182 lines
16 KiB
Markdown
182 lines
16 KiB
Markdown
---
|
||
title: Apa & Mengapa menggunakan Tailscale
|
||
tags:
|
||
- blog
|
||
slug: apa-itu-mengapa-menggunakan-tailscale
|
||
date: 2021-05-21T11:30:00.000Z
|
||
date_updated: 2021-08-01T04:53:57.000Z
|
||
excerpt: Tailscale — a secure network that just works
|
||
---
|
||
|
||
Untuk dapat bisa membuat komputer berkomunikasi satu sama lain, satu-satu nya cara adalah melalui alamat IP sebagai pengenal. Beda dengan manusia yang bisa berkomunikasi dengan memanggil namanya; nama orang tua nya, ataupun kekurangan yang dia miliki.
|
||
|
||
Untuk bisa mendapatkan alamat IP caranya ada 2: statis alias kita atur sendiri & dinamis alias ada "seseuatu" yang mengaturnya sendiri (DHCP). Tapi tidak sesederhana itu, jika gue sedang menyalakan 2 komputer dan masing-masing komputer sudah gue set dengan alamat IP yang berbeda-beda, apakah bisa langsung berkomunikasi? Tentu tidak. Dalam komunikasi, kita tidak hanya butuh "lawan bicara" saja melainkan "media" nya juga. Misal, bila kita ingin *say hello *ke seseorang, media tersebut berarti mulut untuk berbicara (send) & telinga untuk mendengarkan (receive). Di dunia komputer, let's say media itu adalah Hub, Switch dan Router.
|
||
|
||
Oke sekarang kita sudah ada pengenal & sudah ada media, lalu apakah sudah bisa berkomunikasi? Satu hal lagi yang dibutuhkan dalam komunikasi adalah protokol, ada tata caranya. Misal, komunikasi akan berjalan kurang lancar ketika si A yang orang Bandung berbicara dengan si B yang orang Surabaya dengan bahasa Sunda.
|
||
|
||
Protokol adalah tentang kesepakatan, sederhananya di dunia komputer, misal untuk dapat mengetahui apakah si B bisa dihubungi oleh si A, biasanya kita menggunakan protokol ICMP untuk mengirim "PING" ke target dan karena si B tau kalau itu adalah PING, maka si B bisa mengirim balik ke si A "PONG" untuk memberitahukan bahwa si B dapat dihubungi khususnya melalui protokol ICMP.
|
||
router sebagai "media" untuk berkomunikasi
|
||
Kasus diatas adalah untuk komunikasi yang berada di jaringan lokal atau yang biasa disebut dengan Local Area Network (LAN) yang mana jaringan yang ada hanya sebatas di lokal yang relatif sempit.
|
||
|
||
Sekarang adalah era internet, internet sederhananya adalah jaringan komputer yang saling terhubung. Komputer yang berada di Bandung dapat berkomunikasi dengan komputer yang berada di Singapore di jaringan internet. Media yang digunakan dalam komunikasi tersebut masih router, namun lebih kompleks.
|
||
contoh yang disederhanakan melakukan PING dari 192.168.10.6 ke 1.1.1.1 di Singapore
|
||
Sebagai catatan tambahan, biasanya jaringan untuk level kota keatas akan melalui Point of Presence (PoP) dan untuk yang negara (kumpulan kota) keatas akan melalui IXP.
|
||
|
||
Bagian dari ilustrasi diatas yang tidak gue bahas adalah tentang Network Address Translation (NAT) yang akan gue bahas nanti di tulisan khusus. Ilustrasi diatas hanyalah gambaran yang disederhanakan, dalam praktiknya harusnya lebih kompleks dari ilustrasi tersebut.
|
||
|
||
Disitu terlihat bahwa untuk mencapai 1.1.1.1 dari 192.168.10.6, komputer kita harus melalui komputer yang memiliki alamat IP 118.99.118.144 lalu 27.111.228.9 yang mana dua (tiga dengan 1.1.1.1) tersebut adalah alamat IP publik sedangkan yang 192.168.10.6 tersebut adalah privat.
|
||
|
||
Lanjut.
|
||
|
||
Total alamat IP versi 4 yang ada adalah **4,294,967,296** dan untuk yang publik sendiri ada ****3,706,452,992**. **Bayangkan komputer kita terhubung (berada dalam jaringan) dengan 3 milyar komputer lainnya.
|
||
|
||
Bagian yang mau gue highlight disini salah satunya adalah di keamanan.
|
||
|
||
Devbox gue yang ada di Singapore secara teori dapat berkomunikasi dengan 3 milyar komputer lainnya yang berada dalam jaringan internet. Begitupula sebaliknya, 3 milyar komputer tersebut dapat berkomunikasi dengan komputer gue juga.
|
||
|
||
Ingat analogi mulut & telinga dalam berkomunikasi?
|
||
|
||
Analogi telinga dalam komunikasi antar komputer adalah "port". Ketika komputer A mengirim PING ke komputer B, komputer A membuka port yang dia gunakan untuk "mendengarkan" balasan dari komputer B, dan komputer B akan mengirim balasan tersebut ke port yang komputer A gunakan.
|
||
PING dari kompuer A yang menggunakan 55 dan komputer B yang menggunakan port 28
|
||
Terdapat [~64k port](https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers) yang sudah diketahui, dan terdapat maksimal [65,535 port](https://stackoverflow.com/a/113228) yang dapat dibuka. Port yang paling sering digunakan untuk berkomunikasi adalah 22, yakni untuk membuat koneksi SSH alias mengakses komputer dari jarak jauh.
|
||
|
||
Beberapa orang ada yang menyamarkan port untuk SSH misal dari yang 22 menjadi 24 demi menghindari serangan, namun pendekatan tersebut adalah "security by obscurity" karena pada akhirnya penyerang pun akan menemukannya thanks to `nmap(1)`.
|
||
|
||
Mari kita fokus terkait SSH terlebih dahulu.
|
||
|
||
Masalahnya adalah bagaimanapun port tersebut tetap terbuka ke jaringan publik. Mungkin masalah ini dapat diatasi dengan melakukan *rate limit *di firewall untuk menghindari serangan *bruteforce *namun tetap tidak menyelesaikan masalah tersebut.
|
||
|
||
Solusi yang paling umum digunakan adalah dengan membuat jaringan pribadi (virtual) diatas jaringan publik atau yang biasa disebut dengan Virtual Private Network (VPN).
|
||
Ilustrasi sederhana tentang VPN dengan subnet 10.0.0.0/24
|
||
Sekilas terlihat seperti komunikasi dalam jaringan seperti biasa, bukan? Dari gambaran diatas, paket yang dikirimkan untuk "jaringan biasa" sederhananya seperti ini:
|
||
|
||
**IP header (inner, encrypted):**
|
||
|
||
- source: 192.168.6.8
|
||
- destination: 192.168.7.9
|
||
|
||
**IP header (outer):**
|
||
|
||
- source: 192.168.6.8
|
||
- destination: 192.168.7.9
|
||
|
||
Namun dalam jaringan VPN, sederhananya seperti ini:
|
||
|
||
**IP header (inner, encrypted):**
|
||
|
||
- source: 10.0.0.2
|
||
- destination: 10.0.0.3
|
||
|
||
**IP header (outer):**
|
||
|
||
- source: <ip_public_a>
|
||
- destination: <ip_public_b>
|
||
|
||
Yang sederhananya, router (dan siapapun yang berada dibalik itu) tidak mengetahui siapa berkomunikasi dengan siapa, tapi yang dia ketahui adalah paket tersebut untuk memang untuk dia dan dia tau harus diteruskan kemana paket tersebut. Berikut ilustrasi lanjutannya:
|
||
IP yang ada diatas kotak komputer adalah IP Publik milik router
|
||
VPN pada umumnya menggunakan pendekatan "hub-and-spoke" atau yang biasa dikenal dengan "star network" yang sederhananya adalah mengandalkan 1 gerbang sebagai relay. Alasannya? Banyak. Yang paling umum adalah terkait Firewall yang nanti akan kita bahas di tulisan tentang NAT :))
|
||
|
||
Lanjut. Misal kita buat gambaran untuk membuat koneksi SSH dari komputer A ke komputer B melalui VPN. Karena mereka tersambung ke VPN, pasti mereka memiliki (Virtual) Network Interface lagi yang ditujukan untuk *tunneling *untuk alamat IP yang sudah didefinisikan. Anggap network interface tersebut namanya adalah `utun3`, nama bisa bervariasi tergantung mood kernel.
|
||
|
||
Ketika pengguna melakukan `ssh faultable@10.0.0.3`, dalam routing table berarti paket tersebut di *handle *oleh `utun3`. Dari `utun3` dia kirim paket (ter-enkripsi) ke default/external router bahwasannya dia ingin mengirimnya ke `143.198.198.198` yang mana itu adalah alamat IP publik dari komputer B.
|
||
|
||
Darimana komputer A alias si `utun3` tau kalau paket untuk `10.0.0.3` adalah komputer yang memiliki alamat IP `143.198.198.198`? Beragam. Misal, dari VPN Gateway.
|
||
|
||
Lalu paket dikirim oleh ISP A ke VPN Gateway dan si gateway meneruskannya ke ISP B, dan ISP B tau kalau paket tersebut adalah untuk dia dan kemana paket tersebut diteruskan misal ke port 22.
|
||
|
||
Berdasarkan kasus diatas, kita bisa memitigasi serangan terkait koneksi SSH dengan hanya menerima koneksi ke port 22 dari alamat IP VPN yang sudah didefinisikan.
|
||
|
||
Berkat menggunakan VPN, dapat diasumsikan bahwa segala sesuatu yang berada di jaringan tersebut terjamin & aman, dan bukan alasan mengapa VPN memiliki moto "trust but verify", karena untuk dapat terhubung ke VPN biasanya pengguna harus melakukan autentikasi terlebih dahulu dan juga paket selalu berada dalam bentuk ter-enkripsi.
|
||
|
||
Misal ada 3 komputer yang terhubung ke VPN.
|
||
|
||
Salah satu komputer diretas, dan seseorang dapat mengakses mesin tersebut.
|
||
|
||
Ingatkan kalau moto VPN adalah "trust but verify" dan karena koneksi tersebut berasal dari VPN, maka si komputer C yang diretas dapat berkomunikasi dengan komputer lain termasuk melakukan SSH. Meskipun mungkin penyerang tidak mengetahui kredensial yang terkait target, namun ini bisa menjadi masalah karena, well, koneksi yang berada di jaringan VPN terjamin & aman.
|
||
|
||
Dan berapa lama untuk melakukan *crack *terhadap ssh private key menggunakan john the ripper? Gue rasa tidak akan selamanya.
|
||
|
||
Anyway, kasus tersebut mungkin terlalu imajinatif.
|
||
|
||
Manfaat menggunakan VPN bukan hanya di keamanan, melainkan bisa untuk mengakses komputer yang tidak berada di 1 jaringan fisik namun dibalik alamat IP dinamis (misal mengakses Raspberry Pi gue dari Starbucks) yang pada intinya dapat membuat jaringan interlokal seperti lokal. Silahkan berimajinasi, seperti, membuat AirDrop® like experience untuk mengirim berkas dengan mudah & aman secara peer-to-peer.
|
||
|
||
## Wireguard®
|
||
|
||
Wireguard adalah program untuk membuat VPN. Program Wireguard bersumber kode terbuka, relatif sederhana, dan cepat. Autentikasi yang ada di Wireguard menggunakan *public key cryptography* seperti sebagaimana SSH.
|
||
|
||
Paket yang ditukar di Wireguard menggunakan protokol UDP daripada TCP seperti kebanyakan program VPN lainnya seperti OpenVPN dan tinc. Terdapat pro-kontra khususnya dalam pemilihan protokol UDP karena ISP sering memblokir protokol UDP untuk non well-known port, namun itu bukanlah masalah besar mengingat kita bisa melakukan hole punching yang nanti akan kita bahas di tulisan NAT.
|
||
|
||
Wireguard dapat menghubungkan antar komputer secara peer-to-peer, berbeda dengan VPN lain yang biasanya menggunakan *hub-and-spoke *yang biasanya berguna dalam proses autentikasi. Karena Wireguard menggunakan PKI dalam autentikasi, bagian yang harus didefinisikan oleh Wireguard hanya 4:
|
||
|
||
- PrivateKey: private key dari peer ini
|
||
- Address: alamat IP dari peer ini
|
||
- Endpoint: dimana peer tersebut berada
|
||
- PublicKey: apa public key dari peer tersebut
|
||
- AllowedIPs: kumpulan alamat IP yang ingin diarahkan melalui Wireguard
|
||
|
||
Misal jika ada konfigurasi seperti ini:
|
||
|
||
[Interface]
|
||
PrivateKey = <private_key_kita>
|
||
Address = 10.0.0.3/24
|
||
|
||
[Peer]
|
||
PublicKey = <public_key_peer>
|
||
AllowedIPs = 10.0.0.0/24
|
||
Endpoint = 143.198.198.198:1337
|
||
|
||
Ketika kita melakukan PING ke 10.0.0.3, berarti paket tersebut akan dikirimkan melalui interface yang dibuat oleh Wireguard di kita ke peer yang berada di 143.198.198.198.
|
||
|
||
Peer yang berada di IP 143.198.198.198 pun konfigurasinya harus disesuaikan dengan konfigurasi kita, misal seperti ini:
|
||
|
||
[Interface]
|
||
PrivateKey = <private_key_peer>
|
||
Address = 10.0.0.1/24
|
||
|
||
[Peer]
|
||
PublicKey = <public_key_kita>
|
||
AllowedIPs = 10.0.0.2/32
|
||
|
||
Bagian endpoint opsional bila komputer tersebut berada dibalik IP dinamis. Sayangnya, rata-rata komputer pribadi berada dibalik alamat IP dinamis. Dan untuk dapat terhubung ke komputer/peer lain, kita lagi-lagi membutuhkan Hub sebagai STUN server untuk dapat mengetahui alamat IP publik dari peer kita.
|
||
|
||
Dan juga, kita harus *take care *terkait public/private key yang ada. Ketika kita memiliki 8 komputer yang ingin terhubung di VPN melalui Wireguard secara peer-to-peer, berarti ada n*(n-1) koneksi yang terjadi. Berarti, jika n tersebut adalah 8, ada 56 koneksi yang terjadi.
|
||
ilustrasi jelek koneksi p2p
|
||
Setiap *peer *harus memiliki *public key *dari *peer *yang ingin tersambung. Setup VPN terakhir gue melalui Wireguard menggunakan pendekatan hub-and-spoke karena... lebih sederhana.
|
||
|
||
Dengan setup seperti diatas, ketika komputer 2 ingin mengakses komputer 3, paket dikirimkan melalui komputer 1 terlebih dahulu. Dan good luck ketika komputer 1 meninggoy.
|
||
|
||
Tapi setup diatas relatif sederhana. Komputer selain komputer 1 bertindak sebagai *client *dan si komputer 1 yang memegang semua *public key *yang ada serta yang bertanggung jawab seperti *apakah komputer 2 boleh mengakses komputer 3?*
|
||
|
||
Masalah utama yang sering gue rasakan adalah tidak *reliable *nya komputer 1 yang menyebabkan koneksi VPN tidak efektif (tapi gue sadar diri kok). Setelah itu gue mencoba menggunakan solusi lain yakni [ZeroTier](https://www.zerotier.com) yang mana menggunakan pendekatan mesh network, namun terlalu kompleks dari sisi konfigurasi untuk admin dan juga kurang reliable khususnya dalam kasus "full tunnel mode" karena sering kali paket tidak dikirim melalui interface nya ZT.
|
||
|
||
## Tailscale
|
||
|
||
Tailscale adalah program untuk membuat VPN juga yang dibuat diatas Wireguard. Yang berarti, segala benefit yang didapat dari menggunakan Wireguard maka ada di Tailscale juga.
|
||
|
||
Tailscale melengkapi beberapa kekurangan yang dari Wireguard yang memang kekurangan tersebut bukanlah tanggung jawab Wireguard, seperti:
|
||
|
||
- Mesh network, meskipun Wireguard akan mendukungnya (seperti out-of-the-box nya `wg-quick`) melalui `[wg-dynamic](https://github.com/WireGuard/wg-dynamic/blob/master/docs/idea.md)`
|
||
- Machine authentication, jika di Wireguard hanya butuh public/private key, di Tailscale salah satunya menggunakan autentikasi via SSO untuk menjelaskan bahwa *komputer A boleh tersambung ke jaringan B*
|
||
- Magic DNS. Ini seperti mDNS, seperti, ketika ingin mendapatkan alamat IP komputer B, di mDNS kita hanya perlu mengetahui *hostname *nya saja sedangkan di Magic DNS hampir sama namun pendekatan yang digunakan adalah "machine name". Di Wireguard untuk dapat mengetahui alamat IP private dari mesin X, kita harus mengatur bagian `DNS` berikut dengan DNS nya juga.
|
||
- ACL. Di Wireguard mungkin ACL dapat diatur melalui `AllowedIPs`, jika di Tailscale menggunakan "caranya sendiri" yakni sebuah berkas yang berformat JSON sehingga kasus seperti *yang boleh SSH (port 22) ke mesin db-prod dan app-prod hanya group:devops *relatif lebih mudah
|
||
|
||
Mungkin masih banyak fitur lain yang belum gue sebut, cuman yang gue pakai fitur-fitur diatas aja. Tailscale menjanjikan "zero config" dalam proses instalasinya, dan bahkan cewek gue yang bukan orang IT pun bisa mengakses *private services* yang hanya bisa diakses di jaringan VPN.
|
||
|
||
Thanks to Tailscale sehingga dia tidak perlu berurusan dengan PublicKey, Endpoint, AllowedIPs, Ip dan lain sebagainya :))
|
||
|
||
## Cara mulai menggunakan Tailscale
|
||
|
||
Satu hal yang perlu diketahui adalah autentikasi di Tailscale baru hanya bisa melalui akun Google, akun Microsoft, dan SSO provider lain. Gue belum coba apakah menggunakan solusi lain seperti Keycloak bisa atau tidak tapi harusnya bisa jika Tailscale mendukung SAML. Anyway.
|
||
|
||
Jika kebutuhan diatas sudah siap, tinggal unduh aplikasi Tailscale di sistem operasi yang digunakan, autentikasi, selesai.
|
||
|
||
## Mengapa menggunakan Tailscale?
|
||
|
||
Gue sejujurnya ingin menulis lebih dalam tentang ini khususnya terkait Zero Trust networks yang menjadi salah satu alasan mengapa Tailscale ada. Dan karena itu adalah termasuk *buzzword *yang sangat menarik, jadi gue akan tulis ditulisan khusus—yang anggap saja sebagai part 2 dari tulisan ini—untuk menarik pembaca yang datang dari hasil pencarian *Apa itu Zero Trust network *hahaha.
|
||
|
||
## Penutup
|
||
|
||
Gue rasa judul dari tulisan ini lumayan oke untuk dijangkau oleh pengguna internet yang bergantung dengan mesin pencari untuk mendapatkan informasi. Serta, tulisan gue cuma ada 1 dan itupun tidak jelas.
|
||
|
||
Tulisan ini sebagai pembuka untuk gambaran akan tulisan-tulisan selanjutnya yang akan ada di blog ini. Di next post gue akan menulis tentang NAT, dan selanjutnya gue akan fokus ke dunia p2p karena ini menjadi topik yang gue tertarik untuk pelajari di tahun 2021 ini.
|