SSD Nodes Learn 🎉 VPS mulai $5.50/bln
Panduan Matt ConnorOleh Matt Connor · Diperbarui 2026-08-13

Cara Menjalankan Subnet Router Tailscale di VPS

Pelajari cara mengiklankan jaringan privat dari VPS ke tailnet, menyetujui rute, membuat IP forwarding bertahan setelah reboot, dan memakai --accept-routes di Linux.

Apa yang dilakukan subnet router Tailscale

Subnet router Tailscale 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: kumpulan perangkat yang masuk ke satu akun atau organisasi. Exit node adalah fitur yang sering disalahartikan sebagai subnet router, padahal tugasnya berlawanan. Exit node mengirimkan seluruh trafik 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 fitur kedua, baca cara menjalankan exit node Tailscale pada VPS. Keduanya menggunakan flag yang berbeda, dan satu VPS dapat menjalankan keduanya sekaligus, tetapi keduanya menyelesaikan masalah yang berbeda dan mengalami kegagalan dengan cara yang berbeda.

Saat VPS membutuhkan router subnet

Kasus yang umum adalah jaringan privat yang sudah diberikan oleh provider Anda. VPS memiliki alamat publik dan antarmuka kedua pada segmen privat. Server lain pada segmen tersebut sama sekali tidak memiliki alamat publik: database di 10.0.0.20 dan target pencadangan di 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 perlu diubah, dan database tetap tidak memiliki alamat publik.

Kasus lainnya adalah jaringan yang berada di sisi lain VPS. Jaringan LAN (local area network) di rumah atau kantor yang berada di belakang router sendiri, atau rak perangkat yang sama sekali tidak dapat menjalankan Tailscale, seperti switch terkelola atau NAS lama dengan firmware terkunci. Satu komputer Linux pada jaringan tersebut menjadi router subnet untuk semua perangkat lain di jaringan itu.

Kedua kasus tersebut memiliki satu persyaratan. Router subnet harus sudah dapat menjangkau rentang yang diiklankannya, menggunakan tabel routing dan firewall miliknya sendiri. Tailscale tidak membangun 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 tersebut. Konfirmasikan 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 pada tahap ini, yaitu ke router itu sendiri, 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 setelah reboot

Mesin Linux membuang setiap paket yang tidak ditujukan kepadanya sendiri jika penerusan belum aktif. Meneruskan paket mesin lain adalah fungsi utama router subnet, sehingga 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 berlaku dan hilang pada boot berikutnya. Akibatnya, router subnet berjalan selama berminggu-minggu, lalu berhenti pada pagi hari setelah reboot untuk upgrade kernel. Bagian yang membingungkan adalah tidak ada hal yang tampak rusak. tailscale status masih menampilkan node sebagai online, konsol admin masih menampilkan rute sebagai disetujui, dan klien masih memiliki rute tersebut. Paket tiba di VPS, lalu kernel membuangnya tanpa mencatat apa pun. Menulis nilai tersebut ke dalam /etc/sysctl.d/99-tailscale.conf akan membuatnya aktif kembali setelah reboot.

Jika Anda mengiklankan rute saat penerusan masih nonaktif, 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 keluaran perintah tersebut, jangan langsung melewatinya.

Iklankan rute

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

Pada VPS yang sudah login ke tailnet, ubah pengaturannya secara langsung:

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

Gunakan tailscale set untuk setiap perubahan berikutnya. Menjalankan kembali tailscale up dengan satu flag akan mengatur ulang flag yang tidak Anda cantumkan. CLI akan menghentikan proses dengan pesan error bahwa perubahan pengaturan dengan cara ini mengharuskan semua flag non-default dicantumkan. tailscale set mengubah satu pengaturan dan membiarkan pengaturan lainnya tetap.

Beberapa rentang harus 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 jaringan 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. Pesan error akan menyebutkan prefix yang kemungkinan Anda maksud. Untuk berhenti mengiklankan rute, tetapkan daftar kosong dengan sudo tailscale set --advertise-routes=.

Setujui rute di konsol admin

Mengiklankan rute adalah permintaan, bukan perubahan. Sebelum disetujui oleh admin, tidak ada client yang menerima rute tersebut dan tidak ada alamat dalam rentang itu yang dapat dijangkau. Ini memang dirancang demikian, karena mesin yang dapat menambahkan dirinya sendiri ke tabel routing semua orang dapat menangkap trafik untuk rentang mana 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 muncul sebagai belum disetujui, sedangkan prefix lama tetap berfungsi. Rute yang disetujui dan rute yang diabaikan terlihat sama dari VPS. 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 disetujui saat pertama kali diiklankan. Tag tersebut harus sudah ada di bagian tagOwners pada file kebijakan yang sama. Pengaturan ini berguna jika Anda membangun ulang VPS dari script, karena node hasil build ulang dianggap sebagai node baru dan rutenya kembali berstatus belum disetujui.

Mengapa klien Linux mengabaikan rute tanpa --accept-routes

Rute tersebut kini telah diiklankan dan disetujui. Ponsel dan Mac Anda dapat menjangkau 10.0.0.20. Laptop Linux Anda tidak dapat menjangkaunya, 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. Pada 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, pada Linux Anda harus mengaktifkannya secara eksplisit di 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 pada Linux tidak menempatkan rute yang diterima di tabel routing utama. Tailscale menempatkannya di tabel routing 52 dan memasang aturan kebijakan yang terlihat dengan ip rule show dalam rentang prioritas 5210 hingga 5270. Aturan tersebut mengirim paket yang tidak cocok ke tabel itu. Jadi, ip route show saja tidak akan pernah menampilkan 10.0.0.0/24, dan pembaca yang hanya memeriksa perintah tersebut akan menyimpulkan bahwa --accept-routes tidak melakukan apa pun. ip route show table 52 adalah perintah yang menampilkan kondisi sebenarnya, dan hasilnya 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 membuatnya mengirim trafik untuk subnet yang terhubung langsung melalui router lain, bukan melalui interface-nya sendiri. Pada router standby dalam pasangan high availability, biarkan --accept-routes tetap nonaktif dan hanya iklankan rute.

Mode kegagalan: dua router mengiklankan rentang yang 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 ke 10.0.0.20 diarahkan ke A.

Hal yang sering mengejutkan adalah perilakunya ketika A offline. Tailscale tidak beralih ke rute yang kurang spesifik. Trafik ke 10.0.0.20 berhenti, sedangkan trafik ke 10.1.0.20 tetap berjalan melalui B. Gejalanya tampak seperti separuh jaringan privat tidak aktif, dan penyebabnya adalah satu node offline yang masih memegang prefix yang lebih spesifik. Jika Anda memerlukan 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 ke sisi klien. Jika Anda berada di jaringan hotel pada 192.168.1.0/24 sementara subnet router Anda mengiklankan 192.168.1.0/24, keduanya bersaing untuk tujuan yang sama, dan rute yang menang bergantung pada platform. Di Linux, pasang aturan sebelum aturan milik Tailscale agar alamat lokal menggunakan tabel utama:

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

Aturan 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 nilai 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 merusak VPN WireGuard biasa yang Anda konfigurasikan secara manual, dengan alasan yang sama: rute lokal yang lebih spesifik akan menang, sehingga trafik tidak pernah masuk ke tunnel.

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

Bagian 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 menjadi 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 tahap terpisah, dan keduanya tidak saling memeriksa. Kemudian, paket menuju 10.0.5.20 tidak menemukan rute yang cocok pada tailnet, sehingga paket tersebut keluar melalui gateway default klien dan menghilang.

Gunakan dua perintah berikut untuk memisahkan kedua bagian tersebut:

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

Jika lookup mengembalikan sebuah 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 konsol.

Ada jebakan serupa pada nameserver itu sendiri. Jika Anda menetapkan nameserver global di konsol admin pada alamat privat seperti 10.0.0.53, alamat tersebut harus berada di dalam rute yang telah disetujui. Jika tidak, perangkat Anda tidak dapat menjangkau resolver sama sekali. Jika Anda mengaktifkan opsi yang mengambil alih server DNS lokal saat mengarahkannya ke resolver yang tidak dapat dijangkau, semua perangkat dalam tailnet akan kehilangan resolusi nama sekaligus, termasuk perangkat yang masih berfungsi sesaat sebelumnya. Iklankan dan setujui rute menuju resolver terlebih dahulu, kemudian ubah pengaturan DNS. Jika DNS di dalam tunnel terus menjadi masalah, cara DNS mengalami gangguan melalui tunnel WireGuard menjelaskan mekanisme yang sama tanpa lapisan koordinasi tambahan.

NAT Sumber dan koneksi site-to-site

Secara default, router subnet mengubah alamat sumber setiap paket yang diteruskan menjadi alamat privatnya sendiri. Ini disebut SNAT (source network address translation). SNAT digunakan agar balasan dapat berfungsi tanpa perubahan apa pun pada jaringan privat: database di 10.0.0.20 membalas VPS, yang sudah diketahui cara mencapainya oleh database tersebut. Konsekuensinya, database melihat semua 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 pada 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 biarkan SNAT tetap aktif.

Koneksi site-to-site menggunakan dua subnet router yang melakukan konfigurasi ini 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 command yang sesuai pada router lain menggunakan rentangnya sendiri. Kedua rentang tersebut harus berbeda. Jika transfer berukuran besar berhenti sementara ssh dan ping berfungsi normal, penyebabnya adalah MSS (maximum segment size), yaitu ukuran maksimum data yang dibawa oleh satu paket TCP. Overhead tunnel membuat paket yang diteruskan terlalu besar untuk salah satu link di sepanjang jalur. Clamping mengatasi masalah ini:

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

Simpan rule tersebut dengan iptables-persistent. Jika tidak, rule akan hilang saat boot berikutnya.

Pemeliharaan agar layanan tetap berjalan

Secara default, kunci node kedaluwarsa setelah 180 hari, mulai Agustus 2026. Saat kunci pada router subnet 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 antar-peer dan beralih ke server relay jika koneksi langsung tidak dapat dibuat. 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 firewall dikelola oleh ufw, 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 suatu 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 ter-host. Kunci Anda tetap berada di mesin Anda, tetapi akun dan file kebijakan tersimpan di sana. Menjalankan Headscale, server kontrol Tailscale yang di-host sendiri menyimpan komponen tersebut di VPS Anda sendiri, dengan konsekuensi Anda harus memeliharanya. Jawaban lain untuk kekhawatiran yang sama adalah tidak menggunakan klien Tailscale, lalu meng-host sendiri server VPN NetBird menempatkan lapisan koordinasi dan klien mesh-nya pada satu mesin yang Anda kendalikan. Jika Anda masih mempertimbangkan model ini dibandingkan konfigurasi yang ditulis secara manual, perbandingan WireGuard dan Tailscale menjelaskan manfaat lapisan koordinasi dan biaya yang ditimbulkannya.

FAQ

Apa perbedaan antara subnet router dan exit node?

Subnet router mengiklankan rentang alamat privat agar perangkat 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 menjalankan 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 secara otomatis. Jalankan sudo tailscale set --accept-routes pada client. Kemudian periksa menggunakan ip route show table 52, bukan ip route show. Tailscale memasang rute yang diterima pada routing table 52 dan menjangkaunya melalui policy rules, sehingga main table tidak pernah mencantumkan rute tersebut dan rute yang berfungsi tampak seperti hilang.

Subnet saya berhenti berfungsi setelah reboot. Apa penyebabnya?

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

Dapatkah dua subnet router mengiklankan rentang yang sama?

Tidak untuk rentang yang identik. Rentang yang tumpang tindih dengan panjang prefix berbeda diperbolehkan, dan rute yang paling spesifik akan dipilih. Failover memerlukan perhatian: ketika router yang memiliki 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, lalu paket 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.