Kill-switch Wi-Fi-ről mobilra váltás után: mi törik el

Az egyik pillanatban a laptop az irodai Wi-Fi-n van, a következőben egy telefonhoz kapcsolódik, és a tuneljelző már zöld, mire végzett az ablakok váltogatásával. A zöld fény csak azt jelzi, hogy a tunel újra csatlakozott; hogy az útválasztási és blokkolási szabályzat mit tett a rés alatt, az más kérdés. Ez a szabályzat egyezési feltételek halmaza, amelyet a legutóbbi telepítéskor fordítottak le, és megnevez egy interfészt, egy címet és egy címcsaládot, amelyeket az átállás épp most távolított el. Ugyanaz a váltás ezért három, egyformán kinéző eredményt ad: a blokkolás folytatódik, a szabályzat blokkolja a saját helyreállását, vagy megnyílik egy útvonal, amelyet semmi sem fed le.

A képernyőn semmi sem választja el ezt a három állapotot, ezért azt kérdezze, mely azonosítókhoz voltak a szabályok rögzítve, ne azt, milyen színt mutat a jelző. Linuxon egy szabály megnevezhet egy interfészt vagy egy belőle feltöltött ipsetet; Androidon egy VpnService-nek meg lehet mondani a setUnderlyingNetworks révén, mely mögöttes hálózatokat kövesse. Minden kötés egy linkre mutat, amely épp lecserélődik, és mindegyiket újra kell értékelni utána.

Mit ír át valójában az átállás

Amikor a régi link eltűnik, a kernel eltávolítja a címeit, visszavonja a rajta átvezető útvonalakat, és a forráscím-kiválasztást a megmaradókból újraépíti. Az alapértelmezett útvonal az új átjáróra kerül, és az interfészindex, amelyre a régi szabályok hivatkoztak, eltűnt vagy egy másik eszközhöz újrahasznosult. A linkenkénti feloldók is frissülnek, bár nem ugyanabban a pillanatban, mint az útvonalak. Mindez a VPN-kliens alatt történik, így az a kliens, amely csak a saját tunelje állapotát figyeli, semmit sem lát ebből.

A baj az, hogy a szabály egy konkrét azonosítót kódol a mögötte álló szándék helyett. Az a szabály, amely mindent eldob, ami nem a tunel interfészén keresztül távozik, egy interfésznevet kódol; az a szabály, amely engedélyezi a végpontot, egy olyan címet kódol, amelyet az új hálózat esetleg máshová irányít. Amikor az azonosító eltűnik, a szabály nem lesz láthatóan hibás: vagy megszűnik bármivel egyezni, vagy elkezd a rossz dologgal egyezni.

A külső tunel újraépítése lyuk fúrása nélkül

A külső szállítás a régi forráscímhez volt kötve, ezért új socketet kell nyitnia az újról. Amikor a végpont hosztnév és nem szó szerinti cím, a keresésnek sikerülnie kell, miközben a blokk még érvényben van. Ez a sorrend csapdája: egy elég szigorú szabályzat, amely mindent eldob a végponton kívül, eldobja a megtalálásához szükséges keresést is, hacsak a feloldás nem a blokk felemelése előtt történik, vagy nem egy még élő tunelen keresztül megy. Mindkét sorrend működhet, de csak akkor, ha a kliens tudja, melyikben van.

A kliensek itt olyan módon különböznek, amely a diagnosztikánál számít. Egyesek először feloldanak, és csak utána telepítik a szabályokat, így az átállás látható kieséssel jár, majd magától helyreáll; mások fent tartják a blokkot, és a túlélő tunelre bízzák a keresés szállítását, ami teljesen meghiúsul, ha a tunel a linkkel együtt halt meg. Egy széles közvetlen alapértelmezett útvonal hozzáadása a kapcsolat helyreállítására mindig átengedi a tesztet, és mindig meghagyja azt a szivárgást, amelyet megakadályozni próbált.

A régi átjáróra mutató útvonal ugyanazt a beragadt helyreállást adja más okból, ezért olvassa el a táblázatot, mielőtt a klienst hibáztatja. Az alábbi parancsok megnevezik azt az interfészt és forráscímet, amelyet a kernel valóban használna, és ez egy sorban eldönti, hogy a régi útvonal még telepítve van-e.

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

Amikor az új link IPv6-ot hoz, a szabályok pedig nem

A mobil- és vendéghálózatok gyakran globális IPv6-előtagot osztanak, még akkor is, ha az iroda vezetékes LAN-ja soha nem tette ezt. A csak IPv4-szabályként írt szabályzat, a legtöbb kézzel írt iptables- és nftables-recept alapformája, ennek semmit sem fed le. A tunel csatlakozva marad, az IPv6-elérhetőséggel rendelkező alkalmazások kívülre mennek, és a jelző nem tudja megmutatni a különbséget, mert a tunel valóban fent van. A tükör eset ugyanilyen gyakori: a csak IPv6-ra írt szabálykészlet semmit sem tesz egy olyan hálózaton, amely nem kínál v6-ot.

Hasonlítsa össze, mit kínál a link azzal, amit a szabályzat említ, az átállás mindkét oldalán. Ezek a parancsok ugyanazokat a tényeket írják ki, amelyekkel a kliens dolgozik:

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

Ha a második parancs alapértelmezett útvonalat ír ki, miközben a harmadik nullát ad vissza, az új link kiviheti a gépet IPv6-on, anélkül hogy bármely szabály figyelné. Futtassa mindhármat újra a váltás után, mert az érdekes szám a két futás különbsége. Ha a második semmit sem ír ki, a fordított eset érvényes, és bármilyen v6-nehéz szabályzat ott csak díszítés.

A feloldó gazdát cserél a munkamenet közepén

A modern rendszereken a feloldók linkekhez kapcsolódnak, így az új link új feloldókészlettel és esetleg más split-DNS-nézettel érkezik. A systemd-resolved linkenként egy hatókört tart, és útvonal szerint választ köztük, míg a macOS a dinamikus tárból olvassa a hatókörös feloldókat, és tiszteletben tartja az interfészek sorrendjét. Az a kliens, amely a saját feloldóját telepíti, verseng a linkével, és a győztest olyan prioritási szabályok döntik el, amelyeket senki sem figyel. Akkor a névfeloldás eltörhet, miközben a csomagszűrés pontosan azt teszi, amire írták.

Az aktív feloldót olvassa, ne a beállítottat. Egy systemd-gazdagépen a status alparancs megmutatja, melyik linkről jött az egyes hatókör, és hogy érvényben van-e private-DNS-név:

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

Ha a lekérdezés a fizikai linken megy ki a tunel helyett, a kliens elvesztette a prioritási versenyt, és semmilyen tűzfal-hangolás nem javítja a névadást. Hasonlítsa össze a lekérdezés útvonalát az átállás mindkét oldalán, hogy lássa, melyik mozdult el. Az a név, amely olyan privát címre oldódik fel, amelyet az új hálózat nem tud irányítani, harmadik eset, és időtúllépésként jelenik meg, nem hibaként.

Gyakorolja az átállást, és őrizze meg a feljegyzést

Szándékosan reprodukálja a változást, ne várjon rá. Hozza fel a tunelt az első linken, indítson hosszú átvitelt és ismételt lekérdezést, majd váltson linket, és figyelje, melyik éli túl. Jegyezze fel a régi link eltűnése és a tunel csatlakozott-jelzése közötti időközt, mert ebben az ablakban tartott ki a szabályzat vagy nem. Futtassa a sorozatot a másik irányban is, hogy az eredmény ne legyen egyoldalú.

A kivételeknek saját kör kell, mert a régi hálózaton indokolt megkerülés az újon automatikusan nem indokolt. Az otthoni LAN nyomtatójának, NAS-ának vagy captive portaljának nincs megfelelője a mobilon, és a kivétel, amely elérte őket, megfelelő nélküli szabállyá válik.

Írja fel az interfészneveket, a kínált családokat, az érvényes feloldót és a kiesés hosszát minden irányhoz. Az újracsatlakozás azt bizonyítja, hogy a szállítás helyreállt, nem azt, hogy a blokk tartott a rés alatt, és ezek külön állítások egy jegyhez. Ezzel a feljegyzéssel a következő átállást ismert állapothoz hasonlítja, nem az emlékezetéhez.