Kill-switch po přechodu z Wi-Fi na mobilní síť: co se rozbije

V jednom okamžiku je notebook na kancelářské Wi-Fi, v dalším je připojený k telefonu a indikátor tunelu je znovu zelený, než stihnete přepnout okna. Zelené světlo hlásí jen to, že se tunel znovu připojil; co během mezery dělala politika směrování a blokování, je jiná otázka. Ta politika je sada podmínek shody zkompilovaných při poslední instalaci a pojmenovává rozhraní, adresu a rodinu adres, které předání právě odstranilo. Stejný přechod proto dává tři výsledky, které vypadají stejně: blokování pokračuje, politika zablokuje vlastní obnovu, nebo se otevře cesta, kterou nic nekryje.

Nic na obrazovce tyto tři stavy neodděluje, proto se ptejte, na jaké identifikátory byla pravidla připevněna, místo jakou barvu ukazuje indikátor. V Linuxu může pravidlo pojmenovat rozhraní nebo ipset naplněný z něj; v Androidu lze VpnService říct, které podkladové sítě má následovat, pomocí setUnderlyingNetworks. Každá vazba ukazuje na spoj, který se právě chystá být nahrazen, a každá musí být potom znovu vyhodnocena.

Co předání skutečně přepisuje

Když starý spoj zmizí, jádro odstraní jeho adresy, stáhne trasy, které přes něj vedly, a znovu postaví výběr zdrojové adresy z toho, co zbylo. Výchozí trasa se přesune na novou bránu a index rozhraní, na který stará pravidla odkazovala, je pryč nebo recyklován pro jiné zařízení. Resolvery pro jednotlivé spoje se také obnovují, i když ne ve stejný okamžik jako trasy. Všechno se to děje pod VPN klientem, takže klient, který sleduje jen stav svého tunelu, z toho nic nevidí.

Potíž je v tom, že pravidlo kóduje konkrétní identifikátor místo záměru za ním. Pravidlo, které zahazuje vše, co neodchází přes rozhraní tunelu, kóduje název rozhraní; pravidlo, které povoluje koncový bod, kóduje adresu, kterou nová síť může směrovat jinam. Když identifikátor zmizí, pravidlo se viditelně nezmění na chybné: buď přestane odpovídat čemukoli, nebo začne odpovídat špatné věci.

Přestavět vnější tunel, aniž by se udělala díra

Vnější transport byl svázán se starou zdrojovou adresou, takže musí otevřít nový socket z nové. Když je koncový bod název hostitele, nikoli doslovná adresa, musí vyhledání uspět, dokud blokování stále platí. To je past pořadí: politika dost přísná na to, aby zahodila vše kromě koncového bodu, zahodí i vyhledání potřebné k jeho nalezení, ledaže k rozlišení dojde před zvednutím blokování nebo je neseno tunelem, který je stále živý. Fungovat může obojí pořadí, ale jen když klient ví, v kterém je.

Klienti se zde liší způsobem, který při diagnostice záleží. Někteří nejprve rozlišují a pravidla instalují potom, takže předání stojí viditelný výpadek a pak se samo zotaví; jiní drží blokování a spoléhají na přeživší tunel, že ponese vyhledání, což úplně selže, když tunel zemřel spolu se spojem. Přidání široké přímé výchozí trasy pro obnovení připojení vždy nechá test projít a vždy ponechá únik, kterému jste bránili.

Trasa, která stále ukazuje na starou bránu, dává stejné zaseknuté zotavení z jiné příčiny, takže si přečtěte tabulku, než obviníte klienta. Níže uvedené příkazy pojmenovávají rozhraní a zdrojovou adresu, které by jádro skutečně použilo, a to rozhodne na jednom řádku, zda je stará cesta stále nainstalovaná.

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

Když nový spoj přinese IPv6 a pravidla ne

Mobilní a hostitelské sítě často přidělují globální prefix IPv6, i když kancelářská kabelová LAN to nikdy nedělala. Politika napsaná jen jako pravidla IPv4, což je výchozí podoba většiny ručně psaných receptů pro iptables a nftables, nic z toho nekryje. Tunel zůstává připojený, aplikace s dosažitelností IPv6 vycházejí mimo něj a indikátor nemůže rozdíl ukázat, protože tunel opravdu běží. Zrcadlový případ je stejně běžný: sada pravidel jen pro IPv6 nedělá nic v síti, která v6 nenabízí.

Porovnejte, co spoj nabízí, s tím, co politika zmiňuje, na obou stranách předání. Tyto příkazy tisknou stejná fakta, se kterými klient pracuje:

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

Pokud druhý příkaz vytiskne výchozí trasu, zatímco třetí vrátí nulu, nový spoj může stroj vyvést přes IPv6, aniž by ho hlídalo nějaké pravidlo. Spusťte všechny tři znovu po přepnutí, protože zajímavé číslo je rozdíl mezi oběma běhy. Pokud druhý nic nevytiskne, platí opačný případ a jakákoli politika těžká na v6 je tam jen dekorace.

Resolver mění ruce uprostřed relace

V moderních systémech jsou resolvery připojeny ke spojům, takže nový spoj přichází s novou sadou resolverů a možná s jiným pohledem split-DNS. systemd-resolved drží rozsah pro každý spoj a vybírá mezi nimi podle trasy, zatímco macOS čte resolvery s rozsahem z dynamického úložiště a respektuje pořadí rozhraní. Klient, který instaluje vlastní resolver, soutěží s resolverem spoje, a o vítězi rozhodují pravidla priority, na která nikdo nedohlíží. Překlad názvů se pak může rozbít, zatímco filtrování paketů dělá přesně to, k čemu bylo napsáno.

Čtěte resolver, který je aktivní, ne ten nakonfigurovaný. Na hostiteli se systemd podpříkaz status ukazuje, ze kterého spoje každý rozsah přišel a zda platí jméno private-DNS:

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

Pokud dotaz odchází přes fyzický spoj místo tunelu, klient prohrál soutěž priorit a žádné ladění firewallu názvy nespraví. Porovnejte cestu dotazu na obou stranách předání a zjistěte, která se pohnula. Název, který se přeloží na soukromou adresu, kterou nová síť neumí směrovat, je třetí případ a projevuje se jako časový limit, ne jako chyba.

Procvičte předání a veďte záznam

Reprodukujte změnu záměrně, místo abyste na ni čekali. Zvedněte tunel na prvním spoji, spusťte dlouhý přenos a opakované vyhledání, pak přepněte spoj a sledujte, které přežije. Poznamenejte interval mezi zmizením starého spoje a hlášením tunelu, že je připojen, protože v tom okně politika buď vydržela, nebo ne. Spusťte sekvenci i opačným směrem, aby výsledek nebyl jednostranný.

Výjimky potřebují vlastní průchod, protože obchvat odůvodněný ve staré síti není automaticky odůvodněný v nové. Tiskárna, NAS nebo captive portal v domácí LAN nemá na mobilní síti protějšek a výjimka, která se k němu dostala, se stává pravidlem bez protějšku.

Zapište názvy rozhraní, nabízené rodiny, platný resolver a délku výpadku pro každý směr. Opětovné připojení dokazuje, že se transport zotavil, ne že blokování během mezery vydrželo, a to jsou oddělená tvrzení do tiketu. S tímto záznamem se další předání porovnává se známým stavem, ne s pamětí.