Mengapa rute subnet Tailscale yang disetujui masih kehabisan waktu

Persetujuan di konsol admin tampak seperti langkah terakhir, dan memang bukan. Aplikasi kehabisan waktu lebih dulu, dan baru setelah itu Anda menemukan router daring dan rute disetujui. Persetujuan adalah langkah distribusi, bukan izin dan bukan jaminan penerusan. Empat tahap harus sejajar sebelum paket mencapai host di belakang router subnet, dan masing-masing bisa berhasil sementara tahap berikutnya gagal. Kerjakan berurutan dan berhenti pada tahap pertama yang tidak bertahan.

Empat tahap, satu kegagalan

Router mengumumkan prefiks, tailnet menyetujui pengumuman itu, klien menerima rute yang diterimanya, dan kebijakan akses mengizinkan koneksi tertentu. Itu empat keputusan terpisah yang diambil oleh tiga komponen berbeda. Jadi rute yang disetujui hanya menyatakan bahwa jaringan kini menjadi bagian tabel perutean tailnet.

Tahap keempat paling sering dilewati, karena tiga tahap pertama menghasilkan status yang terlihat. Pemberian izin yang mencakup alamat tailnet router itu sendiri tidak otomatis mencakup subnet privat di belakangnya. Itu tujuan yang berbeda, dan kebijakan dievaluasi per tujuan.

Di Linux tahap ketiga juga punya nilai bawaan yang mengejutkan: menerima rute subnet bersifat opsional. Beberapa klien GUI menerima rute yang diumumkan secara bawaan, jadi armada campuran dapat menunjukkan satu mesin gagal sementara sisanya berfungsi.

Konfirmasi pengaturan pada mesin yang gagal alih-alih mengasumsikan platform. Rute tidak pernah menjadi bagian yang hilang pada mesin yang berfungsi, jadi biarkan mesin itu membuktikan bahwa sisi tailnet sehat. Dokumentasi Tailscale tentang router subnet mencakup persetujuan, penerimaan rute oleh klien, dan tahap kebijakan.

Periksa rute di tempat klien berjalan

Mulai dari klien yang gagal, bukan dari router. Pastikan rute ada dan pengaturan klien sama sekali mengizinkan penerimaan rute.

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

Perintah pertama menampilkan daftar peer dan apakah router subnet dapat dijangkau, yang kedua mencetak preferensi klien termasuk tanda penerimaan rute, dan yang ketiga menanyakan kepada kernel antarmuka mana yang akan dipakai untuk host nyata di subnet. Jika perintah terakhir itu menyebut antarmuka fisik alih-alih antarmuka Tailscale, rute tidak pernah masuk ke tabel. Rute yang hilang adalah masalah sisi klien, bukan masalah persetujuan. Perbaiki sebelum melihat kebijakan.

Untuk menerima rute di Linux, sambungkan ulang dengan tanda itu alih-alih mengasumsikan sudah disetel: tailscale up --accept-routes. Klien yang bergabung dengan tanda lain menyimpannya sampai diubah, jadi periksa pengaturan saat ini sebelum menambahkan yang lain. Menjalankan ulang perintah pertama setelah perubahan seharusnya menunjukkan rute di tabel.

Buktikan penerusan dan jalur kembali

Persetujuan tidak mengonfigurasi router untuk meneruskan paket, dan tidak mengatur balasannya. Keduanya urusan tingkat host di sisi LAN router. Ujilah di router, bukan di klien.

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

Perintah pertama harus melaporkan 1, atau kernel akan membuang paket yang diteruskan. Yang kedua menunjukkan apakah penyamaran rute subnet menulis ulang sumber, yang merupakan perilaku bawaan dan biasanya yang Anda inginkan. Yang ketiga menunjukkan apakah permintaan mencapai tujuan dan apakah ada yang kembali; permintaan tanpa jawaban adalah masalah jalur kembali, bukan masalah persetujuan. Baca ketiga hasil bersama sebelum mengubah salah satunya.

Jika penyamaran dinonaktifkan, jaringan tujuan memerlukan rute kembali ke alamat tailnet, dan setiap hop di antaranya harus mengetahuinya. Menyalakan kembali penyamaran adalah perbaikan tercepat untuk satu layanan, dengan biaya menyembunyikan alamat klien asli dari tujuan. Pertukaran itu penting ketika tujuan mencatat alamat sumber untuk audit, jadi putuskan dengan sengaja alih-alih membalik tanda saat insiden. Dokumentasikan pilihan yang Anda ambil, karena orang berikutnya hanya akan melihat salah satu dari dua perilaku.

Baca aturan akses untuk sumber daya

Dengan rute ada dan penerusan terbukti, tersangka yang tersisa adalah kebijakan. Baca pemberian izin yang seharusnya mengizinkan koneksi dan periksa tujuannya, bukan hanya sumbernya. Identitas klien sendiri juga harus cocok dengan pemilih kebijakan, jadi catat dari mesin yang sama yang gagal.

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

Keluaran status mengidentifikasi alamat klien sendiri dan peer yang dilihatnya, dan itulah yang harus cocok dengan pemilih sumber kebijakan. tailscale ping membuktikan jalur tailnet ke router subnet itu sendiri; ia menyelesaikan nama peer dan alamat tailnet, bukan host di dalam subnet yang diumumkan. Perintah ketiga mengirim gema ICMP biasa melalui rute subnet, jadi hasilnya menggambarkan tujuan alih-alih router. Penolakan di tingkat tailnet biasanya kembali sebagai penolakan, sedangkan paket yang keluar dan tidak pernah kembali kehabisan waktu.

Nama yang gagal adalah pertanyaan berbeda dari alamat yang gagal; selesaikan host secara langsung sebelum menyalahkan rute. Tulis pemberian izin sesuai kebutuhan sumber daya yang sebenarnya, bukan seluruh subnet. Membuka seluruh /24 agar satu aplikasi berfungsi adalah cara permintaan sempit menjadi izin luas yang kemudian tidak berani dicabut siapa pun.

Jika tujuannya adalah keluar ke internet dan bukan subnet privat, komponen yang benar adalah node keluar, bukan router subnet, dan kebijakan serta peruteannya berbeda sesuai itu. Periksa keputusan itu sebelum memperluas pemberian izin. Node keluar mengubah rute bawaan; router subnet hanya mengumumkan prefiks.