Kill switch selepas bertukar dari Wi-Fi ke selular: apa yang rosak

Satu ketika komputer riba berada di Wi-Fi pejabat, ketika berikutnya ia tersambung ke telefon, dan penunjuk terowong kembali hijau sebelum anda selesai menukar tetingkap. Lampu hijau hanya melaporkan bahawa terowong telah bersambung semula; apa yang dilakukan oleh dasar penghalaan dan penyekatan sepanjang selang itu ialah soalan lain. Dasar itu ialah satu set syarat padanan yang dikompil semasa pemasangan terakhir, dan ia menamakan antara muka, alamat dan keluarga alamat yang baru sahaja dibuang oleh peralihan. Oleh itu pertukaran yang sama menghasilkan tiga hasil yang kelihatan serupa: penyekatan berterusan, dasar menyekat pemulihannya sendiri, atau terbuka laluan yang tidak dilindungi apa-apa.

Tiada apa pada skrin yang memisahkan ketiga-tiga keadaan itu, jadi tanyakan pengenal mana peraturan itu dipaku, bukan warna apa yang ditunjukkan penunjuk. Pada Linux sesuatu peraturan boleh menamakan antara muka atau ipset yang diisi daripadanya; pada Android sesuatu VpnService boleh diberitahu rangkaian asas mana yang perlu diikuti melalui setUnderlyingNetworks. Setiap ikatan menunjuk ke pautan yang akan diganti, dan setiap satunya mesti dinilai semula selepas itu.

Apa yang sebenarnya ditulis semula oleh peralihan

Apabila pautan lama hilang, kernel membuang alamatnya, menarik balik laluan yang melaluinya, dan membina semula pemilihan alamat sumber daripada apa yang tinggal. Laluan lalai berpindah ke get laluan baharu, dan indeks antara muka yang dirujuk oleh peraturan lama telah hilang atau dikitar semula untuk peranti lain. Penyelesai bagi setiap pautan juga disegarkan, walaupun bukan pada saat yang sama dengan laluan. Semua ini berlaku di bawah klien VPN, jadi klien yang hanya memerhati keadaan terowongnya sendiri tidak melihat apa-apa daripadanya.

Masalahnya ialah peraturan mengekodkan pengenal tertentu dan bukannya niat di belakangnya. Peraturan yang membuang semua yang tidak keluar melalui antara muka terowong mengekodkan nama antara muka; peraturan yang membenarkan titik hujung mengekodkan alamat yang mungkin dihalakan rangkaian baharu ke tempat lain. Apabila pengenal hilang, peraturan itu tidak menjadi jelas salah: ia sama ada berhenti sepadan dengan apa-apa atau mula sepadan dengan perkara yang salah.

Membina semula terowong luar tanpa menebuk lubang

Pengangkutan luar terikat pada alamat sumber lama, jadi ia perlu membuka soket baharu daripada alamat baharu. Apabila titik hujung ialah nama hos dan bukan alamat harfiah, carian mesti berjaya semasa penyekatan masih berkuat kuasa. Inilah perangkap urutan: dasar yang cukup ketat untuk membuang segala-galanya kecuali titik hujung juga akan membuang carian yang diperlukan untuk menemuinya, melainkan penyelesaian berlaku sebelum penyekatan dinaikkan atau dibawa melalui terowong yang masih hidup. Kedua-dua urutan boleh berfungsi, tetapi hanya jika klien tahu urutan mana ia berada.

Klien berbeza di sini dengan cara yang penting semasa mendiagnosis. Sesetengah menyelesaikan dahulu dan memasang peraturan kemudian, jadi peralihan menelan gangguan yang kelihatan dan kemudian pulih sendiri; yang lain mengekalkan penyekatan dan bergantung pada terowong yang terselamat untuk membawa carian, yang gagal sepenuhnya apabila terowong mati bersama pautan. Menambah laluan lalai langsung yang luas untuk memulihkan sambungan sentiasa meluluskan ujian dan sentiasa meninggalkan kebocoran yang anda halang.

Laluan yang masih menunjuk ke get laluan lama memberikan pemulihan tersekat yang sama daripada punca lain, jadi baca jadual sebelum menyalahkan klien. Perintah di bawah menamakan antara muka dan alamat sumber yang benar-benar akan digunakan oleh kernel, dan itu memutuskan dalam satu baris sama ada laluan lama masih dipasang.

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

Apabila pautan baharu membawa IPv6 dan peraturannya tidak

Rangkaian selular dan tetamu sering memberikan awalan IPv6 global walaupun LAN berwayar pejabat tidak pernah melakukannya. Dasar yang ditulis hanya sebagai peraturan IPv4, bentuk lalai kebanyakan resipi iptables dan nftables buatan tangan, tidak meliputi apa-apa daripadanya. Terowong kekal bersambung, aplikasi yang mempunyai ketersampaian IPv6 keluar di luarnya, dan penunjuk tidak dapat menunjukkan perbezaan kerana terowong itu benar-benar hidup. Kes cermin juga sama lazim: set peraturan untuk IPv6 sahaja tidak melakukan apa-apa pada rangkaian yang tidak menawarkan v6.

Bandingkan apa yang ditawarkan pautan dengan apa yang disebut dasar, pada kedua-dua belah peralihan. Perintah ini mencetak fakta yang sama dengan yang digunakan oleh klien:

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

Jika perintah kedua mencetak laluan lalai manakala yang ketiga memulangkan sifar, pautan baharu boleh membawa mesin keluar melalui IPv6 tanpa apa-apa peraturan mengawasinya. Jalankan ketiga-tiganya sekali lagi selepas pertukaran, kerana nombor yang menarik ialah perbezaan antara kedua-dua jalanan. Jika yang kedua tidak mencetak apa-apa, kes sebaliknya terpakai dan apa-apa dasar yang berat pada v6 di situ hanyalah hiasan.

Penyelesai bertukar tangan di tengah-tengah sesi

Pada sistem moden penyelesai terikat pada pautan, jadi pautan baharu tiba dengan set penyelesai baharu dan mungkin pandangan split-DNS yang berbeza. systemd-resolved menyimpan satu skop bagi setiap pautan dan memilih antaranya mengikut laluan, manakala macOS membaca penyelesai berskop daripada stor dinamik dan menghormati susunan antara muka. Klien yang memasang penyelesainya sendiri bersaing dengan penyelesai pautan, dan peraturan keutamaan yang tidak diawasi sesiapa menentukan pemenangnya. Maka penyelesaian nama boleh rosak manakala penapisan paket melakukan tepat apa yang ditulis untuknya.

Baca penyelesai yang aktif dan bukan yang dikonfigurasikan. Pada hos systemd subperintah status menunjukkan dari pautan mana setiap skop datang dan sama ada nama private-DNS berkuat kuasa:

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

Jika pertanyaan keluar melalui pautan fizikal dan bukan terowong, klien telah kalah dalam pertandingan keutamaan dan tiada penalaan tembok api akan membaiki penamaan. Bandingkan laluan pertanyaan pada kedua-dua belah peralihan untuk melihat mana yang bergerak. Nama yang diselesaikan kepada alamat peribadi yang tidak dapat dihalakan oleh rangkaian baharu ialah kes ketiga, dan ia muncul sebagai tamat masa dan bukan sebagai ralat.

Latih peralihan dan simpan rekod

Hasilkan semula perubahan itu dengan sengaja dan bukan menunggunya. Naikkan terowong pada pautan pertama, mulakan pemindahan jangka panjang dan carian berulang, kemudian tukar pautan dan lihat mana yang terselamat. Catat selang antara hilangnya pautan lama dan laporan terowong bahawa ia bersambung, kerana dalam tetingkap itulah dasar sama ada bertahan atau tidak. Jalankan urutan itu ke arah bertentangan juga, supaya hasilnya tidak berat sebelah.

Pengecualian perlu laluan sendiri, kerana lencongan yang wajar pada rangkaian lama tidak automatik wajar pada rangkaian baharu. Pencetak, NAS atau portal tawanan pada LAN rumah tiada pasangan pada selular, dan pengecualian yang sampai kepadanya menjadi peraturan tanpa pasangan.

Catat nama antara muka, keluarga yang ditawarkan, penyelesai yang berkuat kuasa dan tempoh gangguan bagi setiap arah. Bersambung semula membuktikan pengangkutan pulih, bukan bahawa penyekatan bertahan sepanjang selang, dan itu dakwaan berasingan untuk tiket. Dengan rekod itu peralihan berikutnya dibandingkan dengan keadaan yang diketahui dan bukan dengan ingatan.