Kill-switch po prechode z Wi-Fi na mobilnú sieť: čo sa pokazí

V jednej chvíli je notebook na kancelárskej Wi-Fi, v ďalšej je pripojený k telefónu a indikátor tunela je znovu zelený, skôr než stihnete prepnúť okná. Zelené svetlo hlási len to, že sa tunel znovu pripojil; čo počas medzery robila politika smerovania a blokovania, je iná otázka. Tá politika je sada podmienok zhody skompilovaných pri poslednej inštalácii a pomenúva rozhranie, adresu a rodinu adries, ktoré prechod práve odstránil. Ten istý prepínač preto dáva tri výsledky, ktoré vyzerajú rovnako: blokovanie pokračuje, politika zablokuje vlastné obnovenie, alebo sa otvorí cesta, ktorú nič nekryje.

Nič na obrazovke tieto tri stavy neoddeľuje, preto sa pýtajte, na aké identifikátory boli pravidlá pripnuté, a nie akú farbu ukazuje indikátor. V Linuxe môže pravidlo pomenovať rozhranie alebo ipset naplnený z neho; v Androide možno VpnService povedať cez setUnderlyingNetworks, ktoré podkladové siete má nasledovať. Každé previazanie ukazuje na spoj, ktorý sa práve chystá byť nahradený, a každé treba potom znova vyhodnotiť.

Čo prechod skutočne prepisuje

Keď starý spoj zmizne, jadro odstráni jeho adresy, stiahne trasy, ktoré cezeň viedli, a znova postaví výber zdrojovej adresy z toho, čo zostalo. Predvolená trasa sa presunie na novú bránu a index rozhrania, na ktorý odkazovali staré pravidlá, zmizol alebo je recyklovaný pre iné zariadenie. Resolvery na spoj sa tiež obnovujú, hoci nie v tej istej chvíli ako trasy. Všetko sa to deje pod VPN klientom, takže klient, ktorý sleduje len stav svojho tunela, z toho nič nevidí.

Problém je v tom, že pravidlo kóduje konkrétny identifikátor namiesto zámeru za ním. Pravidlo, ktoré zahadzuje všetko, čo neodchádza cez rozhranie tunela, kóduje názov rozhrania; pravidlo, ktoré povoľuje koncový bod, kóduje adresu, ktorú môže nová sieť smerovať inam. Keď identifikátor zmizne, pravidlo sa viditeľne nepokazí: buď prestane zodpovedať čomukoľvek, alebo začne zodpovedať nesprávnej veci.

Znovu postaviť vonkajší tunel bez vyrazenia diery

Vonkajší transport bol viazaný na starú zdrojovú adresu, preto musí otvoriť nový socket z novej. Keď je koncový bod názov hostiteľa a nie doslovná adresa, vyhľadanie musí uspieť, kým blokovanie stále platí. To je pasca poradia: politika dosť prísna na to, aby zahodila všetko okrem koncového bodu, zahodí aj vyhľadanie potrebné na jeho nájdenie, ak sa rozlíšenie neudeje pred zdvihnutím blokovania alebo sa neprenesie cez ešte živý tunel. Obe poradia môžu fungovať, ale iba ak klient vie, v ktorom je.

Klienti sa tu líšia spôsobom, ktorý pri diagnostike záleží. Niektoré najprv rozlíšia a potom nainštalujú pravidlá, takže prechod stojí viditeľný výpadok a potom sa sám zotaví; iné držia blokovanie a spoliehajú na prežívajúci tunel, že prenesie vyhľadanie, čo úplne zlyhá, keď tunel zomrel so spojom. Pridanie širokej priamej predvolenej trasy na obnovenie pripojenia vždy nechá test prejsť a vždy zanechá únik, ktorému ste bránili.

Trasa, ktorá stále ukazuje na starú bránu, dáva rovnaké zaseknuté zotavenie z inej príčiny, preto si prečítajte tabuľku, než obviníte klienta. Príkazy nižšie pomenúvajú rozhranie a zdrojovú adresu, ktoré by jadro skutočne použilo, a to rozhodne v jednom riadku, či je stará cesta ešte nainštalovaná.

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

Keď nový spoj prinesie IPv6 a pravidlá nie

Mobilné a hostiteľské siete často prideľujú globálny prefix IPv6, aj keď kancelárska káblová LAN to nikdy nerobila. Politika napísaná len ako pravidlá IPv4, predvolená podoba väčšiny ručne robených receptov pre iptables a nftables, nič z toho nekryje. Tunel zostáva pripojený, aplikácie s dosiahnuteľnosťou IPv6 vychádzajú mimo neho a indikátor nemôže rozdiel ukázať, pretože tunel naozaj beží. Zrkadlový prípad je rovnako bežný: sada pravidiel len pre IPv6 nič nerobí v sieti, ktorá v6 neponúka.

Porovnajte, čo spoj ponúka, s tým, čo politika spomína, na oboch stranách prechodu. Tieto príkazy tlačia tie isté fakty, s ktorými klient pracuje:

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

Ak druhý príkaz vytlačí predvolenú trasu, zatiaľ čo tretí vráti nulu, nový spoj môže stroj vyviesť cez IPv6 bez toho, aby ho strážilo nejaké pravidlo. Spustite všetky tri znova po prepnutí, pretože zaujímavé číslo je rozdiel medzi oboma behmi. Ak druhý nič nevytlačí, platí opačný prípad a akákoľvek politika ťažká na v6 je tam len dekorácia.

Resolver mení ruky uprostred relácie

V moderných systémoch sú resolvery pripojené k spojom, takže nový spoj prichádza s novou sadou resolverov a možno s iným pohľadom split-DNS. systemd-resolved drží rozsah pre každý spoj a vyberá medzi nimi podľa trasy, zatiaľ čo macOS číta resolvery s rozsahom z dynamického úložiska a rešpektuje poradie rozhraní. Klient, ktorý si nainštaluje vlastný resolver, súťaží s resolverom spoja, a o víťazovi rozhodujú pravidlá priority, na ktoré nikto nedohliada. Preklad názvov sa potom môže pokaziť, zatiaľ čo filtrovanie paketov robí presne to, na čo bolo napísané.

Čítajte resolver, ktorý je aktívny, nie ten nakonfigurovaný. Na hostiteľovi so systemd podpríkaz status ukazuje, z ktorého spoja prišiel každý rozsah a či platí názov private-DNS:

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

Ak dopyt odchádza cez fyzický spoj a nie cez tunel, klient prehral súťaž priorít a žiadne ladenie firewallu názvy nespraví. Porovnajte cestu dopytu na oboch stranách prechodu, aby ste videli, ktorá sa pohla. Názov, ktorý sa preloží na súkromnú adresu, ktorú nová sieť nevie smerovať, je tretí prípad a prejavuje sa ako časový limit, nie ako chyba.

Precvičte prechod a veďte záznam

Reprodukujte zmenu zámerne, namiesto čakania na ňu. Zdvihnite tunel na prvom spoji, spustite dlhý prenos a opakované vyhľadanie, potom prepnite spoj a sledujte, čo prežije. Poznamenajte interval medzi zmiznutím starého spoja a hlásením tunela, že je pripojený, pretože v tom okne politika buď vydržala, alebo nie. Spustite sekvenciu aj opačným smerom, aby výsledok nebol jednostranný.

Výnimky potrebujú vlastný priechod, pretože obchvat odôvodnený v starej sieti nie je automaticky odôvodnený v novej. Tlačiareň, NAS alebo captive portal v domácej LAN nemá v mobilnej sieti náprotivok a výnimka, ktorá sa k nim dostávala, sa stáva pravidlom bez náprotivku.

Zapíšte názvy rozhraní, ponúkané rodiny, platný resolver a dĺžku výpadku pre každý smer. Opätovné pripojenie dokazuje, že sa transport zotavil, nie že blokovanie počas medzery vydržalo, a to sú oddelené tvrdenia do tiketu. S týmto záznamom sa ďalší prechod porovnáva so známym stavom a nie s pamäťou.