Mengapa Koneksi Tailscale Lambat: Relay vs Langsung

Mengapa Tailscale lambat: koneksi melalui relay, bukan koneksi langsung

Tailscale lambat ketika koneksi diteruskan melalui salah satu server DERP bersama, dan kecepatannya mendekati kapasitas jalur ketika koneksi berlangsung secara langsung. Koneksi langsung membawa paket WireGuard terenkripsi langsung dari satu mesin ke mesin lainnya, sehingga kecepatannya bergantung pada kapasitas yang dapat disediakan oleh kedua koneksi Internet tersebut. Koneksi melalui relay mengirim setiap paket melalui mesin ketiga terlebih dahulu, sehingga koneksi tersebut mewarisi latensi mesin itu serta bagian bandwidth yang tersedia untuk Anda. Besarnya dampak bergantung pada relay yang digunakan. Tailscale menyebut server DERP-nya “umumnya lebih lambat daripada koneksi langsung”, sedangkan relay peer yang Anda jalankan sendiri “biasanya lebih cepat daripada DERP” dan, dalam pengujian awal Tailscale, mencapai throughput yang “mendekati koneksi langsung”. Halaman performa Tailscale merangkum aturan umumnya dalam satu kalimat: “Koneksi langsung hampir selalu menghasilkan latensi yang lebih rendah dan throughput yang lebih tinggi.”

Tidak ada apa pun di dalam aplikasi Anda yang menunjukkan perbedaan ini. Penyalinan file hanya terasa lambat, dan sesi SSH hanya terasa tersendat. Jadi, langkah pertama adalah mengetahui jenis koneksi yang sedang digunakan. Dua perintah dapat menjawabnya dalam waktu kurang dari satu menit, dan semua langkah setelah itu berfokus pada memperbaiki penyebabnya. Bagian penyiapan ini perlu dipahami sebelum Anda mulai, karena server koordinasi dan data plane WireGuard merupakan sistem yang terpisah dan hanya data plane yang memindahkan byte Anda.

Dua perintah untuk membedakan koneksi langsung dan relay

Kirimkan beberapa trafik ke peer sebelum melakukan pengukuran. Tailscale membangun path sesuai permintaan, sehingga peer yang belum Anda hubungi hari ini mungkin belum menegosiasikan path. Jika langsung mengukur, Anda dapat membaca hasil yang sudah kedaluwarsa. Satu ping atau satu curl ke alamat tailnet peer sudah cukup.

tailscale status

Jawabannya berada di akhir baris setiap peer.

100.113.160.82 device-a  tagged-devices linux   active; offers exit node; direct 203.0.113.9:41641
100.104.93.78  device-b  you@           android active; relay "tor"

direct yang diikuti alamat dan port berarti paket dikirim langsung ke alamat tersebut. relay "tor" menunjukkan server DERP (designated encrypted relay for packets), yaitu salah satu mesin relay Tailscale. Semua paket ke peer tersebut melewati server itu. Nilai ketiga, peer-relay, dibahas pada bagian berikutnya.

tailscale ping device-b

Koneksi yang sehat biasanya dimulai melalui relay lalu beralih. Paket pertama melewati server DERP terdekat saat kedua mesin melakukan negosiasi. Setelah itu, path berubah:

pong from device-b (100.113.160.82) via DERP(tor) in 51ms
pong from device-b (100.113.160.82) via DERP(tor) in 48ms
pong from device-b (100.113.160.82) via 203.0.113.9:41641 in 35ms

Perintah tersebut berhenti di sana karena --until-direct secara default bernilai true. Koneksi yang tidak dapat beralih ke koneksi langsung akan terlihat seperti berikut. Perintah tersebut berakhir dengan sebuah kalimat, bukan pong:

pong from device-b (100.104.93.78) via DERP(tor) in 53ms
pong from device-b (100.104.93.78) via DERP(tor) in 60ms
direct connection not established

Baris terakhir itu adalah hasilnya. Artinya, Tailscale telah mengirim semua probe yang akan dikirimnya, tetapi tidak pernah mendapatkan path langsung. Untuk terus memantau path relay tanpa berhenti pada koneksi langsung pertama, jalankan tailscale ping --until-direct=false -c 20 device-b dan baca variasi latensinya. Path relay biasanya menunjukkan angka yang lebih tinggi dan variasi yang lebih besar karena path tersebut menggabungkan dua jalur Internet melalui mesin yang tidak Anda kendalikan.

Apa arti peer-relay dalam status tailscale?

Peer relay adalah mesin di tailnet Anda sendiri yang meneruskan trafik untuk anggota lain ketika koneksi langsung tidak dapat dibuat. Mesin ini mendengarkan pada port UDP yang Anda pilih, dan daemon akan menggunakannya sebelum DERP. tailscale status menandai koneksi seperti ini peer-relay, sedangkan tailscale ping menampilkan endpoint relay tersebut:

pong from device-b (100.97.143.93) via peer-relay(203.0.113.42:40000:vni:1) in 4ms
direct connection not established

Perhatikan bagian itu. Koneksi tersebut tetap bukan koneksi langsung, sehingga prosesnya tetap berakhir dengan direct connection not established. Yang berubah adalah pihak yang meneruskan trafik. VPS dengan alamat IP publik dan alokasi bandwidth yang besar merupakan relay yang jauh lebih baik untuk trafik Anda sendiri dibandingkan node DERP bersama. Karena itu, fitur ini penting bagi siapa pun yang menyewa server. Aktifkan fitur tersebut pada mesin yang memiliki endpoint publik yang dapat diakses:

sudo tailscale set --relay-server-port=40000

Port 0 memilih port acak yang belum digunakan, sedangkan string kosong menonaktifkan relay server. Selanjutnya, berikan izin kepada perangkat klien untuk menggunakannya melalui capability tailscale.com/cap/relay dalam file kebijakan tailnet Anda:

{
  "grants": [
    {
      "src": ["tag:us-east-vpc"],
      "dst": ["tag:us-east-relays"],
      "app": {
        "tailscale.com/cap/relay": []
      }
    }
  ]
}

Perangkat relay dan perangkat klien harus menggunakan Tailscale 1.86 atau yang lebih baru. Jadi, periksa dengan tailscale version pada masing-masing perangkat sebelum menghabiskan waktu satu jam untuk mengatur file kebijakan. Urutan percobaan daemon perlu diingat. Daemon mencoba koneksi langsung terlebih dahulu. Jika gagal, daemon mencari peer relay yang diizinkan untuk digunakan. Jika tidak ada, daemon beralih ke DERP. DERP tidak pernah sepenuhnya tidak digunakan karena DERP juga menjadi saluran yang digunakan kedua mesin untuk melakukan negosiasi sejak awal.

Penyebab 1: firewall egress yang memblokir UDP

Tailscale mendokumentasikan dua alasan koneksi tetap menggunakan relay. Alasan pertama adalah UDP yang diblokir. Tanyakan langsung kepada mesin:

tailscale netcheck

Laporan tersebut dipangkas di sini. Field paling atas adalah bagian yang menentukan semuanya:

Report:
  * UDP: true
  * IPv4: yes, 203.0.113.9:41641
  * IPv6: no
  * MappingVariesByDestIP: false
  * PortMapping:
  * Nearest DERP: Dallas

UDP: false adalah petunjuk terkuat yang akan Anda dapatkan. Artinya, mesin tidak dapat mengirim paket UDP ke server probe Tailscale. Referensi CLI Tailscale sendiri menyatakan bahwa dalam kondisi tersebut, "it's unlikely Tailscale will be able to make point-to-point connections." Trafik kemudian melewati DERP melalui TCP port 443. Fallback ini membuat mesin tetap terlihat sehat: mesin tetap terhubung, dapat dijangkau, dan setiap byte diteruskan melalui relay. netcheck menjelaskan jaringan, bukan satu koneksi tertentu. Karena itu, pastikan jalur yang benar-benar digunakan oleh sebuah peer dengan tailscale status atau tailscale ping sebelum Anda mulai mengubah aturan.

Ada dua aturan keluar yang didokumentasikan. "Let your internal devices start UDP from :41641 to *:*", yaitu trafik WireGuard itu sendiri, dan "Let your internal devices start UDP to *:3478", yaitu STUN (session traversal utilities for NAT), protokol yang digunakan mesin untuk mengetahui alamat dan port publiknya sendiri. Gunakan wildcard untuk tujuan. Tailscale menambahkan server relay seiring waktu, dan daftar alamat yang ditulis manual akan keliru dalam waktu satu tahun.

Pada server sewaan, penyebab yang paling umum adalah kebijakan egress yang terlalu ketat. Kebijakan tersebut dapat berasal dari image yang diperkuat keamanannya atau diterapkan oleh provider di jaringan upstream. Periksa kebijakan keluar default terlebih dahulu:

sudo ufw status verbose
sudo nft list ruleset

Default: deny (incoming), allow (outgoing) tidak bermasalah. Default keluar sebesar deny dengan daftar izin singkat yang hanya mencakup TCP 443 dan DNS akan membuat server terus menggunakan relay. Jalur DERP melalui TCP 443 dapat melewati celah tersebut, sedangkan jalur langsung tidak. Lokasi aturan tersebut bergantung pada apakah mesin menggunakan iptables atau nftables di lapisan bawah. Mengedit firewall yang salah adalah penyebab umum perubahan tidak berdampak apa pun.

Sisi inbound juga penting. VPS memiliki alamat IP publik sehingga dapat menjadi sisi yang mudah dijangkau dalam pasangan koneksi. Jika firewall menerima UDP inbound pada port tempat tailscaled melakukan listen, peer di balik router rumah yang bermasalah dapat menjangkaunya tanpa konfigurasi tambahan. Cari port yang benar-benar digunakan:

sudo ss -lunp | grep tailscaled
sudo ufw allow 41641/udp

41641 adalah port statis default. Tailnet dengan pengaturan randomizeClientPort yang aktif membuat klien memilih port acak. Dalam kondisi tersebut, ambil nomor sebenarnya dari output ss, bukan dari halaman ini. Selanjutnya, periksa control panel provider Anda. Sebagian besar host menjalankan network firewall yang terpisah dari firewall di dalam server. Aturan yang Anda tambahkan dengan ufw tidak memengaruhi firewall tersebut.

Penyebab 2: hard NAT pada salah satu atau kedua sisi

Penyebab kedua yang terdokumentasi adalah hard NAT. NAT (network address translation) adalah proses ketika router mengubah alamat privat Anda menjadi alamat publik. Router yang bersifat ramah mempertahankan port publik yang sama untuk socket internal tertentu, terlepas dari pihak yang Anda hubungi. Mekanisme ini disebut endpoint independent mapping. Hard NAT memberikan port publik yang berbeda untuk setiap tujuan. Akibatnya, alamat yang dipelajari mesin dari server STUN bukan alamat yang dapat digunakan oleh peer. Tailscale melaporkan kondisi ini dalam netcheck sebagai MappingVariesByDestIP: true.

Satu hard NAT masih dapat ditangani. Jika sisi lain memiliki endpoint publik yang stabil, mesin di balik hard NAT masih dapat membuat koneksi masuk dan membentuk jalur. Dua hard NAT sekaligus menyebabkan koneksi gagal karena tidak ada sisi yang dapat memprediksi port tempat sisi lainnya akan muncul.

Pada VPS dengan alamat publik IPv4, kolom ini biasanya harus berisi false. Alamat publik tidak selalu berarti tidak ada proses translasi: AWS, misalnya, mendokumentasikan bahwa internet gateway-nya melakukan NAT satu-ke-satu antara alamat publik IPv4 instance dan alamat privatnya. Pemetaan statis satu-ke-satu seperti ini mempertahankan port yang sama, terlepas dari pihak yang Anda hubungi. Jadi, kondisi tersebut bukan hard NAT dan kolomnya tetap berisi false. Jika kolom tersebut berisi true pada server yang Anda sewa, berarti ada komponen dalam jaringan provider yang memberikan port berbeda untuk setiap tujuan. Tidak ada firewall rule di dalam mesin yang dapat mengubah kondisi ini. Pilihan Anda adalah menempatkan peer relay pada mesin yang memiliki endpoint publik yang bersih atau memindahkan workload. Kondisi ini juga merupakan alasan mengiklankan range privat Anda dari subnet router bermanfaat, karena Anda hanya memerlukan satu jalur yang baik menuju jaringan tersebut, bukan jalur yang baik menuju setiap perangkat di dalamnya.

Mengapa exit node membuat Tailscale terlihat lebih lambat daripada kondisi sebenarnya

Exit node menambahkan hop kedua, dan pembaca sering menyalahkan tunnel. Saat exit node dipilih, request meninggalkan laptop Anda, melewati tunnel menuju VPS, meninggalkan VPS menuju Internet publik, lalu respons kembali melalui jalur yang sama. Bahkan koneksi yang sepenuhnya langsung ke VPS tersebut tidak dapat membuat total kecepatan melebihi uplink VPS itu sendiri, dan jarak tambahan terlihat pada setiap pemuatan halaman.

Ukur kedua bagian tersebut secara terpisah. Nonaktifkan exit node, lalu uji tunnel secara langsung ke alamat tailnet VPS:

sudo tailscale set --exit-node=
sudo apt install -y iperf3
iperf3 -s

Jalankan iperf3 -c 100.113.160.82 dari client ke alamat tailnet tersebut. Nilai itu menunjukkan kecepatan tunnel Anda. Aktifkan kembali exit node dengan sudo tailscale set --exit-node=100.113.160.82, lalu jalankan speed test biasa ke Internet publik. Nilai itu menunjukkan gabungan tunnel dan uplink VPS. Jika nilai pertama baik, tetapi nilai kedua buruk, Tailscale bukan masalahnya. Periksa jaringan dan kapasitas exit node itu sendiri. tailscale exit-node list menampilkan node yang tersedia jika Anda tidak yakin node mana yang dipilih.

CPU adalah faktor lain yang membatasi kapasitas exit node. Panduan Tailscale menyarankan penggunaan generasi CPU yang lebih baru dengan clock speed lebih tinggi daripada jumlah core yang lebih besar. Jadi, paket dengan lebih banyak vCPU tidak otomatis lebih cepat dalam kasus ini. Pada host bersama yang sibuk, CPU yang dijanjikan kepada Anda belum tentu CPU yang benar-benar Anda dapatkan. steal time dari noisy neighbour terlihat sebagai throughput yang berubah-ubah setiap jam tanpa perubahan apa pun di sisi Anda.

Satu pengaturan utama: rx-udp-gro-forwarding

Tailscale mendokumentasikan satu pengaturan Linux yang berlaku pada mesin yang meneruskan trafik, yaitu exit node dan subnet router. Client biasa tidak memperoleh manfaat dari pengaturan ini. Pengaturan ini memerlukan Tailscale 1.54 atau yang lebih baru dan kernel Linux 6.2 atau yang lebih baru. Pastikan keduanya terpenuhi sebelum mengubah apa pun:

tailscale version
uname -r

Setelah itu, aktifkan penerusan UDP GRO (generic receive offload) pada interface yang menghadap ke Internet:

NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")
sudo ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list off

Pastikan pengaturan berhasil diterapkan:

ethtool -k $NETDEV | grep -E 'rx-udp-gro-forwarding|rx-gro-list'

Anda seharusnya melihat rx-udp-gro-forwarding: on dan rx-gro-list: off. Pengaturan ini membantu karena trafik Tailscale menggunakan UDP. Dengan membiarkan kernel mempertahankan paket UDP kecil dalam bentuk gabungan selama proses forwarding, daemon menangani lebih sedikit segmen yang lebih besar untuk jumlah byte yang sama. ethtool -K tidak bertahan setelah reboot, jadi jadikan pengaturan ini persisten. Pada sistem yang menggunakan networkd-dispatcher:

printf '#!/bin/sh\n\nethtool -K %s rx-udp-gro-forwarding on rx-gro-list off \n' "$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")" | sudo tee /etc/networkd-dispatcher/routable.d/50-tailscale
sudo chmod 755 /etc/networkd-dispatcher/routable.d/50-tailscale

Jalankan script tersebut sekali secara manual, lalu pastikan exit status-nya adalah 0. Node forwarding juga harus mengaktifkan IP forwarding terlebih dahulu. Pengaturan ini terpisah dan kegagalannya juga terpisah:

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

MTU apa yang digunakan oleh antarmuka tailscale0 Anda?

Jangan menebak angka ini. Baca nilainya langsung dari mesin:

ip link show tailscale0

Nilai mtu pada output tersebut adalah nilai yang benar-benar digunakan tunnel Anda. Nilai itu lebih kecil daripada 1500 yang dilaporkan oleh antarmuka ethernet Anda. Hal ini disengaja, bukan bug. Setiap paket yang Anda kirim di dalam tunnel dibungkus dengan header IP luar berukuran 20 byte untuk IPv4 atau 40 byte untuk IPv6, header UDP berukuran 8 byte, serta framing WireGuard dan tag autentikasi berukuran 32 byte. Semua komponen tersebut harus muat dalam kapasitas jalur jaringan yang sebenarnya. Tailscale kemudian memilih nilai yang cukup rendah agar tetap berfungsi pada link yang tidak dapat membawa paket penuh berukuran 1500 byte. Ini termasuk koneksi PPPoE, beberapa jaringan seluler, dan tunnel IPv6.

Gejala masalah MTU bersifat spesifik. Karena itu, jangan mendiagnosisnya hanya berdasarkan koneksi yang lambat. SSH tetap responsif, ping berfungsi, tetapi transfer berukuran besar atau halaman HTTPS besar berhenti sepenuhnya, bukan hanya berjalan lambat. Pola ini menunjukkan bahwa paket yang terlalu besar dibuang di suatu titik, tanpa pesan ICMP yang kembali untuk memberi tahu pengirim. Menaikkan MTU tailscale0 mendekati 1500 justru memperburuk masalah karena paket yang sebelumnya sudah tidak muat menjadi lebih besar. Solusi sebenarnya adalah menemukan MTU jalur yang berfungsi dengan metode bisection dan membatasi TCP MSS pada router yang meneruskan trafik tersebut. Jenis koneksi tidak mengubah hal ini: jalur relay dan jalur langsung menggunakan MTU antarmuka yang sama.

FAQ

Bagaimana cara mengetahui apakah koneksi Tailscale saya langsung atau melalui relay?

Jalankan tailscale status dan baca bagian akhir baris peer tersebut. direct 203.0.113.9:41641 berarti koneksi langsung, relay "tor" berarti setiap paket melewati server DERP tersebut, dan peer-relay berarti paket melewati mesin dalam tailnet Anda sendiri. Untuk pemeriksaan kedua, jalankan tailscale ping <peer>: jalur yang sehat dimulai di DERP, kemudian menampilkan pong dengan alamat dan port biasa, sedangkan jalur relay menampilkan pong DERP hingga proses berakhir dengan direct connection not established. Kirimkan trafik ke peer tersebut terlebih dahulu karena Tailscale hanya membangun jalur saat diperlukan.

Mengapa VPS saya tidak pernah mendapatkan koneksi langsung?

Jalankan tailscale netcheck pada VPS. Jika hasilnya UDP: false, UDP keluar tidak dapat diteruskan, biasanya karena firewall egress, dan menurut Tailscale koneksi point-to-point kemungkinan tidak dapat dibuat. Konfirmasikan dengan tailscale status atau tailscale ping bahwa peer berada di DERP. DERP berjalan melalui TCP 443, sehingga mesin tetap terlihat terhubung. Izinkan UDP keluar dari port 41641 ke tujuan mana pun dan UDP keluar ke tujuan mana pun pada port 3478. Periksa firewall jaringan provider dan firewall di dalam server karena keduanya merupakan kontrol yang terpisah. Aturan ufw tidak memengaruhi firewall milik provider.

Apakah koneksi Tailscale melalui relay kurang aman daripada koneksi langsung?

Tidak. Server DERP meneruskan paket WireGuard yang tidak dapat didekripsinya karena kunci enkripsi dibuat pada perangkat Anda dan tidak pernah meninggalkan perangkat tersebut. Dampak relay adalah latensi dan throughput, bukan kerahasiaan. Hal yang dikendalikan server koordinasi adalah perangkat mana yang dapat saling mengetahui. Pemisahan antara material kunci dan metadata koneksi perlu dipahami sebelum Anda memutuskan seberapa banyak komponen yang akan di-self-host.

Apakah pengaturan rx-udp-gro-forwarding membantu setiap mesin?

Tidak. Pengaturan ini didokumentasikan untuk mesin Linux yang meneruskan trafik bagi mesin lain, yaitu exit node dan subnet router. Laptop atau server yang hanya berkomunikasi dengan peer miliknya sendiri tidak memperoleh manfaat dari pengaturan ini. Pengaturan ini juga memerlukan Tailscale 1.54 atau yang lebih baru serta Linux kernel 6.2 atau yang lebih baru. Karena itu, periksa tailscale version dan uname -r terlebih dahulu. Ingat bahwa ethtool -K kembali ke nilai awal setelah reboot jika tidak dibuat persisten.

Apakah Tailscale lebih lambat daripada WireGuard biasa?

Keduanya menggunakan WireGuard untuk mengenkripsi trafik Anda. Tailscale menambahkan proses penyiapan koneksi yang pada WireGuard biasa harus Anda lakukan secara manual. Proses tersebut terkadang membuat koneksi menggunakan relay. WireGuard biasa tidak memiliki relay. Koneksi akan tersambung langsung atau gagal tersambung sama sekali. Karena itu, bandingkan kondisi yang setara dan lakukan benchmark Tailscale hanya ketika tailscale status menyatakan direct. Jika Anda ingin menggunakan versi yang dikonfigurasi secara manual sebagai pembanding, server WireGuard yang Anda bangun sendiri memerlukan sekitar empat puluh baris konfigurasi. Trade-off tersebut dibahas dalam perbandingan kedua pendekatan tersebut.