Miért dobja el a forgalmat a kill switch szerverváltáskor

Kiválaszt egy közelebbinek tűnő szervert, rákattint a csatlakozásra, és a böngésző már nem tölt, mielőtt az új alagút feláll. Az ikon csatlakozó állapotba vált, és ott is marad, míg minden lap ki nem fut az időből. Ez a szünet általában a kill switch, amely úgy működik, ahogy tervezték: a forgalom blokkolva van, amíg a kliensnek nincs alagútja, amelyen átküldhetné. Hogy a szünet elfogadható-e, attól függ, mit tesz a kliens azokban a másodpercekben, és hogy a blokk valóban megszűnik-e, amikor azt állítja.

Mit tesz a kliens két szerver között

A végpontváltás több lépés, nem egy kapcsoló. A kliens lebontja a jelenlegi alagutat, frissíti a blokkolási szabályait, feloldja és eléri az új végpontot az alagúton kívül, majd telepíti az új útvonalakat és feloldja a blokkot. Az Ön által érzett rés az első és az utolsó lépés között van.

Itt a sorrend fontosabb, mint a sebesség. Ha a blokkolási szabályok az új végpont kivétele előtt lépnek életbe, a kliens nem tudja befejezni a kézfogást, és csatlakozó állapotban marad az időtúllépésig. Ha a kivétel a régi szerver címének másolata, az új kézfogás bármely más kimenő csomaghoz hasonlít, és eldobódik. Mindkét eset ugyanúgy néz ki a böngészőből, ezért a hat másodperc után helyreálló és a soha helyre nem álló váltásnak közös oka lehet.

Az új végpontnak lyuk kell a blokkban

Az alagút felépítéséhez a kliensnek csomagokat kell küldenie az új szerver címére és portjára a fizikai interfészen, például UDP 51820-at egy tipikus WireGuard-profilnál vagy 1194-et és 443-at OpenVPN-nél, amit a saját profilja előír. Ez a forgalom nincs benne a hamarosan létrejövő alagútban, ezért az egész eszközre kiterjedő blokk elnyeli, hacsak nincs megfelelő engedélyező szabály.

A hosztnévre épülő profilok második követelményt adnak hozzá: magát a feloldást. Ha a kliens a blokk felemelkedése előtt oldja fel a végpontot, használhat gyorsítótárazott címet, de amikor a profil címet vált, vagy a gyorsítótárazott bejegyzés elavul, a kézfogás olyan cím felé indul, amelyet az engedélyező szabály nem fed le. Az IPv6 láthatóvá teszi ezt, mert a kettős vermű végpont A és AAAA rekordot is közzétehet, és a csak a v4 címet lefedő engedélyező szabály a klienset egy blokkolt v6 cím elleni újrapróbálkozásra készteti.

Az opciónevek és az alapértelmezett értékek kliensenként és verzióként változnak, ezért olvassa el a sajátjához tartozó dokumentált listát, ne pedig képernyőképekből találgasson. Az OpenVPN Connect beállításreferenciája a openvpn.net/connect-docs/app-settings-windows címen egy példa arra, hogyan írja le egy kliens a blokk- és osztott alagút opcióit.

A fail-closed állapotgép, nem kapcsoló

A legtöbb kliens a blokkot tűzfalszabályként három állapotban fejezi ki: alagút fent, a forgalom az alagúton megy át és nincs blokk; alagút lent, a blokk aktív; és átmenet, amikor a blokk aktív, plusz ideiglenes kivételek a végpontra. A harmadik állapotban élnek a hibák, mert néhány másodpercen belül kétszer kell változnia, és a belőle való kilépés elmaradása pontosan úgy néz ki, mint egy állandó blokk.

A mechanizmus platformonként változik, és a hiba is. A Windows Filtering Platform szűrőinek súlyuk van, ezért az engedélyét felülíró blokkoló szűrő továbbra is eldobja a csomagokat, pedig az engedély létezik, és a megölt kliensfolyamat által hátrahagyott szűrők offline tarthatják a gépet, miután az alkalmazás eltűnt. A macOS kliensei általában pf-szabályokat írnak egy horgonyba, ahol a szabálysorrend és a gyors döntések határozzák meg, melyik szabály érvényesül. A Linux kliensei általában nftables- vagy iptables-láncot kezelnek drop-politikával és kifejezett engedélyekkel a végpontra, az alagút interfészére és a loopbackre. Az Android always-on VPN-je a VPN nélküli kapcsolatok blokkolása opcióval a csoport legszigorúbbja, mert az operációs rendszer a blokkot az egész eszközre alkalmazza, nem alkalmazásonként.

A WireGuard külön megjegyzést érdemel, mert az AllowedIPs útvonalválasztó, nem blokkoló. Azt dönti el, mely célok kerülnek az alagútba; semmit nem tesz azért, hogy egy még alagút nélküli csomag ne lépjen ki Wi-Fi-n. Egy csak WireGuardból álló beállításban tűzfalszabály nélkül a kill switch valójában az útvonal hiánya, és egy eldobott kézfogás után valódi csomag léphet ki a fizikai interfészen.

Mérje a rést ahelyett, hogy az ikont figyelné

A csomagokat figyelje, ne az állapotlámpát. Linuxon indítson lassú pinget egy nyilvános címre az egyik terminálban, és kapja el az alagút szállítási portját a fizikai interfészen egy másikban:

ping -i 0.2 -c 100 1.1.1.1 | tail -5

sudo tcpdump -ni eth0 'udp port 51820'

Váltson szervert a kliensben, miközben mindkettő fut. Három dolog számít: mennyi ideig állnak meg a pingek, mutatja-e a rögzítés, hogy a kézfogás eléri az új végpontot, és a forgalom a kliens állapotának csatlakozottra váltása előtt vagy után tér-e vissza. Ha a pingrés előbb ér véget, vagy a blokk korán megszűnt, vagy az alagút már fent van, mielőtt a jelző elismerné. Ha a rés később ér véget, a jelző optimista.

Windows alatt a netsh wfp show state pillanatképet ír, amelyben olyan blokkoló szűrőket kereshet, amelyek még jelen vannak, miközben a kliens azt állítja, hogy bontva van. macOS alatt a sudo pfctl -sr listázza a betöltött szabályokat és sorrendjüket. Párosítsa bármelyik pillanatképet a kliens saját naplójával; a pingből kapott idővonal megmondja, hogy a blokk későn ért-e véget, vagy soha.

Normál kiesés szemben a beragadt blokkal

Némi megszakítás a funkció lényege, ezért minden beállítás módosítása előtt végezzen triázst:

Ha a második vagy az ötödik sorba kerül, ne kapcsolja ki a kill switch-et teszteléshez, mert az egy útvonalhibát szivárgássá alakít. Indítsa újra a kliens szolgáltatását, vagy indítsa újra a gépet ott, ahol a szűrők túlélik a folyamat megölését, majd nézze meg, eltűnik-e a blokk. Ha eltűnik, a hiba a váltás közbeni takarításban van, nem magában a blokkban.

A következő váltás előtt erősítsen meg négy dolgot: a végpontengedély lefedi a profilja által feloldott összes címcsaládot, a kliensnapló a befejezett átmenetet mutatja, a pingtesztje a rést méri, nem az ikont, és a kliens bezárása helyreállítja a normál kapcsolatot. Az a kill switch, amely a váltás alatt tart, utána pedig elenged, végzi a dolgát. Amelyik korán vagy soha nem enged el, érdemes hibakeresni.