Kill switch setelah beralih dari Wi-Fi ke seluler: apa yang rusak

Suatu saat laptop ada di Wi-Fi kantor, saat berikutnya terhubung ke ponsel, dan indikator terowongan kembali hijau sebelum Anda selesai berpindah jendela. Lampu hijau hanya melaporkan bahwa terowongan tersambung lagi; apa yang dilakukan kebijakan perutean dan pemblokiran selama jeda itu pertanyaan lain. Kebijakan itu adalah sekumpulan kondisi pencocokan yang dikompilasi saat terakhir dipasang, dan menyebut antarmuka, alamat, serta keluarga alamat yang baru saja dihapus oleh peralihan. Karena itu peralihan yang sama menghasilkan tiga hasil yang tampak identik: pemblokiran berlanjut, kebijakan memblokir pemulihannya sendiri, atau terbuka jalur yang tidak dicakup apa pun.

Tidak ada yang di layar memisahkan ketiga keadaan itu, jadi tanyakan pengenal mana yang dipakai untuk memaku aturan, bukan warna apa yang ditunjukkan indikator. Di Linux sebuah aturan dapat menyebut antarmuka atau ipset yang diisi darinya; di Android sebuah VpnService dapat diberi tahu jaringan dasar mana yang harus diikuti melalui setUnderlyingNetworks. Setiap ikatan menunjuk ke tautan yang akan segera diganti, dan setiap ikatan harus dievaluasi ulang sesudahnya.

Apa yang sebenarnya ditulis ulang oleh peralihan

Ketika tautan lama hilang, kernel menghapus alamatnya, menarik kembali rute yang mengarah melewatinya, dan membangun ulang pemilihan alamat sumber dari yang tersisa. Rute default pindah ke gateway baru, dan indeks antarmuka yang dirujuk aturan lama sudah hilang atau didaur ulang untuk perangkat lain. Resolver per tautan juga disegarkan, meski tidak pada saat yang sama dengan rute. Semua ini terjadi di bawah klien VPN, sehingga klien yang hanya memantau keadaan terowongannya sendiri tidak melihatnya.

Masalahnya adalah aturan mengodekan pengenal tertentu alih-alih maksud di baliknya. Aturan yang membuang semua yang tidak keluar melalui antarmuka terowongan mengodekan nama antarmuka; aturan yang mengizinkan titik akhir mengodekan alamat yang mungkin dirutekan jaringan baru ke tempat lain. Ketika pengenal hilang, aturan tidak menjadi tampak salah: ia berhenti cocok dengan apa pun atau mulai cocok dengan hal yang salah.

Membangun ulang terowongan luar tanpa melubangi

Transport luar terikat pada alamat sumber lama, jadi ia harus membuka soket baru dari alamat baru. Ketika titik akhir adalah nama host dan bukan alamat literal, pencarian harus berhasil selama pemblokiran masih berlaku. Inilah perangkap urutan: kebijakan yang cukup ketat untuk membuang semua kecuali titik akhir juga akan membuang pencarian yang diperlukan untuk menemukannya, kecuali resolusi terjadi sebelum pemblokiran diangkat atau dibawa melalui terowongan yang masih hidup. Kedua urutan bisa berhasil, tetapi hanya jika klien tahu urutan mana yang sedang berlaku.

Klien berbeda di sini dengan cara yang penting saat mendiagnosis. Sebagian menyelesaikan lebih dulu lalu memasang aturan, sehingga peralihan berbiaya gangguan yang terlihat lalu pulih sendiri; sebagian lain menahan pemblokiran dan bergantung pada terowongan yang bertahan untuk membawa pencarian, yang gagal total ketika terowongan mati bersama tautan. Menambahkan rute default langsung yang lebar untuk memulihkan konektivitas selalu meloloskan uji dan selalu menyisakan kebocoran yang Anda cegah.

Rute yang masih menunjuk ke gateway lama memberi pemulihan macet yang sama dari sebab lain, jadi bacalah tabel sebelum menyalahkan klien. Perintah di bawah menyebut antarmuka dan alamat sumber yang benar-benar akan dipakai kernel, dan itu memutuskan dalam satu baris apakah jalur lama masih terpasang.

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Ketika tautan baru membawa IPv6 dan aturannya tidak

Jaringan seluler dan tamu sering membagikan prefiks IPv6 global meski LAN kabel kantor tidak pernah melakukannya. Kebijakan yang ditulis hanya sebagai aturan IPv4, bentuk bawaan sebagian besar resep iptables dan nftables buatan tangan, tidak mencakup itu sama sekali. Terowongan tetap tersambung, aplikasi dengan keterjangkauan IPv6 keluar di luarnya, dan indikator tidak dapat menunjukkan bedanya karena terowongan benar-benar hidup. Kasus cerminnya sama lazimnya: seperangkat aturan hanya untuk IPv6 tidak melakukan apa pun di jaringan yang tidak menawarkan v6.

Bandingkan apa yang ditawarkan tautan dengan apa yang disebut kebijakan, di kedua sisi peralihan. Perintah ini mencetak fakta yang sama dengan yang dipakai klien:

ip -4 route show default
ip -6 route show default
sudo nft list ruleset | grep -c 'ip6 '

Jika perintah kedua mencetak rute default sementara yang ketiga mengembalikan nol, tautan baru dapat membawa mesin keluar melalui IPv6 tanpa satu aturan pun mengawasinya. Jalankan ketiganya lagi setelah peralihan, karena angka yang menarik adalah selisih antara kedua jalankan. Jika yang kedua tidak mencetak apa pun, kasus sebaliknya berlaku dan kebijakan yang berat pada v6 di sana hanya hiasan.

Resolver berpindah tangan di tengah sesi

Pada sistem modern resolver terikat pada tautan, jadi tautan baru datang dengan set resolver baru dan mungkin pandangan split-DNS yang berbeda. systemd-resolved menyimpan scope per tautan dan memilih di antaranya menurut rute, sementara macOS membaca resolver ber-scope dari penyimpanan dinamis dan menghormati urutan antarmuka. Klien yang memasang resolver sendiri bersaing dengan resolver tautan, dan aturan prioritas yang tidak diawasi siapa pun menentukan pemenangnya. Ketika itu resolusi nama bisa rusak sementara penyaringan paket melakukan tepat apa yang ditulis untuknya.

Bacalah resolver yang aktif, bukan yang dikonfigurasi. Pada host systemd subperintah status menunjukkan dari tautan mana setiap scope datang dan apakah nama private-DNS berlaku:

resolvectl status --no-pager
resolvectl query intranet.example.com

Jika kueri keluar melalui tautan fisik alih-alih terowongan, klien kalah dalam kompetisi prioritas dan tidak ada penyetelan firewall yang akan memperbaiki penamaan. Bandingkan jalur kueri di kedua sisi peralihan untuk melihat mana yang bergeser. Nama yang resolve ke alamat privat yang tidak dapat dirutekan jaringan baru adalah kasus ketiga, dan muncul sebagai batas waktu, bukan kesalahan.

Latih peralihan dan simpan catatannya

Reproduksi perubahan itu dengan sengaja alih-alih menunggunya. Naikkan terowongan pada tautan pertama, mulai transfer berdurasi panjang dan pencarian berulang, lalu ganti tautan dan lihat mana yang bertahan. Catat selang antara hilangnya tautan lama dan laporan terowongan bahwa ia tersambung, karena di jendela itulah kebijakan bertahan atau tidak. Jalankan urutan itu juga ke arah sebaliknya, agar hasilnya tidak sepihak.

Pengecualian perlu jalannya sendiri, karena pengecualian yang wajar di jaringan lama tidak otomatis wajar di jaringan baru. Pencetak, NAS, atau portal captive di LAN rumah tidak punya padanan di jaringan seluler, dan pengecualian yang mencapainya menjadi aturan tanpa padanan.

Catat nama antarmuka, keluarga yang ditawarkan, resolver yang berlaku, dan lama gangguan untuk setiap arah. Tersambung ulang membuktikan transport pulih, bukan bahwa pemblokiran bertahan selama jeda, dan itu klaim terpisah untuk tiket. Dengan catatan itu peralihan berikutnya dibandingkan dengan keadaan yang diketahui, bukan dengan ingatan.