Kill switch i appen versus kill switch i firewallen: hvad hver især blokerer

En kill switch på en funktionsliste fortæller næsten intet om, hvad der sker, når tunnelen falder. Én implementering lukker udvalgte processer, en anden installerer pakkefiltre ved operativsystemets grænse, og en tredje forsøger blot at genoprette forbindelsen. Forskellen viser sig i sekunderne efter en fejl, ikke på indstillingsskærmen. Gå gennem disse kontroller i rækkefølge og stop ved den første, du ikke kan svare ærligt på, for det er der, din reelle dækning slutter.

Navngiv håndhævelsesmekanismen først

Procesafslutning er en applikationslivscyklusfunktion. Den finder udvalgte programmer efter en registreret tunnelefejl og lukker dem. Alt, der ikke er hovedprocessen, overlever: hjælpetjenester, baggrundssynkronisering og enhver applikation, der startes et sekund senere, har deres egen livscyklus og deres egen timing.

Pakkefiltrering er en operativsystemfunktion. Den afviser trafik, der ikke følger den tilladte vej, hvilket er et stærkere løfte, men kun i det omfang reglen faktisk matcher. Adressefamilie, interface, udelukkede applikationer og undtagelser afgør det, ikke etiketten i klienten.

Overlever blokeringen klienten?

Stil fire spørgsmål i denne rækkefølge: hvad sker der ved et crash, ved manuel afslutning, ved logud og ved genstart. En regel, som klienten selv vedligeholder, fjernes normalt under en pæn nedlukning og ofte efterladt efter et crash. En regel, der installeres i platformens lager, kan opføre sig modsat og overleve både klienten og indimellem afinstallationen.

Luk klienten midt i en lang download og se, om overførslen går i stå eller fortsætter.

Se efter de standardhuller

IPv6 er det første. En regel skrevet til IPv4-adresser lader IPv6-trafik være upåvirket, og mange klienter skriver kun v4-halvdelen. Det andet er interfacet: USB-tethering, en ekstra Wi-Fi-adapter og et mobilt modem er måske ikke omfattet af en regel, der er begrænset til den primære forbindelse. Udelukkede applikationer og undtagelser for det lokale netværk er det tredje.

På Windows kan du læse de installerede regler i stedet for at stole på kontakten: Get-NetFirewallRule -DisplayName '*VPN*' og netsh wfp show filters viser begge, hvad der findes. På Linux dækker iptables -S, ip6tables -S og nft list ruleset de almindelige tilfælde, og det er pointen at sammenligne alle tre.

DNS er den sædvanlige lækage

At blokere TCP, mens UDP 53 står åbent, giver dig en meget overbevisende kill switch, som stadig besvarer hvert værtsnavnopslag. Det samme gælder, når DNS gives til en resolver på et andet interface, eller når klienten kun blokerer v4, og resolveren kan nås via v6.

Med tunnelen nede, slå et kendt navn op og se, om der kommer et svar tilbage. Hvis der gør, er trafikken ikke fuldt blokeret, uanset hvad statusikonet siger.

Test overgangen, ikke kontakten

At slukke VPN’en fra dens egen menu er en pæn nedlukning, og det pæne tilfælde håndterer enhver implementering godt. Den overgang, der betyder noget, er den brutale: dræb tunnelprocessen, træk netværket, lad serveren holde op med at svare. Start derefter en anmodning og se, om den fejler eller stille bruger det fysiske link.

Et resultat fra én bærbar overføres ikke til en telefon eller router. Forskellige platform-API'er, forskellige standarder, og på Android er forskellen skarp: always-on med blokering håndhæves af systemet frem for klienten, så det fortsætter med at virke, når klienten ikke gør. Android VPN-vejledningen beskriver den opdeling.

Hold en vej tilbage

Blokering på systemniveau har den modsatte fejltilstand. Filtre, der overlever klienten, kan efterlade en maskine helt uden netværk efter en afinstallation, hvilket er et supportopkald uden åbenlys årsag. Før du aktiverer en kill switch, der skriver platformregler, skal du notere, hvordan den fjernes, og have leverandørens reparationsvej, hvor du kan finde den.

Hvis du ikke kan svare på crash-, IPv6-, DNS- og overgangskontrollerne for din klient, skal du behandle den som en kontakt på appniveau med kendte huller og planlægge derefter.