Prečo kill switch zhodí prevádzku pri zmene servera

Vyberiete server, ktorý vyzerá bližšie, stlačíte pripojiť a prehliadač prestane načítavať skôr, než sa nový tunel zdvihne. Ikona prejde do stavu pripájania a zostane tam, kým každá karta nevyprší. Tá pauza je zvyčajne kill switch, ktorý pracuje podľa návrhu: prevádzka je blokovaná, kým klient nemá tunel, cez ktorý by ju poslal. Či je pauza prijateľná, závisí od toho, čo klient v tých sekundách robí, a od toho, či sa blok zruší, keď tvrdí, že áno.

Čo klient robí medzi dvoma servermi

Zmena koncového bodu je niekoľko krokov, nie jeden prepínač. Klient zbúra aktuálny tunel, aktualizuje svoje pravidlá blokovania, preloží a dosiahne nový koncový bod mimo tunela, potom nainštaluje nové trasy a zruší blok. Medzera, ktorú cítite, leží medzi prvým a posledným krokom.

Poradie je tu dôležitejšie ako rýchlosť. Ak pravidlá blokovania začnú platiť skôr než výnimka pre nový koncový bod, klient nemôže dokončiť podanie ruky a zostane v stave pripájania do vypršania. Ak je výnimka kópiou adresy starého servera, nové podanie ruky vyzerá ako ktorýkoľvek iný odchádzajúci paket a je zahodené. Oba prípady vyzerajú z prehliadača rovnako, a preto zmena, ktorá sa spamätá po šiestich sekundách, a tá, ktorá sa nespamätá nikdy, môžu mať rovnakú príčinu.

Nový koncový bod potrebuje v bloku dieru

Aby klient postavil tunel, musí posielať pakety na adresu a port nového servera cez fyzické rozhranie, napríklad UDP 51820 pri typickom profile WireGuard alebo 1194 a 443 pri OpenVPN, čokoľvek váš profil predpisuje. Táto prevádzka nie je vo vnútri tunela, ktorý práve vznikne, takže blok pre celé zariadenie ju pohltí, ak neexistuje zodpovedajúce povoľovacie pravidlo.

Profily založené na názve hostiteľa pridávajú druhú požiadavku: samotné vyhľadanie. Ak klient preloží koncový bod skôr, než sa blok zdvihne, môže použiť adresu z vyrovnávacej pamäte, ale keď profil otočí adresy alebo záznam v pamäti zostarne, podanie ruky mieri na adresu, ktorú povoľovacie pravidlo nepokrýva. IPv6 to robí viditeľným, pretože koncový bod s dvoma zásobníkmi môže publikovať záznam A aj AAAA a povoľovacie pravidlo pokrývajúce len adresu v4 nechá klienta opakovať pokusy proti blokovanej adrese v6.

Názvy možností a predvolené hodnoty sa líšia podľa klienta a verzie, preto si prečítajte dokumentovaný zoznam pre ten svoj, namiesto hádania zo snímok obrazovky. Referencia nastavení OpenVPN Connect na openvpn.net/connect-docs/app-settings-windows je jedným príkladom toho, ako klient opisuje svoje možnosti blokovania a rozdeleného tunela.

Fail-closed je stavový automat, nie prepínač

Väčšina klientov vyjadruje blok ako firewallovú politiku v troch stavoch: tunel zdvihnutý, prevádzka ide tunelom a blok nie je; tunel spadnutý, blok je aktívny; a prechod, keď je blok aktívny plus dočasné výnimky pre koncový bod. Práve v treťom stave žijú chyby, pretože sa musí zmeniť dvakrát v priebehu pár sekúnd, a neschopnosť z neho vystúpiť vyzerá presne ako trvalý blok.

Mechanizmus sa líši podľa platformy, a zlyhanie tiež. Filtre Windows Filtering Platform majú váhy, takže blokovací filter, ktorý prevažuje vaše povolenie, ďalej zahadzuje pakety, aj keď povolenie existuje, a filtre, ktoré zanechal zabitý proces klienta môžu držať stroj offline po tom, čo aplikácia zmizne. Klienti macOS zvyčajne zapisujú pravidlá pf do anchoru, kde o poradí pravidiel a rýchlych rozhodnutiach závisí, ktoré pravidlo platí. Klienti Linuxu zvyčajne spravujú reťazec nftables alebo iptables s politikou drop a výslovnými povoleniami pre koncový bod, rozhranie tunela a loopback. Always-on VPN v Androide s voľbou blokovať pripojenia bez VPN je najprísnejšia v skupine, pretože systém uplatňuje blok na celé zariadenie, nie na aplikáciu.

WireGuard si zaslúži vlastnú poznámku, pretože AllowedIPs je selektor smerovania, nie blokátor. Rozhoduje, ktoré ciele idú do tunela; nerobí nič pre to, aby paket, ktorý ešte tunel nemá, neodišiel cez Wi-Fi. V zostave len s WireGuardom a bez firewallového pravidla je kill switch vlastne neprítomnosť trasy a po zahodenom podaní ruky môže cez fyzické rozhranie odísť skutočný paket.

Merajte medzeru, namiesto pozerania na ikonu

Sledujte pakety, nie stavovú kontrolku. Na Linuxe spustite pomalý ping na verejnú adresu v jednom termináli a v druhom zachyťte transportný port tunela na fyzickom rozhraní:

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

sudo tcpdump -ni eth0 'udp port 51820'

Prepnutie servera v klientovi urobte, kým oba bežia. Záležia tri veci: ako dlho sa pingy zastavia, či zachytenie ukazuje podanie ruky dosahujúce nový koncový bod a či sa prevádzka vráti pred alebo po tom, ako sa stav klienta zmení na pripojený. Ak sa medzera v pingoch skončí prvá, buď sa blok zrušil príliš skoro, alebo je tunel zdvihnutý skôr, než to indikátor prizná. Ak sa medzera skončí neskôr, indikátor je optimistický.

V Windows netsh wfp show state zapíše snímku, v ktorej môžete hľadať blokovacie filtre, ktoré stále existujú, kým klient tvrdí, že je odpojený. V macOS sudo pfctl -sr vypíše načítané pravidlá a ich poradie. Spojte ktorúkoľvek snímku s vlastným logom klienta; časová os z vášho pingu vám povie, či sa blok skončil neskoro alebo nikdy.

Normálne vytmenie versus zaseknutý blok

Nejaké prerušenie je zmyslom tejto funkcie, preto najprv zatrieďte, než zmeníte akékoľvek nastavenie:

Ak skončíte v druhom alebo piatom riadku, nevypínajte kill switch na test, pretože tým premeníte chybu smerovania na únik. Reštartujte službu klienta alebo reštartujte stroj tam, kde filtre prežijú zabitie procesu, a potom sa pozrite, či sa blok vyčistí. Ak áno, chyba je v upratovaní počas prepnutia, nie v samotnom bloku.

Pred ďalším prepnutím potvrďte štyri veci: povolenie pre koncový bod pokrýva každú rodinu adries, ktorú váš profil prekladá, log klienta ukazuje dokončený prechod, váš ping test meria medzeru a nie ikonu, a ukončenie klienta obnoví normálne pripojenie. Kill switch, ktorý vydrží prepnutie a potom pustí, robí svoju prácu. Ten, ktorý pustí skoro alebo nikdy, stojí za ladenie.