Varför en kill switch tappar trafiken när du byter server
Varför en kill switch blockerar trafiken under ett serverbyte, vad klienten gör i det fönstret och hur du skiljer en normal paus från en fastlåst blockering.
Du väljer en server som ser närmare ut, trycker på anslut, och webbläsaren slutar ladda innan den nya tunneln är uppe. Ikonen växlar till ett anslutande läge och stannar där medan varje flik löper ut. Den pausen är oftast kill switchen som arbetar som tänkt: trafiken blockeras medan klienten inte har någon tunnel att skicka den genom. Om pausen är acceptabel beror på vad klienten gör under de sekunderna, och på om blockeringen hävs när den säger att den gör det.
Vad klienten gör mellan två servrar
Ett byte av slutpunkt är flera steg, inte en enda omkopplare. Klienten river ner den nuvarande tunneln, uppdaterar sina blockeringsregler, slår upp och når den nya slutpunkten utanför tunneln, installerar sedan de nya rutterna och häver blockeringen. Glappet du känner ligger mellan första och sista steget.
Ordningen är viktigare än hastigheten här. Om blockeringsreglerna träder i kraft före undantaget för den nya slutpunkten kan klienten inte slutföra handskakningen och stannar på ansluter tills en tidsgräns inträffar. Om undantaget är en kopia av den gamla serverns adress ser den nya handskakningen ut som vilket annat utgående paket som helst och släpps. Båda fallen ser likadana ut från webbläsaren, och därför kan ett byte som återhämtar sig efter sex sekunder och ett som aldrig återhämtar sig dela samma orsak.
Den nya slutpunkten behöver ett hål i blockeringen
För att bygga tunneln måste klienten skicka paket till den nya serverns adress och port på det fysiska gränssnittet, till exempel UDP 51820 för en typisk WireGuard-profil eller 1194 och 443 för OpenVPN, vad din egen profil nu anger. Den trafiken ligger inte inne i tunneln som just ska skapas, så en blockering för hela enheten sväljer den om det inte finns en matchande tillåtelseregel.
Profiler baserade på värdnamn lägger till ett andra krav: själva uppslaget. Om klienten slår upp slutpunkten innan blockeringen går upp kan den använda en cachad adress, men när profilen roterar adresser eller den cachade posten blir gammal går handskakningen mot en adress som tillåtelseregeln inte täcker. IPv6 gör detta synligt, eftersom en slutpunkt med dubbel stack kan publicera både en A- och en AAAA-post, och en tillåtelseregel som bara täcker v4-adressen låter klienten försöka igen mot en blockerad v6-adress.
Namn på alternativ och standardvärden varierar mellan klienter och versioner, så läs den dokumenterade listan för din i stället för att gissa från skärmbilder. Referensen för OpenVPN Connect-inställningarna på openvpn.net/connect-docs/app-settings-windows är ett exempel på hur en klient beskriver sina blockerings- och delade tunnelalternativ.
Fail-closed är en tillståndsmaskin, inte en omkopplare
De flesta klienter uttrycker blockeringen som brandväggspolicy i tre tillstånd: tunnel uppe, med trafik genom tunneln och ingen blockering; tunnel nere, med blockeringen aktiv; och övergång, med blockeringen aktiv plus tillfälliga undantag för slutpunkten. Det är i det tredje tillståndet felen bor, eftersom det måste ändras två gånger inom några sekunder, och att inte komma ur det ser exakt ut som en permanent blockering.
Mekanismen skiljer sig mellan plattformar, och felet också. Filter i Windows Filtering Platform har vikter, så ett blockeringsfilter som överstiger din tillåtelse fortsätter släppa paket trots att tillåtelsen finns, och filter som en dödad klientprocess lämnat kvar kan hålla maskinen offline efter att appen är borta. macOS-klienter skriver oftast pf-regler i ett ankare, där regelordning och snabba beslut avgör vilken regel som gäller. Linux-klienter hanterar oftast en nftables- eller iptables-kedja med drop-policy och uttryckliga tillåtelser för slutpunkten, tunnelgränssnittet och loopback. Androids alltid-på-VPN med alternativet att blockera anslutningar utan VPN är den strängaste i gruppen, eftersom operativsystemet tillämpar blockeringen på hela enheten och inte per app.
WireGuard förtjänar en egen not: AllowedIPs är en ruttväljare, inte en blockerare. Den avgör vilka destinationer som går in i tunneln; den gör inget för att hindra ett paket utan tunnel från att gå ut över Wi-Fi. I en uppsättning med bara WireGuard och utan brandväggsregel är kill switchen i själva verket avsaknaden av en rutt, och efter en släppt handskakning kan ett riktigt paket gå ut över det fysiska gränssnittet.
Mät glappet i stället för att titta på ikonen
Följ paketen, inte statuslampan. På Linux startar du en långsam ping mot en offentlig adress i en terminal och fångar tunnelns transportport på det fysiska gränssnittet i en annan:
ping -i 0.2 -c 100 1.1.1.1 | tail -5
sudo tcpdump -ni eth0 'udp port 51820'
Byt server i klienten medan båda kör. Tre saker spelar roll: hur länge pingarna stannar, om fångsten visar att handskakningen når den nya slutpunkten, och om trafiken kommer tillbaka före eller efter att klientens tillstånd växlar till ansluten. Om ping-glappet slutar först är blockeringen antingen hävd för tidigt eller så är tunneln uppe innan indikatorn medger det. Om glappet slutar senare är indikatorn optimistisk.
På Windows skriver netsh wfp show state en ögonblicksbild där du kan söka efter blockeringsfilter som fortfarande finns medan klienten hävdar att den är frånkopplad. På macOS listar sudo pfctl -sr de inlästa reglerna och deras ordning. Koppla någon av ögonblicksbilderna till klientens egen logg; tidslinjen från din ping säger om blockeringen slutade sent eller aldrig.
Normalt mörker kontra en fastlåst blockering
Lite avbrott är hela poängen med funktionen, så gör en bedömning innan du ändrar någon inställning:
| What you see | Usually means | Next check |
|---|---|---|
| Two or three seconds of timeouts, then normal browsing | Expected fail-closed gap | Nothing to fix |
| State says connected, traffic stays dead | Block filter or route left behind | Firewall snapshot, client log |
| One app dead while others work | TCP session bound to the old exit address | Restart the app |
| LAN devices unreachable after the switch | LAN exception not reapplied | Allow-LAN or split-tunnel setting |
| New server hangs, the old one reconnects | Permit covers only the old address | Resolved address of the new host, including AAAA |
Om du hamnar i andra eller femte raden ska du inte stänga av kill switchen för att testa, för det förvandlar en ruttbugg till en läcka. Starta om klientens tjänst, eller starta om maskinen där filter överlever att en process dödas, och se om blockeringen försvinner. Gör den det ligger felet i städningen under bytet och inte i blockeringen själv.
Före ditt nästa byte, bekräfta fyra saker: tillåtelsen för slutpunkten täcker varje adressfamilj som din profil slår upp, klientloggen visar att övergången slutförs, ditt pingtest mäter glappet och inte ikonen, och att avsluta klienten återställer normal anslutning. En kill switch som håller under bytet och släpper efteråt gör sitt jobb. En som släpper tidigt, eller aldrig, är värd att felsöka.