Apa Itu Tailscale dan Bagaimana Cara Kerjanya?

Apa itu Tailscale?

Tailscale adalah VPN yang menghubungkan mesin secara langsung satu sama lain, bukan merutekan seluruh trafik melalui satu gateway yang Anda jalankan. Setiap node menjalankan WireGuard, sehingga paket dikirim secara terenkripsi dari satu server ke server lain dan tidak ada pihak di jalur tersebut yang dapat membacanya. Server koordinasi terkelola menangani proses perkenalan antar-node. Server ini menyimpan dan mendistribusikan kunci publik serta memberi tahu setiap node lokasi node lainnya. Server ini juga menerapkan aturan akses yang Anda tulis.

Pemisahan tersebut merupakan keseluruhan desainnya. Data plane bersifat peer-to-peer dan terenkripsi di antara node. Control plane adalah layanan yang dijalankan Tailscale untuk Anda. Setiap pertanyaan penting tentang Tailscale, termasuk pertanyaan yang sulit tentang kepercayaan, berawal dari dua fakta tersebut. Jika Anda sudah membangun VPN WireGuard secara manual pada VPS, Tailscale menyediakan tunnel yang sama, tetapi distribusi kunci dan traversal firewall ditangani untuk Anda.

Bagaimana cara kerja Tailscale?

Jaringan privat node Anda disebut tailnet. Empat hal terjadi ketika sebuah mesin bergabung ke dalamnya.

1. Daemon tailscaled dimulai, membuat pasangan kunci WireGuard, dan menyimpan statusnya di /var/lib/tailscale/tailscaled.state. Kunci privat tetap berada di mesin tersebut. Tailscale menyatakannya dengan jelas: "kunci privat tidak pernah meninggalkan node-nya."
2. Node masuk ke server koordinasi dan mengunggah kunci publiknya, serta alamat tempat node tersebut memperkirakan dirinya dapat dijangkau. Tailscale menjelaskan server itu sebagai "drop box bersama untuk kunci publik."
3. Server koordinasi mengirimkan peta jaringan: kunci publik, alamat tailnet, nama mesin, dan endpoint kandidat setiap node yang boleh dijangkau oleh node ini.
4. Setiap pasangan node kemudian mencoba membangun tunnel WireGuard langsung di antara keduanya. Jika gagal, paket akan dikirim melalui relay.

Setiap node memperoleh alamat stabil dari 100.64.0.0/10, yaitu rentang carrier-grade NAT dari 100.64.0.0 hingga 100.127.255.255. Tailscale menggunakan rentang tersebut karena dicadangkan untuk infrastruktur provider, sehingga jarang bertabrakan dengan alamat privat yang sudah digunakan server Anda. Di Linux, tunnel tersebut muncul sebagai interface bernama tailscale0.

Implementasi WireGuard berada di dalam tailscaled pada userspace, bukan pada modul kernel. Karena itu, Tailscale dapat dijalankan pada virtualisasi container ketika sudo modprobe wireguard gagal dengan Operation not supported. Konsekuensinya, batas throughput pada mesin tertentu lebih rendah daripada WireGuard di kernel. Ini adalah salah satu kompromi yang dibahas dalam perbandingan Tailscale dengan WireGuard biasa.

Dua perintah berikut menunjukkan kondisi koneksi Anda.

tailscale ip -4
tailscale status

tailscale status mencetak satu baris untuk setiap node. Kolom terakhir adalah bagian yang perlu diperhatikan.

100.101.102.103  web-1      you@  linux  -
100.101.102.104  db-1       you@  linux  active; direct 198.51.100.24:41641
100.101.102.105  ci-runner  you@  linux  active; relay "fra"

direct yang diikuti alamat dan port berarti kedua mesin menemukan jalur satu sama lain dan trafik berlangsung secara peer-to-peer. relay "fra" berarti trafik melewati relay Tailscale di Frankfurt. - berarti saat ini tidak ada sesi aktif dengan node tersebut. Kondisi ini normal.

Hal yang dapat dan tidak dapat dilihat oleh server koordinasi

Server koordinasi menyimpan kunci publik dan metadata. Server ini mengetahui nama mesin Anda, pengguna atau tag yang memiliki setiap node, alamat tailnet setiap node, alamat publik yang dapat digunakan untuk menjangkau node Anda, waktu terakhir setiap node online, serta file kebijakan yang Anda tulis. Informasi tersebut merupakan peta lengkap fleet Anda.

Server ini tidak menyimpan kunci privat, sehingga tidak dapat mendekripsi trafik antara dua node. Enkripsi berlangsung secara end-to-end antara peer WireGuard, sedangkan server koordinasi bukan peer.

Server ini dapat membagikan kunci. Setiap server koordinasi, baik yang di-host maupun yang Anda kelola sendiri, dipercaya untuk memberi tahu node Anda kunci publik mana yang menjadi bagian dari tailnet. Hal ini menjadi inti model ancaman yang dibahas di bagian selanjutnya dan menjadi alasan Headscale, server koordinasi open-source yang Anda host sendiri tersedia.

Cara dua server di balik firewall berbeda berkomunikasi secara langsung

NAT (network address translation) memungkinkan banyak mesin menggunakan satu alamat publik. VPS biasanya memiliki alamat publik sendiri, tetapi mesin lain yang ingin Anda masukkan ke tailnet sering kali tidak memilikinya: server di rumah, build runner pada jaringan kantor, atau mesin di balik firewall provider yang tidak dapat Anda ubah.

Tailscale menemukan jalur menggunakan teknik yang dibangun berdasarkan standar STUN (session traversal utilities for NAT) dan ICE. Setiap node mengirim paket UDP kecil ke server STUN, lalu mengetahui alamat publik dan port yang ditetapkan router untuk socket tersebut. Kedua node melaporkan kandidat tersebut ke server koordinasi, yang meneruskannya ke sisi lain. Setelah itu, kedua node mulai mengirim paket satu sama lain secara bersamaan. Setiap router melihat paket keluar terlebih dahulu, sehingga router membuat pemetaan dan menerima balasan yang datang dari alamat yang sama. Tidak ada sisi yang memerlukan aturan firewall inbound.

Port yang digunakan bersifat spesifik. Tunnel WireGuard langsung menggunakan UDP dengan source port default 41641. STUN berjalan melalui UDP 3478 ke server relay Tailscale. Koneksi kontrol dan data yang direlay menggunakan HTTPS pada TCP 443. Biasanya Anda tidak perlu membuka port inbound, tetapi pada jaringan dengan NAT yang sulit, mengizinkan UDP 41641 inbound meningkatkan kemungkinan terbentuknya koneksi langsung.

tailscale netcheck

Baca dua baris dari laporan tersebut. UDP: true berarti UDP dapat keluar dari mesin, sedangkan UDP: false berarti setiap koneksi dari node ini akan menggunakan relay. MappingVariesByDestIP: true berarti router menetapkan port publik yang berbeda untuk setiap tujuan, sehingga prediksi alamat di atas tidak dapat berfungsi dan node tersebut biasanya tetap menggunakan relay.

Saat Tailscale menggunakan relay DERP

DERP (designated encrypted relay for packets) adalah mekanisme fallback. Tailscale menjalankan relay di banyak region yang dapat dijangkau melalui TCP 443. Node yang tidak dapat memperoleh jalur langsung akan mengirim paket WireGuard melalui salah satu relay tersebut.

Paket tetap terenkripsi. Tailscale menjelaskannya secara tegas: "tidak pernah ada cara bagi server DERP untuk mendekripsi trafik Anda. Server tersebut hanya meneruskan trafik yang sudah dienkripsi secara buta dari satu node ke node lain." Relay melihat ciphertext dan mengetahui node mana yang berkomunikasi dengan node mana.

Relay juga membawa paket pertama dari sebagian besar koneksi. Pencarian jalur langsung memerlukan waktu singkat. Karena itu, sesi sering kali dimulai melalui relay lalu beralih ke jalur langsung setelah kedua node saling menemukan. Anda dapat memantau proses tersebut.

tailscale ping db-1

Balasan pertama muncul melalui via DERP(fra), lalu baris berikutnya melaporkan sesuatu seperti via 198.51.100.24:41641. Perubahan tersebut menunjukkan peningkatan ke tunnel langsung. Jika nilainya tidak pernah berubah, jalankan tailscale netcheck pada kedua sisi. Jalur melalui relay tetap berfungsi. Namun, latensinya lebih tinggi karena setiap paket harus melewati mesin ketiga sebagai perantara. Jika yang Anda amati adalah transfer yang lambat, bukan koneksi yang gagal, mengapa koneksi Tailscale melalui relay jauh lebih lambat daripada koneksi langsung mengukur perbedaannya dan menunjukkan cara menghubungkan VPS ke jalur langsung.

Menghubungkan VPS ke tailnet

Skrip instalasi ini mendukung Ubuntu dan Debian.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

sudo tailscale up mencetak URL. Buka URL tersebut, lakukan autentikasi, lalu node akan muncul di konsol admin. Setelah itu, pastikan daemon kembali berjalan setelah reboot karena langkah ini sering dilewati.

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled harus mencetak enabled, dan tailscale status harus menampilkan node baru beserta alamat 100.x-nya. Untuk server yang dibuat dengan skrip, URL interaktif tidak berguna. Buat auth key di konsol admin, lalu berikan key tersebut bersama tag yang menunjukkan jenis mesin ini.

sudo tailscale up --auth-key=tskey-auth-REPLACE-ME --advertise-tags=tag:server

Node yang diberi tag dimiliki oleh tag tersebut, bukan oleh orang yang menjalankan perintah. Dengan demikian, node tetap berfungsi setelah akun orang tersebut dihapus. Tag harus dideklarasikan terlebih dahulu dalam file kebijakan di bawah tagOwners, atau perintah akan ditolak. Pemberian tag juga mengubah cara mesin dihitung dalam paket Anda, karena resource bertag dihitung secara terpisah dari perangkat milik pribadi pengguna. Cakupan paket gratis yang sebenarnya menjelaskan batas tersebut.

Dua pengaturan penting untuk armada server. Secara default, node key kedaluwarsa setelah 180 hari (per Agustus 2026). Setelah key kedaluwarsa, "koneksi ke/dari endpoint yang dimaksud akan berhenti berfungsi" sampai seseorang login kembali. Oleh karena itu, buka baris mesin tersebut di konsol admin dan pilih Disable Key Expiry pada server yang tidak digunakan secara interaktif. MagicDNS, yang secara default diaktifkan untuk tailnet yang dibuat pada atau setelah 20 October 2022, memberikan setiap node nama seperti db-1.yak-bebop.ts.net. Nama tersebut di-resolve oleh stub resolver pada 100.100.100.100. Gunakan nama tersebut, bukan alamatnya, karena node yang dibuat ulang akan memperoleh alamat baru tetapi tetap menggunakan namanya.

Jika instalasi gagal pada apt atau repositori, error instalasi Tailscale yang umum di Ubuntu menjelaskan solusinya.

Mengakses service yang terikat ke localhost

Di sinilah tailnet berguna, sekaligus menjadi bagian yang sering membingungkan. Bergabung ke tailnet tidak membuat service loopback dapat diakses.

ss -tlnp | grep 3000

Jika perintah tersebut menampilkan 127.0.0.1:3000, socket hanya menerima paket yang alamat tujuannya 127.0.0.1. Permintaan dari node lain tiba dengan alamat tujuan 100.x milik node ini, sehingga kernel tidak menemukan listener untuk permintaan tersebut dan mengirim TCP reset. Client melaporkan Connection refused. Tunnel tidak bermasalah. Listener-nya yang bermasalah.

Ada dua solusi yang tepat. Ikat service ke alamat tailnet node agar service tetap tidak terbuka pada interface publik tanpa perantara proxy: teruskan --bind 100.101.102.104 atau opsi yang setara dalam konfigurasi Anda, dan untuk container, publish port sebagai -p 100.101.102.104:3000:3000. Atau, biarkan service tetap menggunakan loopback dan tempatkan Tailscale di depannya.

tailscale serve 3000

Konfigurasi tersebut mem-proxy permintaan ke http://127.0.0.1:3000 dan menyediakannya di dalam tailnet melalui nama ts.net menggunakan HTTPS, setelah sertifikat HTTPS diaktifkan untuk tailnet. Service tetap privat bagi node Anda. Versi publik dari konsep yang sama adalah Funnel. Tailscale serve dan funnel menjelaskan pilihan yang sesuai.

Dua kebutuhan terkait memiliki halaman tersendiri. Untuk mengakses seluruh jaringan privat yang tidak memasang Tailscale, gunakan subnet router pada VPS. Untuk mengirim trafik Internet keluar dari sebuah node melalui node lain, gunakan exit node.

Menutup port yang tidak lagi diperlukan

Setelah semua administrator dapat mengakses server melalui tailnet, port publik 22 tidak lagi diperlukan. Inilah manfaat praktisnya: port yang ditutup tidak dapat menjadi sasaran brute force, dan log Anda tidak lagi dipenuhi percobaan akses.

Urutan langkah penting. Tambahkan akses tailnet, pastikan Anda dapat login melaluinya dari sesi kedua, lalu hapus aturan publik.

sudo ufw allow in on tailscale0
sudo ufw status verbose

Setelah itu, hapus aturan SSH publik dan sambungkan kembali menggunakan nama MagicDNS. Perhatikan fungsi ufw allow in on tailscale0: aturan ini mempercayai semua koneksi yang datang melalui tunnel, sehingga file kebijakan Tailscale menjadi kontrol akses, bukan ufw. Tulis kebijakan dengan mempertimbangkan hal tersebut.

Peringatan bagi siapa pun yang menjalankan container. Port Docker yang dipublikasikan membuat aturan NAT sendiri dan melewati ufw, sehingga ufw deny tidak menutupnya. Port Docker yang dipublikasikan melewati ufw menjelaskan mekanismenya. Memublikasikan port ke alamat tailnet, seperti di atas, menghindari masalah tersebut. Jika aplikasi berjalan menggunakan Docker Compose, sidecar Tailscale dalam stack Compose mengambil langkah lebih jauh dan menghapus port yang dipublikasikan sepenuhnya, sehingga container hanya dapat dijangkau melalui nama tailnet-nya.

Apa yang dilindungi Tailscale dan apa yang tidak

Hal ini perlu dinyatakan dengan jelas karena versi pemasaran sering mengaburkan batasnya.

Dilindungi: trafik antara dua node dienkripsi secara end-to-end dengan WireGuard, dan tidak ada relay di tengah yang dapat membacanya. Kunci privat tidak pernah meninggalkan mesin yang membuatnya. Node tidak memerlukan port publik inbound, sehingga tidak ada layanan pada 22 atau 5432 yang dapat dipindai oleh Internet. Akses antar-node ditentukan oleh file kebijakan, bukan oleh siapa pun yang mengetahui suatu alamat.

Tidak dilindungi: server koordinasi dapat melihat grafik perangkat Anda. Metadata tersebut sensitif, karena nama mesin, pemilik, alamat, dan waktu online menggambarkan infrastruktur Anda. Server itu juga mendistribusikan kunci, dan di situlah risikonya lebih besar. Tailscale menyatakannya secara langsung: "Jika Tailscale bersifat jahat dan secara diam-diam memasukkan node baru ke jaringan Anda, Tailscale dapat mengirim atau menerima trafik ke node yang sudah ada dalam bentuk plaintext." Penyedia single sign-on Anda berada dalam jalur kepercayaan yang sama, karena siapa pun yang dapat membuat identitas di sana dapat menambahkan node. Node yang telah dibobol juga merupakan peer di dalam tailnet, sehingga apa pun yang dapat dijangkaunya berikutnya ditentukan oleh kebijakan Anda. Apakah hal itu merupakan risiko yang dapat diterima bergantung pada pihak yang ingin Anda lindungi, dan model kepercayaan lengkap membahas setiap kasus tersebut, termasuk tindakan yang sebenarnya dapat dilakukan menggunakan akun identitas yang dicuri.

Ada dua jawaban untuk risiko distribusi kunci. Yang pertama adalah tailnet lock, yang mengharuskan node tepercaya yang sudah ada menandatangani node baru secara kriptografis sebelum node lain menerimanya. Control plane yang menambahkan node tanpa tanda tangan yang valid akan diabaikan. Konsol admin membuat baris tailscale lock init yang tepat untuk node penanda tangan Anda, dan setiap node dapat mengonfirmasi apa yang dilihatnya.

tailscale lock status

Semua node harus melaporkan kumpulan kunci penanda tangan tepercaya yang sama. Jawaban kedua adalah menjalankan control plane sendiri. Server koordinasi Headscale yang di-host sendiri menggunakan protokol yang sama dengan klien yang sama, sehingga grafik perangkat dan distribusi kunci dipindahkan ke perangkat keras milik Anda. Anda juga bertanggung jawab atas ketersediaan server tersebut. Jika Anda masih membandingkan control plane yang di-host sendiri dan belum memilih yang ini, NetBird adalah VPN mesh terpisah yang servernya Anda jalankan sepenuhnya pada satu VPS.

Ada satu default yang perlu diperbaiki pada hari pertama. tailnet baru bersifat permisif: "file kebijakan tailnet default memungkinkan komunikasi antara semua perangkat dalam tailnet." Segera setelah Anda menambahkan bagian acls, modelnya berubah menjadi deny by default dan hanya aturan Anda yang dapat diterapkan.

{
  "tagOwners": {
    "tag:server": ["autogroup:admin"]
  },
  "acls": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server:22"]}
  ]
}

Kebijakan tersebut memungkinkan anggota tailnet mengakses SSH pada server yang diberi tag dan tidak mengakses layanan lain. Tambahkan satu aturan untuk setiap service, bukan membiarkan wildcard, karena wildcard berarti satu kunci laptop yang dicuri dapat mengakses database Anda.

Mode kegagalan dan string yang akan Anda lihat

tailscale status selalu menampilkan relay. Kedua node tidak pernah membangun jalur langsung. Jalankan tailscale netcheck pada kedua sisi. UDP: false berarti UDP diblokir untuk koneksi keluar, sehingga hanya relay yang dapat berfungsi. MappingVariesByDestIP: true berarti ada NAT ketat yang menghalangi, dan mengizinkan UDP 41641 masuk pada sisi yang Anda kendalikan sering kali dapat mengatasinya.

Node yang berfungsi selama berbulan-bulan tiba-tiba menghilang. Kunci node tersebut kedaluwarsa setelah 180 hari, sesuai nilai default. Mesin ditampilkan sebagai kedaluwarsa di konsol admin, dan sudo tailscale up pada mesin tersebut akan memulihkannya. Nonaktifkan kedaluwarsa kunci pada server agar masalah ini tidak terulang.

Peer tercantum, tetapi koneksi mengalami timeout. Konektivitas berfungsi, dan kebijakan menolak trafik tersebut. Periksa bagian acls untuk menemukan aturan yang mencakup sumber, tujuan, dan port ini. Paket yang ditolak akan dibuang, bukan dibalas. Karena itu, Anda mendapatkan timeout, bukan Connection refused.

Nama MagicDNS tidak dapat di-resolve. ping db-1 gagal, sedangkan ping 100.101.102.104 berhasil. Sesuatu mengganti /etc/resolv.conf, sehingga kueri tidak pernah mencapai stub resolver pada 100.100.100.100. Periksa cat /etc/resolv.conf untuk 100.100.100.100, lalu periksa komponen lain pada mesin yang menulis file tersebut. Ini termasuk jenis masalah yang sama seperti DNS yang rusak di dalam tunnel WireGuard.

tailscale up menolak tag Anda. Tag tersebut belum dideklarasikan di bawah tagOwners dalam file kebijakan. Tambahkan tag tersebut di sana, lalu jalankan kembali perintahnya.

FAQ

Apakah Tailscale merupakan VPN atau jaringan mesh?

Kedua istilah tersebut benar, tetapi menjelaskan lapisan yang berbeda. Tunnel menggunakan WireGuard, sehingga Tailscale merupakan VPN. Topologinya adalah mesh karena setiap node membuat tunnel langsung ke setiap node yang diajak berkomunikasi, bukan mengirim setiap paket melalui satu server pusat. Server koordinasi berada pada jalur kontrol, bukan jalur data. Jadi, jika server tersebut tidak dapat dijangkau, tunnel yang sudah ada tetap meneruskan trafik. Yang terhenti saat terjadi gangguan adalah proses bergabungnya node baru serta penerapan perubahan key atau policy.

Apakah Tailscale dapat membaca trafik saya?

Tidak dapat membaca isinya. Trafik dienkripsi secara end-to-end antara node menggunakan WireGuard, private key tidak pernah meninggalkan node, dan relay DERP meneruskan paket yang tidak dapat didekripsinya. Tailscale tetap dapat melihat metadata: nama mesin, pemilik, public key, alamat endpoint, dan waktu setiap node online. Tailscale juga mendistribusikan key, sehingga server koordinasi yang mengalami breach dapat mencoba memasukkan node yang kemudian akan dipercaya oleh seluruh fleet Anda. Tailnet lock mencegah hal tersebut dengan mewajibkan signature dari node tepercaya milik Anda sendiri, sedangkan Headscale menghapus control plane hosted dari arsitektur.

Apakah saya perlu membuka port firewall untuk Tailscale?

Hampir tidak pernah untuk koneksi inbound. Panduan Tailscale menyatakan bahwa "most of the time, you don't need to open any firewall ports." Untuk koneksi outbound, node memerlukan TCP 443 ke server koordinasi dan relay, serta UDP 3478 untuk STUN. Tunnel langsung menggunakan UDP dengan source port yang secara default adalah 41641. Mengizinkan UDP 41641 inbound bersifat opsional dan hanya membantu koneksi langsung berhasil pada jaringan yang memiliki konfigurasi NAT atau firewall yang tidak umum.

Mengapa node lain tidak dapat menjangkau service saya pada port 3000?

Periksa bind address terlebih dahulu menggunakan ss -tlnp. Listener pada 127.0.0.1:3000 menolak koneksi yang ditujukan ke alamat tailnet 100.x milik node karena socket tersebut hanya menerima destination loopback, sehingga client menerima Connection refused. Bind service ke alamat tailnet, atau jalankan tailscale serve 3000 untuk melakukan proxy. Jika listener sudah menggunakan 0.0.0.0 dan koneksi mengalami timeout, bukan penolakan, penyebabnya adalah policy rule atau host firewall, bukan bind address.

Apakah saya sebaiknya menjalankan Headscale, bukan server koordinasi Tailscale?

Jalankan Headscale jika graph perangkat atau distribusi key harus tetap berada pada infrastruktur yang Anda kendalikan, atau jika tailnet harus berfungsi tanpa bergantung pada service eksternal. Client dan protocol-nya sama. Konsekuensinya, Anda harus mengoperasikan server koordinasi tersebut. Jika server mengalami gangguan, node baru tidak dapat bergabung dan perubahan policy tidak dapat diterapkan. Untuk fleet kecil, control plane hosted dengan tailnet lock yang diaktifkan biasanya memberikan kompromi yang lebih baik.