Mengapa laluan subnet Tailscale yang diluluskan masih tamat masa

Kelulusan dalam konsol pentadbir kelihatan seperti langkah terakhir, dan ia bukan. Aplikasi tamat masa dahulu, dan hanya selepas itu anda mendapati penghala dalam talian dan laluan diluluskan. Kelulusan ialah langkah pengedaran, bukan kebenaran dan bukan jaminan penghantaran. Empat peringkat mesti sejajar sebelum paket sampai ke hos di belakang penghala subnet, dan setiap satu boleh berjaya sementara yang seterusnya gagal. Lakukan mengikut urutan dan berhenti pada peringkat pertama yang tidak bertahan.

Empat peringkat, satu kegagalan

Penghala mengumumkan awalan, tailnet meluluskan pengumuman itu, klien menerima laluan yang diterimanya, dan dasar akses membenarkan sambungan tertentu. Itu empat keputusan berasingan oleh tiga komponen berbeza. Jadi laluan yang diluluskan hanya menyatakan bahawa rangkaian kini sebahagian daripada jadual penghalaan tailnet.

Peringkat keempat paling kerap dilangkau, kerana tiga yang pertama menghasilkan keadaan yang kelihatan. Kebenaran yang meliputi alamat tailnet penghala itu sendiri tidak meliputi subnet peribadi di belakangnya secara automatik. Itu destinasi berbeza, dan dasar dinilai mengikut destinasi.

Pada Linux peringkat ketiga juga mempunyai nilai lalai yang mengejutkan: menerima laluan subnet adalah pilihan. Beberapa klien GUI menerima laluan yang diumumkan secara lalai, jadi armada bercampur boleh menunjukkan satu mesin gagal sementara yang lain berfungsi.

Sahkan tetapan pada mesin yang gagal dan bukannya menganggap platform. Laluan itu tidak pernah menjadi bahagian yang hilang pada mesin yang berfungsi, jadi biarkan mesin itu membuktikan bahawa bahagian tailnet sihat. Dokumentasi Tailscale tentang penghala subnet merangkumi kelulusan, penerimaan laluan oleh klien dan peringkat dasar.

Semak laluan di tempat klien berjalan

Mula dengan klien yang gagal, bukan penghala. Sahkan laluan wujud dan tetapan klien membenarkan penerimaan laluan sama sekali.

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

Perintah pertama menunjukkan senarai rakan dan sama ada penghala subnet boleh dicapai, yang kedua mencetak keutamaan klien termasuk bendera penerimaan laluan, dan yang ketiga bertanya kepada kernel antara muka mana yang akan digunakan untuk hos sebenar pada subnet. Jika perintah terakhir itu menamakan antara muka fizikal dan bukan antara muka Tailscale, laluan itu tidak pernah masuk ke jadual. Laluan yang hilang ialah masalah sebelah klien, bukan masalah kelulusan. Betulkannya sebelum melihat dasar.

Untuk menerima laluan pada Linux, sambung semula dengan bendera itu dan bukannya menganggap ia sudah ditetapkan: tailscale up --accept-routes. Klien yang menyertai dengan bendera lain mengekalkannya sehingga diubah, jadi semak tetapan semasa sebelum menambah satu lagi. Menjalankan semula perintah pertama selepas perubahan sepatutnya menunjukkan laluan dalam jadual.

Buktikan penghantaran dan laluan balik

Kelulusan tidak mengkonfigurasi penghala untuk menghantar paket, dan tidak menguruskan balasan. Kedua-duanya hal peringkat hos di sebelah LAN penghala. Uji pada penghala, bukan pada 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 mesti melaporkan 1, jika tidak kernel akan membuang paket yang dihantar. Yang kedua menunjukkan sama ada penyamaran laluan subnet menulis semula sumber, iaitu tingkah laku lalai dan biasanya yang anda mahu. Yang ketiga menunjukkan sama ada permintaan sampai ke destinasi dan sama ada sesuatu kembali; permintaan tanpa balasan ialah masalah laluan balik, bukan masalah kelulusan. Baca ketiga-tiga hasil bersama sebelum mengubah mana-mana daripadanya.

Jika penyamaran telah dilumpuhkan, rangkaian destinasi memerlukan laluan balik ke alamat tailnet, dan setiap lompatan di antaranya mesti mengetahuinya. Menghidupkan semula penyamaran ialah pembetulan terpantas untuk satu perkhidmatan, dengan kos menyembunyikan alamat klien asal daripada destinasi. Pertukaran itu penting apabila destinasi merekod alamat sumber untuk audit, jadi putuskan dengan sengaja dan bukannya menukar bendera semasa insiden. Dokumentasikan pilihan yang anda buat, kerana orang seterusnya hanya akan melihat salah satu daripada dua tingkah laku.

Baca peraturan akses untuk sumber

Dengan laluan wujud dan penghantaran terbukti, syak yang tinggal ialah dasar. Baca kebenaran yang sepatutnya membenarkan sambungan dan semak destinasinya, bukan hanya sumbernya. Identiti klien sendiri juga mesti sepadan dengan pemilih dasar, jadi catatkannya 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

Output status mengenal pasti alamat klien sendiri dan rakan yang dilihatnya, dan itulah yang mesti sepadan dengan pemilih sumber dasar. tailscale ping membuktikan laluan tailnet ke penghala subnet itu sendiri; ia menyelesaikan nama rakan dan alamat tailnet, bukan hos di dalam subnet yang diumumkan. Perintah ketiga menghantar gema ICMP biasa melalui laluan subnet, jadi hasilnya menerangkan destinasi dan bukan penghala. Penolakan pada peringkat tailnet biasanya kembali sebagai penolakan, manakala paket yang keluar dan tidak pernah kembali tamat masa.

Nama yang gagal ialah soalan berbeza daripada alamat yang gagal; selesaikan hos secara langsung sebelum menyalahkan laluan. Tulis kebenaran mengikut keperluan sumber sebenar dan bukan seluruh subnet. Membuka seluruh /24 supaya satu aplikasi berfungsi ialah cara permintaan sempit menjadi kebenaran luas yang kemudiannya tiada siapa berani menarik balik.

Jika matlamatnya ialah keluar ke internet dan bukan subnet peribadi, komponen yang betul ialah nod keluar, bukan penghala subnet, dan dasar serta penghalaan berbeza mengikutnya. Semak keputusan itu sebelum meluaskan kebenaran. Nod keluar menukar laluan lalai; penghala subnet hanya mengumumkan awalan.