Cara Menjalankan Tailscale Subnet Router di VPS

Apa yang dilakukan Tailscale subnet router

Tailscale subnet router adalah satu mesin yang mengiklankan seluruh rentang alamat IP privat ke tailnet Anda, sehingga setiap perangkat di tailnet dapat menjangkau alamat dalam rentang tersebut meskipun tidak ada perangkat di sana yang menjalankan Tailscale. Tailnet adalah jaringan Tailscale privat Anda, yaitu kumpulan perangkat yang masuk ke satu akun atau organisasi. Fitur yang sering disalahartikan sebagai subnet router adalah exit node, tetapi fungsinya berlawanan. Exit node mengirim seluruh trafik dari suatu perangkat melalui VPS, sehingga VPS menjadi rute perangkat tersebut ke Internet publik.

Satu kalimat untuk masing-masing fitur. Subnet router membuat satu jaringan privat dapat dijangkau dari tailnet. Exit node mengubah lokasi keluarnya trafik publik Anda. Jika yang Anda inginkan adalah fungsi kedua, baca cara menjalankan Tailscale exit node pada VPS. Keduanya menggunakan flag yang berbeda, dan satu VPS dapat menjalankan keduanya secara bersamaan, tetapi keduanya menyelesaikan masalah yang berbeda dan mengalami kegagalan dengan cara yang berbeda.

Kapan VPS memerlukan router subnet

Kasus yang umum adalah jaringan privat yang sudah diberikan oleh provider. VPS Anda memiliki alamat publik dan interface kedua pada segmen privat, sedangkan server lain pada segmen tersebut sama sekali tidak memiliki alamat publik: database pada 10.0.0.20 dan target backup pada 10.0.0.30. Pasang Tailscale pada satu VPS, iklankan 10.0.0.0/24, lalu laptop Anda dapat mengakses alamat privat tersebut secara langsung. Tidak ada hal lain pada segmen tersebut yang berubah, dan database tetap tidak memiliki alamat publik. Jika yang Anda perlukan dari segmen tersebut hanya satu aplikasi web pada satu port, mengiklankan seluruh rentang alamat terlalu luas untuk kebutuhan itu, dan Tailscale serve memasang HTTPS pada satu port tersebut. Pertimbangan yang sama berlaku untuk daemon yang sengaja hanya bind ke localhost, seperti dsh yang berjalan tanpa antarmuka di bawah systemd, ketika alamat tailnet pada VPS tersebut menggantikan tunnel SSH yang biasanya harus tetap terbuka untuk mengakses UI-nya.

Kasus lainnya adalah jaringan di sisi lain VPS. Contohnya LAN (local area network) rumah atau kantor di belakang routernya sendiri, atau rak perangkat yang sama sekali tidak dapat menjalankan Tailscale, seperti switch terkelola atau NAS lama dengan firmware yang dikunci. Satu mesin Linux pada jaringan tersebut menjadi router subnet untuk semua perangkat lain di dalamnya. Di rumah, mesin tersebut sering kali berupa VM kecil pada hypervisor yang sudah Anda jalankan, dan perbandingan biaya host Proxmox di rumah dengan VPS sewaan adalah hal yang harus ditetapkan sebelum Anda menentukan di sisi mana tunnel layanan Anda sebaiknya berada.

Kedua kasus tersebut memiliki satu persyaratan yang sama. Router subnet harus sudah dapat menjangkau rentang alamat yang diiklankannya, menggunakan tabel routing dan firewall miliknya sendiri. Tailscale tidak membuat koneksi tersebut. Tailscale membawa trafik ke router, lalu menyerahkannya kepada kernel untuk diteruskan.

Instal Tailscale dan periksa rute lokal terlebih dahulu

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

Skrip mendeteksi distribusi, menambahkan repositori paket Tailscale, menginstal perintah tailscale dan daemon tailscaled, lalu mengaktifkan service. Pastikan dengan systemctl is-active tailscaled, yang seharusnya menampilkan active.

Sebelum melakukan hal lain, pastikan VPS dapat menjangkau jaringan yang akan Anda iklankan.

ip route show
ping -c3 10.0.0.20

ip route show harus mencantumkan rentang privat pada interface nyata, misalnya 10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5. Jika ping gagal di sini, yaitu langsung ke router, tidak ada flag Tailscale yang dapat memperbaikinya. Masalahnya terletak pada konfigurasi jaringan VPS atau firewall pada host tujuan. Perbaiki masalah tersebut terlebih dahulu karena semua pengujian berikutnya bergantung padanya.

Aktifkan penerusan IP dan pertahankan pengaturannya setelah reboot

Mesin Linux akan membuang setiap paket yang tidak ditujukan kepadanya sendiri, kecuali penerusan diaktifkan. Meneruskan paket mesin lain adalah fungsi utama router subnet, jadi langkah ini wajib dilakukan.

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

Periksa dengan sysctl net.ipv4.ip_forward, yang seharusnya menampilkan net.ipv4.ip_forward = 1.

Banyak orang hanya menyelesaikan langkah ini sebagian. sudo sysctl -w net.ipv4.ip_forward=1 langsung berfungsi, tetapi pengaturannya hilang pada boot berikutnya. Akibatnya, router subnet dapat berjalan selama berminggu-minggu lalu berhenti pada pagi hari setelah reboot akibat upgrade kernel. Bagian yang membingungkan adalah tidak ada tanda kerusakan yang terlihat. tailscale status masih menampilkan node sebagai online, konsol admin masih menampilkan rute yang disetujui, dan klien masih memiliki rute tersebut. Paket tiba di VPS, lalu kernel membuangnya tanpa mencatat apa pun di log. Menulis nilai tersebut ke dalam /etc/sysctl.d/99-tailscale.conf akan memulihkannya setelah reboot.

Jika Anda mengiklankan rute saat penerusan masih dinonaktifkan, tailscale up akan memberikan peringatan saat itu juga, dengan baris yang mirip dengan Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly. Baca output perintah tersebut, jangan langsung melewatinya.

Iklankan route

sudo tailscale up --advertise-routes=10.0.0.0/24

Pada VPS yang sudah login ke tailnet, ubah pengaturan di tempat dengan perintah berikut:

sudo tailscale set --advertise-routes=10.0.0.0/24

Gunakan tailscale set untuk setiap perubahan berikutnya. Menjalankan ulang tailscale up hanya dengan satu flag akan mereset flag yang tidak dicantumkan ulang. CLI akan menghentikan proses dan menampilkan error bahwa perubahan pengaturan dengan cara ini mengharuskan semua flag non-default dicantumkan. tailscale set mengubah satu pengaturan dan mempertahankan pengaturan lainnya.

Beberapa rentang dapat ditulis dalam satu daftar yang dipisahkan koma tanpa spasi: --advertise-routes=10.0.0.0/24,192.168.50.0/24. Setiap entri harus berupa alamat network dalam notasi CIDR (classless inter-domain routing, format 10.0.0.0/24). Jika Anda tidak sengaja menulis alamat host sendiri, 10.0.0.5/24, perintah akan ditolak karena bit setelah prefix tidak bernilai nol. Error tersebut menyebutkan prefix yang kemungkinan Anda maksud. Untuk menghentikan pengiklanan route, tetapkan daftar kosong dengan sudo tailscale set --advertise-routes=.

Menyetujui rute di konsol admin

Mengiklankan rute adalah permintaan, bukan perubahan. Sebelum admin menyetujuinya, tidak ada client yang menerima rute tersebut dan tidak ada alamat dalam rentang itu yang dapat dijangkau. Ini memang disengaja, karena mesin yang dapat menambahkan dirinya sendiri ke tabel routing semua orang dapat menangkap traffic untuk rentang apa pun yang diinginkannya.

Setujui rute tersebut pada halaman Machines di konsol admin. VPS akan tercantum dengan badge subnet. Buka barisnya, cari bagian subnets, edit pengaturan rute, centang rute tersebut, lalu simpan.

Persetujuan berlaku per prefix. Jika Anda mengiklankan 10.0.0.0/24 hari ini dan 192.168.50.0/24 bulan depan, prefix baru akan masuk dalam status belum disetujui, sedangkan prefix lama tetap berfungsi. Dari VPS, rute yang disetujui dan rute yang diabaikan terlihat sama. Karena itu, periksa konsol sebelum melakukan debugging lainnya.

Anda dapat melewati langkah manual ini dengan blok autoApprovers dalam file kebijakan tailnet:

{
  "autoApprovers": {
    "routes": {
      "10.0.0.0/24": ["tag:subnet-router"]
    }
  }
}

Kemudian aktifkan node dengan tag tersebut, sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router, dan rute akan langsung disetujui saat diiklankan. Tag tersebut harus sudah ada di bagian tagOwners pada file kebijakan yang sama. Pengaturan ini berguna jika Anda membuat ulang VPS dari script, karena node hasil pembuatan ulang dianggap sebagai node baru dan rutenya kembali berstatus belum disetujui.

Mengapa klien Linux mengabaikan rute tanpa --accept-routes

Rute tersebut sekarang sudah diiklankan dan disetujui. Ponsel dan Mac Anda dapat mengakses 10.0.0.20. Laptop Linux Anda tidak dapat mengaksesnya, dan tidak ada indikasi masalah pada konsol admin.

Menerima rute subnet berarti menulis entri ke tabel routing klien. Pada Android, iOS, macOS, tvOS, dan Windows, klien Tailscale melakukannya untuk Anda. Di Linux, hal itu tidak dilakukan karena mesin Linux sering berfungsi sebagai server atau router yang tabel routing-nya sengaja dikonfigurasi oleh seseorang. Menyisipkan /24 yang dipelajari dari jaringan secara diam-diam dapat mengganggu trafik yang sudah ditangani mesin tersebut. Jadi, di Linux, Anda harus mengaktifkannya secara eksplisit pada setiap klien:

sudo tailscale set --accept-routes

Kemudian periksa lokasi rute tersebut:

ip route show table 52
ip route get 10.0.0.20

Tailscale di Linux tidak menempatkan rute yang diterima ke tabel routing utama. Rute tersebut ditempatkan di tabel routing 52, lalu Tailscale memasang aturan kebijakan yang dapat dilihat dengan ip rule show dalam rentang prioritas 5210 hingga 5270. Aturan ini mengirim paket yang tidak cocok ke tabel tersebut. Jadi, ip route show sendiri tidak akan pernah menampilkan 10.0.0.0/24, dan pembaca yang hanya memeriksa perintah itu akan menyimpulkan bahwa --accept-routes tidak melakukan apa pun. ip route show table 52 adalah perintah yang menampilkan kondisi sebenarnya, dan seharusnya mencantumkan rentang yang diiklankan pada tailscale0.

Ada satu pengecualian yang perlu diketahui. Jika node Linux ini juga merupakan subnet router kedua untuk jaringan lokalnya sendiri, --accept-routes akan membuatnya mengirim trafik untuk subnet yang terhubung langsung ke router lain, bukan melalui interface-nya sendiri. Pada router standby dalam pasangan high availability, biarkan --accept-routes nonaktif dan hanya iklankan rute.

Mode kegagalan: dua router mengiklankan rentang yang saling tumpang tindih

Dua subnet router tidak boleh mengiklankan rentang yang identik. Rentang yang tumpang tindih dengan panjang prefix berbeda diperbolehkan, dan Tailscale memilih kecocokan yang paling spesifik. Jika router A mengiklankan 10.0.0.0/24 dan router B mengiklankan 10.0.0.0/16, trafik menuju 10.0.0.20 diteruskan ke A.

Hal yang sering mengejutkan adalah perilakunya saat A offline. Tailscale tidak beralih ke rute yang kurang spesifik. Trafik menuju 10.0.0.20 berhenti, sedangkan trafik menuju 10.1.0.20 tetap berfungsi melalui B. Gejalanya terlihat seperti separuh jaringan privat tidak aktif, padahal penyebabnya adalah satu node offline yang memiliki prefix lebih spesifik. Jika Anda ingin menyediakan failover, minta router dengan rentang lebih luas juga mengiklankan prefix yang lebih sempit, sehingga keduanya mencakup alamat yang sama.

Tumpang tindih lainnya terjadi lebih dekat dengan client. Jika Anda berada di jaringan hotel pada 192.168.1.0/24 saat subnet router Anda mengiklankan 192.168.1.0/24, keduanya bersaing untuk tujuan yang sama. Rute yang digunakan bergantung pada platform. Di Linux, tambahkan rule sebelum rule milik Tailscale agar alamat lokal menggunakan main table:

sudo ip rule add to 192.168.1.0/24 priority 2500 lookup main

Rule tersebut tidak persisten dan akan hilang saat boot berikutnya. Solusi sebenarnya adalah memilih rentang privat yang tidak akan Anda temui di jaringan lain. 192.168.0.0/24 dan 192.168.1.0/24 adalah default pada sebagian besar router rumah, jadi pilih sesuatu di dalam 10.0.0.0/8 yang Anda tentukan secara sengaja. Konflik yang sama juga membuat VPN WireGuard biasa yang Anda konfigurasikan secara manual tidak berfungsi, dengan alasan yang sama: rute lokal yang lebih spesifik akan digunakan, sehingga trafik tidak pernah masuk ke tunnel.

Mode kegagalan: DNS mengarah ke alamat yang tidak dicakup oleh rute

Kasus ini sulit di-debug karena tidak ada komponen yang melaporkan error. Nama berhasil di-resolve. Koneksi mengalami timeout.

Misalnya, db.internal.example.com di-resolve ke 10.0.5.20 melalui nameserver privat Anda, dan Anda mengiklankan 10.0.0.0/24. Lookup berhasil karena resolusi DNS (domain name system) dan routing IP merupakan dua langkah terpisah, dan keduanya tidak saling memeriksa. Kemudian, paket menuju 10.0.5.20 tidak menemukan rute yang cocok pada tailnet. Paket tersebut keluar melalui default gateway klien lalu hilang.

Dua perintah berikut memisahkan kedua bagian tersebut:

nslookup db.internal.example.com
ip route get 10.0.5.20

Jika lookup mengembalikan alamat, tetapi ip route get tidak merespons dengan dev tailscale0, berarti nama tersebut benar dan rutenya yang tidak ada. Iklankan rentang yang mencakup alamat tersebut, yaitu 10.0.0.0/16 atau prefix eksplisit kedua, lalu setujui prefix baru tersebut di console.

Ada jebakan serupa pada nameserver itu sendiri. Jika Anda menetapkan nameserver global di admin console pada alamat privat seperti 10.0.0.53, alamat tersebut harus berada dalam rute yang telah disetujui. Jika tidak, perangkat Anda sama sekali tidak dapat menjangkau resolver. Jika Anda mengaktifkan opsi yang mengesampingkan server DNS lokal saat mengarah ke resolver yang tidak dapat dijangkau, semua perangkat di tailnet akan kehilangan resolusi nama secara bersamaan, termasuk perangkat yang baru saja masih berfungsi. Iklankan dan setujui rute menuju resolver terlebih dahulu, kemudian ubah pengaturan DNS. Jika DNS di dalam tunnel adalah bagian yang terus bermasalah, cara DNS bermasalah melalui tunnel WireGuard membahas mekanisme yang sama tanpa lapisan koordinasi di atasnya.

Source NAT dan koneksi site-to-site

Secara default, subnet router mengubah alamat sumber setiap paket yang diteruskan menjadi alamat privatnya sendiri. Ini disebut SNAT (source network address translation). Fungsinya agar balasan dapat berjalan tanpa perubahan apa pun pada jaringan privat: database di 10.0.0.20 membalas VPS, yang sudah diketahui cara mengaksesnya. Konsekuensinya, database melihat setiap koneksi tailnet seolah-olah berasal dari VPS. Karena itu, aturan firewall berdasarkan sumber dan access log tidak memberikan informasi yang berguna.

Nonaktifkan SNAT di Linux jika Anda ingin alamat tailnet asli klien tetap dipertahankan:

sudo tailscale set --snat-subnet-routes=false

Host di jaringan privat kemudian memerlukan route kembali ke 100.64.0.0/10, yaitu rentang alamat yang ditetapkan Tailscale untuk perangkat, melalui subnet router. Tanpa route balik tersebut, balasan dikirim ke default gateway dan tidak pernah tiba. Akibatnya, koneksi berhenti setelah paket pertama. Tambahkan static route pada gateway jaringan privat, atau tetap aktifkan SNAT.

Koneksi site-to-site menggunakan dua subnet router secara bersamaan. Masing-masing mengiklankan jaringannya sendiri dan menerima jaringan milik router lainnya:

sudo tailscale up --advertise-routes=10.0.0.0/24 --snat-subnet-routes=false --accept-routes

Jalankan perintah yang sesuai pada router lainnya menggunakan rentangnya sendiri. Kedua rentang tersebut harus berbeda. Jika transfer berukuran besar berhenti sementara ssh dan ping berjalan normal, penyebabnya adalah MSS (maximum segment size), yaitu ukuran potongan data terbesar yang dibawa oleh paket TCP. Overhead tunnel membuat paket yang diteruskan terlalu besar untuk salah satu link di antara kedua endpoint. Clamping mengatasi masalah tersebut:

sudo iptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Simpan aturan tersebut dengan iptables-persistent, atau aturan itu akan hilang pada boot berikutnya.

Pemeliharaan agar tetap berjalan

Kunci node secara default kedaluwarsa setelah 180 days, sejak August 2026. Saat kunci pada subnet router kedaluwarsa, node keluar dan seluruh rentang yang diiklankan menjadi tidak dapat dijangkau, tanpa perubahan konfigurasi di mana pun yang dapat menjelaskannya. Nonaktifkan kedaluwarsa kunci untuk mesin ini pada halaman Machines di konsol admin, lalu catat bahwa Anda telah melakukannya.

Tailscale mengutamakan koneksi langsung antarpeer dan beralih ke server relay jika tidak dapat membuat koneksi tersebut. Relay tetap berfungsi, tetapi menambah latensi. VPS dengan alamat publik adalah kasus yang paling mudah: izinkan UDP masuk pada port 41641 agar sebagian besar peer dapat terhubung secara langsung. Jika ufw mengelola firewall, aturan ufw yang benar-benar diperlukan VPS menjelaskan sintaksnya.

Aturan akses adalah bagian lainnya. Pada tailnet default, setiap perangkat milik Anda dapat menjangkau perangkat lain, sehingga rute yang disetujui langsung berfungsi. Setelah Anda menulis kebijakan ACL, sisi tujuan aturan harus mencantumkan rentang privat, karena 10.0.0.20 bukan alamat tailnet dan tidak tercakup oleh aturan yang ditulis berdasarkan IP tailnet atau tag.

Terakhir, tentukan apakah Anda ingin menggunakan server koordinasi yang tidak Anda kelola sendiri. Control plane Tailscale adalah layanan terkelola. Kunci Anda tetap berada di mesin Anda, tetapi akun dan file kebijakan tersimpan di sana. Hal yang benar-benar dapat dilakukan seseorang dengan control plane yang disusupi atau kredensial login identitas yang dicuri adalah aspek yang perlu Anda selesaikan sebelum memberikan akses rute ke jaringan privat Anda, dan model kepercayaan Tailscale menunjukkan batas tersebut. Biaya jarang menjadi alasan orang meninggalkannya, karena paket gratis mencakup hingga enam pengguna dengan perangkat mereka sendiri tanpa batas, meskipun subnet router yang Anda aktifkan menggunakan tag dihitung secara berbeda dari subnet router yang masuk menggunakan akun Anda. Setelah melewati batas tersebut, tagihan dihitung berdasarkan orang, bukan mesin, sehingga biaya sebenarnya untuk rumah tangga atau tim beranggotakan lima orang setelah paket gratis habis perlu dihitung sebelum Anda menambahkan akun yang membuat batas itu terlampaui. Menjalankan Headscale, server control Tailscale yang di-hosting sendiri membuatnya tetap berada di VPS Anda sendiri, tetapi Anda harus memeliharanya. Jawaban lain untuk kekhawatiran yang sama adalah meninggalkan klien Tailscale juga, lalu menghosting sendiri server VPN NetBird menempatkan lapisan koordinasi dan klien mesh miliknya pada satu mesin yang Anda kendalikan. Jika Anda masih memilih antara model ini dan konfigurasi yang ditulis secara manual, perbandingan WireGuard dan Tailscale menjelaskan fungsi lapisan koordinasi serta biayanya.

FAQ

Apa perbedaan antara subnet router dan exit node?

Subnet router mengiklankan rentang alamat privat agar perangkat dalam tailnet dapat menjangkau mesin yang tidak menjalankan Tailscale. Exit node mengiklankan dirinya sebagai rute ke seluruh Internet, sehingga perangkat mengirim semua trafiknya melalui alamat publik node tersebut. Satu VPS dapat berfungsi sebagai keduanya. Keduanya menggunakan flag terpisah, --advertise-routes dan --advertise-exit-node, dan masing-masing memerlukan persetujuan sendiri di konsol admin.

Mengapa client Linux saya mengabaikan rute subnet yang diiklankan?

Client Linux tidak menerima rute subnet kecuali Anda memintanya. Jalankan sudo tailscale set --accept-routes pada client. Kemudian periksa dengan ip route show table 52, bukan ip route show. Tailscale memasang rute yang diterima di routing table 52 dan mencapainya melalui policy rules, sehingga main table tidak pernah mencantumkannya dan rute yang berfungsi tampak seperti hilang.

Subnet saya berhenti berfungsi setelah reboot. Apa yang rusak?

Kemungkinan besar IP forwarding. Nilai yang ditetapkan dengan sysctl -w tidak bertahan setelah reboot, jadi tuliskan nilai tersebut ke /etc/sysctl.d/99-tailscale.conf dan konfirmasikan dengan sysctl net.ipv4.ip_forward. Jika forwarding aktif dan rentang tersebut masih tidak dapat dijangkau, periksa node di konsol admin. Node key kedaluwarsa setelah 180 hari secara default, dan subnet router yang kedaluwarsa tampak seperti masalah jaringan, bukan masalah akun.

Dapatkah dua subnet router mengiklankan rentang yang sama?

Tidak untuk rentang yang identik. Rentang yang saling tumpang tindih dengan panjang prefix yang berbeda diperbolehkan, dan rute yang paling spesifik akan digunakan. Failover memerlukan perhatian: ketika router yang memegang prefix lebih spesifik offline, Tailscale tidak beralih ke rute yang lebih luas, sehingga trafik tersebut berhenti. Untuk pasangan standby yang sebenarnya, minta kedua router mengiklankan prefix spesifik yang sama.

Hostname berhasil di-resolve, tetapi koneksi mengalami timeout. Mengapa?

Resolusi DNS dan routing adalah dua tahap yang terpisah. Nama dapat di-resolve ke alamat yang tidak tercakup oleh rute yang disetujui, sehingga paket kemudian keluar melalui default gateway client. Jalankan ip route get <address> pada client. Jika jawabannya tidak menyertakan dev tailscale0, iklankan rentang yang mencakup alamat tersebut dan setujui prefix baru di konsol admin.