Kill-switch nakon prelaska s Wi-Fi na mobilnu mrežu: što se kvari

U jednom trenutku laptop je na uredskom Wi-Fi-ju, u sljedećem je vezan za telefon, a indikator tunela je opet zelen prije nego što završite s prebacivanjem prozora. Zeleno svjetlo samo javlja da se tunel ponovo povezao; šta je politika rutiranja i blokiranja radila tokom praznine je drugo pitanje. Ta politika je skup uslova podudaranja kompajliranih pri posljednjoj instalaciji, i imenuje interfejs, adresu i familiju adresa koje je prelazak upravo uklonio. Isti prelazak zato daje tri ishoda koji izgledaju isto: blokiranje se nastavlja, politika blokira vlastiti oporavak, ili se otvara putanja koju ništa ne pokriva.

Ništa na ekranu ne razdvaja ta tri stanja, pa pitajte na koje identifikatore su pravila bila prikvačena umjesto koje boje pokazuje indikator. Na Linuxu pravilo može imenovati interfejs ili ipset napunjen iz njega; na Androidu se VpnService-u može reći koje podložne mreže da prati preko setUnderlyingNetworks. Svaka veza pokazuje na link koji će uskoro biti zamijenjen, i svaka se mora ponovo procijeniti poslije.

Šta prelazak zapravo prepisuje

Kada stari link nestane, kernel uklanja njegove adrese, povlači rute koje su vodile kroz njega i ponovo gradi izbor izvorne adrese iz onoga što ostane. Zadana ruta se pomjera na novi gateway, a indeks interfejsa na koji su stara pravila upućivala je nestao ili recikliran za drugi uređaj. Resolveri po linku se takođe osvježavaju, iako ne u istom trenutku kao rute. Sve se to dešava ispod VPN klijenta, pa klijent koji prati samo stanje svog tunela ne vidi ništa od toga.

Problem je što pravilo kodira određeni identifikator umjesto namjere iza njega. Pravilo koje odbacuje sve što ne izlazi kroz interfejs tunela kodira ime interfejsa; pravilo koje dopušta krajnju tačku kodira adresu koju nova mreža može rutirati negdje drugdje. Kada identifikator nestane, pravilo ne postaje vidljivo pogrešno: ili prestaje da se podudara s bilo čim ili počinje da se podudara s pogrešnom stvari.

Ponovno izgraditi vanjski tunel bez pravljenja rupe

Vanjski transport je bio vezan za staru izvornu adresu, pa mora otvoriti novi socket s nove. Kada je krajnja tačka ime hosta, a ne doslovna adresa, pretraga mora uspjeti dok je blokada još na snazi. To je zamka redoslijeda: politika dovoljno stroga da odbaci sve osim krajnje tačke odbacit će i pretragu potrebnu da je nađe, osim ako se razrješenje dogodi prije podizanja blokade ili se prenese kroz tunel koji je još živ. Oba redoslijeda mogu raditi, ali samo ako klijent zna u kojem je.

Klijenti se ovdje razlikuju na način koji je važan pri dijagnostici. Neki prvo razrješavaju pa poslije instaliraju pravila, pa prelazak košta vidljiv prekid i zatim se sam oporavi; drugi drže blokadu i oslanjaju se na preživjeli tunel da prenese pretragu, što potpuno pada kada je tunel umro zajedno s linkom. Dodavanje široke direktne zadane rute za vraćanje povezanosti uvijek pušta test da prođe i uvijek ostavlja curenje koje ste sprječavali.

Ruta koja još pokazuje na stari gateway daje isti zaglavljeni oporavak iz drugog uzroka, pa pročitajte tablicu prije nego okrivite klijent. Komande ispod imenuju interfejs i izvornu adresu koje bi kernel zaista koristio, a to u jednom redu rješava da li je stara putanja još instalirana.

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

Kada novi link donese IPv6, a pravila ne

Mobilne i gostujuće mreže često daju globalni prefiks IPv6 čak i kada žičana LAN mreža ureda to nikada nije činila. Politika napisana samo kao IPv4 pravila, zadani oblik većine ručno rađenih recepata za iptables i nftables, ne pokriva ništa od toga. Tunel ostaje povezan, aplikacije s IPv6 dostupnošću izlaze izvan njega, a indikator ne može pokazati razliku jer tunel zaista jeste podignut. Zrcalni slučaj je jednako čest: skup pravila samo za IPv6 ne radi ništa na mreži koja ne nudi v6.

Uporedite šta link nudi sa onim što politika spominje, na obje strane prelaska. Ove komande ispisuju iste činjenice s kojima klijent radi:

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

Ako druga komanda ispiše zadanu rutu dok treća vraća nulu, novi link može izvesti mašinu preko IPv6 bez ijednog pravila koje to gleda. Pokrenite sve tri ponovo nakon prebacivanja, jer je zanimljiv broj razlika između dva pokretanja. Ako druga ne ispiše ništa, vrijedi obrnuti slučaj i svaka politika teška na v6 tamo je samo ukras.

Resolver mijenja ruke usred sesije

Na modernim sistemima resolveri su vezani za linkove, pa novi link dolazi s novim skupom resolvera i moguće s drugačijim prikazom split-DNS. systemd-resolved drži scope po linku i bira među njima po ruti, dok macOS čita scoped resolvere iz dinamičkog spremišta i poštuje redoslijed interfejsa. Klijent koji instalira vlastiti resolver takmiči se s onim s linka, a pravila prioriteta koja niko ne gleda odlučuju pobjednika. Tada se razrješavanje imena može slomiti dok filtriranje paketa radi tačno ono za što je napisano.

Čitajte resolver koji je aktivan, a ne onaj koji je konfigurisan. Na systemd hostu podkomanda status pokazuje s kojeg linka je došao svaki scope i da li je ime private-DNS na snazi:

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

Ako upit izlazi kroz fizički link umjesto kroz tunel, klijent je izgubio takmičenje prioriteta i nikakvo podešavanje firewall-a neće popraviti imenovanje. Uporedite putanju upita na obje strane prelaska da vidite koja se pomjerila. Ime koje se razrješava na privatnu adresu koju nova mreža ne može rutirati je treći slučaj, i pojavljuje se kao istek vremena, a ne kao greška.

Vježbajte prelazak i vodite zapis

Reprodukujte promjenu namjerno umjesto da je čekate. Podignite tunel na prvom linku, pokrenite dugotrajan prijenos i ponovljenu pretragu, zatim prebacite link i gledajte šta preživi. Zabilježite interval između nestanka starog linka i izvještaja tunela da je povezan, jer je u tom prozoru politika ili izdržala ili nije. Pokrenite slijed i u drugom smjeru, da rezultat ne bude jednostran.

Izuzeci traže svoj prolaz, jer obilazak opravdan na staroj mreži nije automatski opravdan na novoj. Štampač, NAS ili captive portal na kućnoj LAN mreži nema pandan na mobilnoj, a izuzetak koji je do njega stizao postaje pravilo bez pandana.

Zapišite imena interfejsa, ponuđene familije, resolver na snazi i dužinu prekida za svaki smjer. Ponovno povezivanje dokazuje da se transport oporavio, a ne da je blokada izdržala tokom praznine, i to su odvojene tvrdnje za tiket. S tim zapisom sljedeći prelazak se poredi s poznatim stanjem umjesto s pamćenjem.