Proč kill switch při změně serveru zahodí provoz

Vyberete server, který vypadá blíž, stisknete připojit a prohlížeč přestane načítat dřív, než se nový tunel zvedne. Ikona přejde do stavu připojování a zůstane tam, dokud každá karta nevyprší. Tahle pauza je obvykle kill switch, který pracuje podle návrhu: provoz je blokovaný, dokud klient nemá tunel, kterým by ho poslal. Jestli je pauza přijatelná, závisí na tom, co klient v těch sekundách dělá, a na tom, zda se blok zruší, když tvrdí, že ano.

Co klient dělá mezi dvěma servery

Změna koncového bodu je několik kroků, ne jeden přepínač. Klient zboří aktuální tunel, aktualizuje svá pravidla blokování, přeloží a dosáhne nového koncového bodu mimo tunel, potom nainstaluje nové trasy a zruší blok. Mezera, kterou cítíte, leží mezi prvním a posledním krokem.

Pořadí je tu důležitější než rychlost. Pokud pravidla blokování nastoupí dřív než výjimka pro nový koncový bod, klient nemůže dokončit handshake a zůstane ve stavu připojování do vypršení. Pokud je výjimka kopií adresy starého serveru, nový handshake vypadá jako jakýkoli jiný odchozí paket a je zahozen. Oba případy vypadají z prohlížeče stejně, a proto změna, která se vzpamatuje po šesti sekundách, a ta, která nikdy, mohou mít stejnou příčinu.

Nový koncový bod potřebuje v bloku díru

Aby klient postavil tunel, musí posílat pakety na adresu a port nového serveru přes fyzické rozhraní, například UDP 51820 u typického profilu WireGuard nebo 1194 a 443 u OpenVPN, ať už váš profil předepisuje cokoli. Tento provoz není uvnitř tunelu, který teprve vznikne, takže blok pro celé zařízení ho spolkne, pokud neexistuje odpovídající povolovací pravidlo.

Profily založené na názvu hostitele přidávají druhý požadavek: samotné hledání. Pokud klient přeloží koncový bod dřív, než se blok zvedne, může použít adresu z mezipaměti, ale jakmile profil otočí adresy nebo záznam v mezipaměti zestárne, handshake míří na adresu, kterou povolovací pravidlo nepokrývá. IPv6 to dělá viditelným, protože koncový bod se dvěma zásobníky může publikovat záznam A i AAAA a povolovací pravidlo pokrývající jen adresu v4 nechá klienta opakovat pokusy proti blokované adrese v6.

Názvy voleb a výchozí hodnoty se liší podle klienta a verze, proto si přečtěte dokumentovaný seznam pro ten svůj, místo abyste hádali ze screenshotů. Reference nastavení OpenVPN Connect na openvpn.net/connect-docs/app-settings-windows je jeden příklad toho, jak klient popisuje své volby blokování a rozděleného tunelu.

Fail-closed je stavový automat, ne přepínač

Většina klientů vyjadřuje blok jako firewallovou politiku ve třech stavech: tunel zvednutý, provoz jde tunelem a blok není; tunel spadlý, blok je aktivní; a přechod, kdy je blok aktivní plus dočasné výjimky pro koncový bod. Právě ve třetím stavu žijí chyby, protože se musí změnit dvakrát během pár sekund, a neschopnost z něj vystoupit vypadá přesně jako trvalý blok.

Mechanismus se liší podle platformy, a selhání taky. Filtry Windows Filtering Platform mají váhy, takže blokovací filtr, který převáží vaše povolení, dál zahazuje pakety, i když povolení existuje, a filtry ponechané zabitým procesem klienta mohou držet stroj offline poté, co aplikace zmizí. Klienti na macOS obvykle zapisují pravidla pf do anchoru, kde o pořadí a rychlých rozhodnutích závisí, které pravidlo platí. Klienti na Linuxu obvykle spravují řetěz nftables nebo iptables s politikou drop a výslovnými povoleními pro koncový bod, rozhraní tunelu a loopback. Always-on VPN v Androidu s volbou blokovat připojení bez VPN je nejpřísnější v této skupině, protože systém uplatňuje blok na celé zařízení, ne na aplikaci.

WireGuard si zaslouží vlastní poznámku, protože AllowedIPs je selektor směrování, ne blokátor. Rozhoduje, které cíle jdou do tunelu; neudělá nic pro to, aby paket, který ještě tunel nemá, neodešel přes Wi-Fi. V nastavení jen s WireGuardem a bez firewallového pravidla je kill switch vlastně nepřítomnost trasy a po zahozeném handshaku může odejít skutečný paket přes fyzické rozhraní.

Měřte mezeru, místo abyste sledovali ikonu

Sledujte pakety, ne stavovou kontrolku. Na Linuxu spusťte pomalý ping na veřejnou adresu v jednom terminálu a v druhém zachyťte transportní port tunelu na fyzickém rozhraní:

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

sudo tcpdump -ni eth0 'udp port 51820'

Přepněte servery v klientu, zatímco oba běží. Záleží na třech věcech: jak dlouho se pingy zastaví, zda zachycení ukazuje handshake dosahující nového koncového bodu a zda se provoz obnoví před nebo po tom, co se stav klienta změní na připojeno. Pokud mezera v pingech skončí dřív, buď se blok zrušil brzy, nebo je tunel zvednutý dřív, než to indikátor přizná. Pokud mezera skončí později, je indikátor optimistický.

Ve Windows netsh wfp show state zapíše snímek, ve kterém můžete hledat blokovací filtry, které stále existují, zatímco klient tvrdí, že je odpojený. V macOS sudo pfctl -sr vypíše načtená pravidla a jejich pořadí. Spojte kterýkoli snímek s vlastním logem klienta; časová osa z vašeho pingu vám řekne, zda blok skončil pozdě, nebo nikdy.

Normální výpadek versus zaseknutý blok

Nějaké přerušení je smyslem té funkce, proto nejdřív zařaďte situaci, než změníte jakékoli nastavení:

Pokud skončíte ve druhém nebo pátém řádku, nevypínejte kill switch na test, protože tím proměníte chybu směrování v únik. Restartujte službu klienta, nebo restartujte stroj tam, kde filtry přežijí zabití procesu, a podívejte se, zda se blok vyčistí. Pokud ano, chyba je v úklidu při přepnutí, ne v bloku samotném.

Před dalším přepnutím potvrďte čtyři věci: povolení pro koncový bod pokrývá každou rodinu adres, kterou váš profil překládá, log klienta ukazuje dokončený přechod, váš ping test měří mezeru a ne ikonu, a ukončení klienta obnoví normální konektivitu. Kill switch, který vydrží přepnutí a potom pustí, dělá svou práci. Ten, který pustí brzy nebo nikdy, stojí za ladění.