Zakaj kill switch odreže promet ob menjavi strežnika

Izberete strežnik, ki se zdi bližje, pritisnete poveži in brskalnik preneha nalagati, preden se novi tunel dvigne. Ikona preide v stanje povezovanja in tam ostane, dokler vsak zavihek ne poteče. Ta pavza je običajno kill switch, ki dela po načrtu: promet je blokiran, dokler odjemalec nima tunela, skozi katerega bi ga poslal. Ali je pavza sprejemljiva, je odvisno od tega, kaj odjemalec v teh sekundah počne, in od tega, ali se blokada dvigne, ko trdi, da se je.

Kaj odjemalec počne med dvema strežnikoma

Menjava končne točke je več korakov, ne eno stikalo. Odjemalec poruši trenutni tunel, posodobi svoja pravila blokiranja, razreši in doseže novo končno točko zunaj tunela, nato namesti nove poti in dvigne blokado. Vrzel, ki jo občutite, je med prvim in zadnjim korakom.

Vrstni red je tu pomembnejši od hitrosti. Če pravila blokiranja stopijo v veljavo pred izjemo za novo končno točko, odjemalec ne more dokončati rokovanja in ostane v stanju povezovanja do poteka časa. Če je izjema kopija naslova starega strežnika, je novo rokovanje videti kot kateri koli drug odhodni paket in je zavrženo. Oba primera sta iz brskalnika videti enako, zato imata lahko menjava, ki si opomore po šestih sekundah, in tista, ki si ne opomore nikoli, isti vzrok.

Nova končna točka potrebuje luknjo v blokadi

Da bi zgradil tunel, mora odjemalec pošiljati pakete na naslov in vrata novega strežnika prek fizičnega vmesnika, na primer UDP 51820 pri običajnem profilu WireGuard ali 1194 in 443 pri OpenVPN, karkoli predpisuje vaš profil. Ta promet ni znotraj tunela, ki šele nastaja, zato ga blokada za celotno napravo pogoltne, razen če obstaja ustrezno dovoljevalno pravilo.

Profili na podlagi imena gostitelja dodajo drugo zahtevo: samo iskanje. Če odjemalec razreši končno točko, preden se blokada dvigne, lahko uporabi predpomnjen naslov, ko pa profil zamenja naslove ali predpomnjeni vnos postane star, rokovanje krene proti naslovu, ki ga dovoljevalno pravilo ne pokriva. IPv6 to naredi vidno, ker končna točka z dvojnim skladom lahko objavi zapis A in AAAA, dovoljevalno pravilo, ki pokriva le naslov v4, pa pusti odjemalca, da znova poskuša proti blokiranemu naslovu v6.

Imena možnosti in privzete vrednosti se razlikujejo glede na odjemalca in različico, zato preberite dokumentirani seznam za svojega, namesto da ugibate s posnetkov zaslona. Referenca nastavitev OpenVPN Connect na openvpn.net/connect-docs/app-settings-windows je en primer, kako odjemalec opisuje svoje možnosti blokiranja in razdeljenega tunela.

Fail-closed je stroj stanj, ne stikalo

Večina odjemalcev izrazi blokado kot požarnozidno politiko v treh stanjih: tunel gor, promet gre skozi tunel in blokade ni; tunel dol, blokada je aktivna; in prehod, ko je blokada aktivna plus začasne izjeme za končno točko. Prav v tretjem stanju živijo hrošči, ker se mora spremeniti dvakrat v nekaj sekundah, in nezmožnost izhoda iz njega je videti natanko kot trajna blokada.

Mehanizem se razlikuje glede na platformo, in tudi odpoved. Filtri Windows Filtering Platform imajo uteži, zato blokirni filter, ki pretehta vaše dovoljenje, še naprej zavrača pakete, čeprav dovoljenje obstaja, in filtri, ki jih je pustil ubit proces odjemalca lahko držijo stroj brez povezave, potem ko aplikacije ni več. Odjemalci macOS običajno pišejo pravila pf v sidro, kjer vrstni red pravil in hitre odločitve določijo, katero pravilo velja. Odjemalci Linuxa običajno upravljajo verigo nftables ali iptables s politiko drop in izrecnimi dovoljenji za končno točko, vmesnik tunela in loopback. Način always-on VPN v Androidu z možnostjo blokiranja povezav brez VPN je najstrožji v skupini, ker sistem uporabi blokado za celotno napravo in ne za posamezno aplikacijo.

WireGuard si zasluži svojo opombo, ker je AllowedIPs izbirnik poti, ne blokator. Odloča, katere destinacije gredo v tunel; ne naredi ničesar, da bi paket brez tunela ne šel ven prek Wi-Fi. V postavitvi samo z WireGuardom in brez požarnozidnega pravila je kill switch v resnici odsotnost poti, po zavrženem rokovanju pa lahko skozi fizični vmesnik odide resničen paket.

Izmerite vrzel, namesto da gledate ikono

Opazujte pakete, ne lučke stanja. V Linuxu zaženite počasen ping na javni naslov v enem terminalu in v drugem zajemite transportna vrata tunela na fizičnem vmesniku:

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

sudo tcpdump -ni eth0 'udp port 51820'

Zamenjajte strežnik v odjemalcu, medtem ko oba tečeta. Pomembne so tri stvari: kako dolgo se pingi ustavijo, ali zajem pokaže, da rokovanje doseže novo končno točko, in ali se promet vrne prej ali potem, ko se stanje odjemalca spremeni v povezano. Če se vrzel v pingih konča prva, je bila blokada dvignjena prezgodaj ali pa je tunel gor, preden to indikator prizna. Če se vrzel konča pozneje, je indikator preveč optimističen.

V Windows netsh wfp show state zapiše posnetek, v katerem lahko iščete blokirne filtre, ki še vedno obstajajo, medtem ko odjemalec trdi, da je prekinjen. V macOS sudo pfctl -sr našteje naložena pravila in njihov vrstni red. Povežite kateri koli posnetek z lastnim dnevnikom odjemalca; časovnica iz vašega pinginga pove, ali se je blokada končala pozno ali nikoli.

Običajna zatemnitev proti zataknjeni blokadi

Nekaj prekinitve je smisel te funkcije, zato najprej razvrstite, preden spremenite katero koli nastavitev:

Če pristanete v drugi ali peti vrstici, ne izklopite kill switcha za preizkus, ker to spremeni napako usmerjanja v uhajanje. Znova zaženite storitev odjemalca ali znova zaženite stroj tam, kjer filtri preživijo ubijanje procesa, in poglejte, ali se blokada počisti. Če se, je napaka v čiščenju med menjavo in ne v blokadi sami.

Pred naslednjo menjavo potrdite štiri stvari: dovoljenje za končno točko pokriva vsako družino naslovov, ki jo vaš profil razreši, dnevnik odjemalca kaže dokončan prehod, vaš ping test meri vrzel in ne ikono, in zaprtje odjemalca obnovi običajno povezljivost. Kill switch, ki zdrži menjavo in nato spusti, opravlja svoje delo. Tisti, ki spusti zgodaj ali nikoli, si zasluži razhroščevanje.