Hvorfor en kill switch slipper trafikken når du bytter server

Du velger en server som ser nærmere ut, trykker koble til, og nettleseren slutter å laste før den nye tunnelen er oppe. Ikonet skifter til en tilkoblingstilstand og blir der mens hver fane løper ut. Den pausen er som regel kill switchen som virker som tenkt: trafikken er blokkert mens klienten ikke har noen tunnel å sende den gjennom. Om pausen er akseptabel avhenger av hva klienten gjør i de sekundene, og om blokkeringen løftes når den sier at den gjør det.

Hva klienten gjør mellom to servere

Et bytte av endepunkt er flere trinn, ikke én bryter. Klienten river ned den gjeldende tunnelen, oppdaterer blokkeringsreglene sine, slår opp og når det nye endepunktet utenfor tunnelen, og installerer deretter de nye rutene og løfter blokkeringen. Gapet du merker ligger mellom første og siste trinn.

Rekkefølgen betyr mer enn hastigheten her. Hvis blokkeringsreglene trer i kraft før unntaket for det nye endepunktet, kan ikke klienten fullføre håndtrykket og blir stående på kobler til til det oppstår tidsavbrudd. Hvis unntaket er en kopi av den gamle serverens adresse, ser det nye håndtrykket ut som en hvilken som helst annen utgående pakke og blir droppet. Begge tilfellene ser like ut fra nettleseren, og derfor kan et bytte som kommer seg etter seks sekunder og et som aldri kommer seg dele samme årsak.

Det nye endepunktet trenger et hull i blokkeringen

For å bygge tunnelen må klienten sende pakker til den nye serverens adresse og port på det fysiske grensesnittet, for eksempel UDP 51820 for en typisk WireGuard-profil eller 1194 og 443 for OpenVPN, uansett hva din egen profil angir. Den trafikken er ikke inne i tunnelen som er i ferd med å bli laget, så en blokkering for hele enheten svelger den med mindre det finnes en tilsvarende tillatelsesregel.

Profiler basert på vertsnavn legger til et andre krav: selve oppslaget. Hvis klienten slår opp endepunktet før blokkeringen går opp, kan den bruke en bufret adresse, men når profilen rullerer adresser eller den bufrede oppføringen blir utdatert, går håndtrykket mot en adresse som tillatelsesregelen ikke dekker. IPv6 gjør dette synlig, fordi et endepunkt med dobbel stakk kan publisere både en A- og en AAAA-oppføring, og en tillatelsesregel som bare dekker v4-adressen lar klienten prøve på nytt mot en blokkert v6-adresse.

Navn på alternativer og standardverdier varierer etter klient og versjon, så les den dokumenterte listen for din i stedet for å gjette fra skjermbilder. Referansen for OpenVPN Connect-innstillingene på openvpn.net/connect-docs/app-settings-windows er ett eksempel på hvordan en klient beskriver sine blokk- og delt-tunnel-alternativer.

Fail-closed er en tilstandsmaskin, ikke en bryter

De fleste klienter uttrykker blokkeringen som brannmurpolitikk i tre tilstander: tunnel oppe, med trafikk gjennom tunnelen og ingen blokkering; tunnel nede, med blokkeringen aktiv; og overgang, med blokkeringen aktiv pluss midlertidige unntak for endepunktet. Det er i den tredje tilstanden feilene bor, fordi den må endre seg to ganger i løpet av noen sekunder, og å ikke komme seg ut av den ser nøyaktig ut som en permanent blokkering.

Mekanismen varierer etter plattform, og feilen også. Windows Filtering Platform-filtre har vekter, så et blokkeringsfilter som overgår tillatelsen din fortsetter å droppe pakker selv om tillatelsen finnes, og filtre som en drept klientprosess har etterlatt kan holde maskinen offline etter at appen er borte. macOS-klienter skriver vanligvis pf-regler i et anker, der regelrekkefølge og raske beslutninger avgjør hvilken regel som gjelder. Linux-klienter styrer vanligvis en nftables- eller iptables-kjede med drop-policy og eksplisitte tillatelser for endepunktet, tunnelgrensesnittet og loopback. Androids alltid-på-VPN med alternativet for å blokkere tilkoblinger uten VPN er den strengeste i gruppen, fordi operativsystemet bruker blokkeringen på hele enheten i stedet for per app.

WireGuard trenger sitt eget notat, fordi AllowedIPs er en rutevelger, ikke en blokkerer. Den avgjør hvilke destinasjoner som går i tunnelen; den gjør ingenting for å hindre en pakke uten tunnel i å gå ut over Wi-Fi. I et oppsett med bare WireGuard og ingen brannmurregel er kill switchen i virkeligheten fraværet av en rute, og etter et droppet håndtrykk kan en ekte pakke gå ut over det fysiske grensesnittet.

Mål gapet i stedet for å se på ikonet

Følg med på pakker, ikke statuslampen. På Linux starter du en langsom ping mot en offentlig adresse i ett terminalvindu og fanger tunnelens transportport på det fysiske grensesnittet i et annet:

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

sudo tcpdump -ni eth0 'udp port 51820'

Bytt server i klienten mens begge kjører. Tre ting betyr noe: hvor lenge pingene stopper, om fangsten viser at håndtrykket når det nye endepunktet, og om trafikken kommer tilbake før eller etter at klientens tilstand skifter til tilkoblet. Hvis ping-gapet slutter først, er blokkeringen enten løftet for tidlig, eller tunnelen er oppe før indikatoren innrømmer det. Hvis gapet slutter senere, er indikatoren optimistisk.

På Windows skriver netsh wfp show state et øyeblikksbilde der du kan søke etter blokkeringsfiltre som fortsatt finnes mens klienten hevder å være frakoblet. På macOS viser sudo pfctl -sr de innlastede reglene og rekkefølgen deres. Koble et av øyeblikksbildene til klientens egen logg; tidslinjen fra pingingen din forteller om blokkeringen sluttet sent eller aldri.

Normalt utfall kontra en fastlåst blokkering

Litt avbrudd er hele poenget med funksjonen, så gjør en vurdering før du endrer noen innstilling:

Hvis du ender i andre eller femte rad, ikke slå av kill switchen for å teste, for det gjør en rutefeil om til en lekkasje. Start klienttjenesten på nytt, eller start maskinen på nytt der filtre overlever at en prosess drepes, og se om blokkeringen forsvinner. Gjør den det, ligger feilen i oppryddingen under byttet og ikke i blokkeringen selv.

Før ditt neste bytte, bekreft fire ting: tillatelsen for endepunktet dekker hver adressefamilie profilen din slår opp, klientloggen viser at overgangen fullføres, pingtesten din måler gapet og ikke ikonet, og å avslutte klienten gjenoppretter normal tilkobling. En kill switch som holder under byttet og slipper etterpå, gjør jobben sin. En som slipper tidlig, eller aldri, er verdt å feilsøke.