Kill-switchen blockerar fortfarande trafik efter att VPN:et kopplats från

Tunneln är borta, nätverksikonen ser normal ut och ingenting laddas. Du kopplade från VPN:et, avinstallerade det eller startade om, och blockeringen som skulle skydda dig vid ett avbrott står kvar. Klientfönstret kan inte förklara det, för det är inte klienten som blockerar dig: beslutet skrevs in i kärnan i ditt namn, och ingenting lämnades kvar för att ta bort det. I Windows ligger det tillståndet i Windows Filtering Platform; i Linux är det en regeluppsättning i iptables eller nftables, ofta med en ögonblicksbild som spelas upp vid start. Följande är ordningen jag använder: läs tillståndet, ta bort det smalaste objektet som förklarar felet och hitta sedan det som ständigt sätter tillbaka det.

En kill-switch är kärntillstånd, inte en inställning

Skrivbordsklienter blockerar genom att lägga till filter som nekar trafik utanför tunneln. I Windows är det WFP-filter på connect-redirect- och transportlagren, och några är beständiga: de registreras i Base Filtering Engines principarkiv och återställs när maskinen startar, innan någon VPN-programvara körs. Klienterna skiljer sig åt i när de städar. Vissa tar bort filter vid frånkoppling, vissa bara vid en ren avslutning, och vissa bara om kill-switchen stängs av först. Avinstallera medan blockeringen är aktiv, eller döda processen, och filtren blir kvar.

Linux-motsvarigheten är en drop- eller reject-regel i utgångsvägen, ibland en forwarding-regel, ibland en ändrad kedjepolicy. De reglerna lever längre än processen som lade till dem eftersom de är kärntillstånd: döda klienten, krascha den eller bryt strömmen, och kärnan fortsätter att släppa paket utan att något finns kvar för att ångra det. Ett beständighetspaket lägger till ett andra lager av varaktighet genom att ta en ögonblicksbild av den aktuella regeluppsättningen och återställa den vid start, så nästa start börjar med blockeringen redan installerad.

Läs WFP-tillståndet innan du tar bort något

Windows levereras med verktygen du behöver. Kör en förhöjd kommandotolk och dumpa plattformstillståndet; dumpen hamnar som wfpstate.xml i arbetskatalogen.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

Sök i XML:en efter namnet på leverantören som försvann, efter en Block-åtgärd och efter lagret. Filter på connect-redirect och transport är de som bryter vanlig trafik; ett filter på ett receive-accept-lager är oftast inte din orsak. Om Base Filtering Engine inte körs alls, leta någon annanstans, för ingenting annat kan genomdriva de filtren.

Kontrollera också den vanliga brandväggsvyn, eftersom de flesta bara inspekterar en av de två:

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

När de inbyggda profilerna är på och ingen regel matchar trafiken som misslyckas kommer blockeringen från en tredjepartsleverantör och inte från Windows Firewall. Den skillnaden avgör vilket verktyg du använder för reparationen.

Läs Linux-reglerna i den syntax du ska ta bort med

iptables -S skriver ut regler i samma form som de lades till, vilket gör utdata direkt återanvändbara för en borttagning. iptables -L -v -n lägger till paketräknare, och de räknarna berättar om en regel verkligen matchar dina misslyckade förfrågningar eller bara sitter i kedjan.

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

Läs kedjepolicyerna, inte bara reglerna: -P OUTPUT DROP blockerar trafik även när ingen regel matchar. Inspektera IPv6 separat, eftersom en klient som installerar båda familjerna kan lämna IPv6-blockeringen på plats efter att IPv4-reglerna är borta, och symtomet beror då på vilken familj en applikation föredrar. Där nftables används, kör också nft list ruleset; de två verktygen samexisterar genom ett kompatibilitetslager, och en lista visar inte nödvändigtvis varje regel som kan släppa ett paket.

Ta bort det smalaste objektet som förklarar felet

I Windows är första steget fortfarande leverantörens egen borttagningsväg: kör installationsprogrammet igen och använd repair eller uninstall, eller kör rensningsverktyget om leverantören publicerar ett. Kvarvarande tjänster och schemalagda uppgifter är vanliga, och en uppgift som startar klienten vid inloggning installerar om filtren vid nästa start. En avinstallation som misslyckas när den läser klientens registernyckel betyder oftast att en tjänst eller uppgift fortfarande håller den, inte att registret är skadat.

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

Beständiga filter är sista utvägen. De ligger under HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, ett värde per filter med GUID som nyckel. Exportera nyckeln först, anteckna GUID:erna du tar bort, ta bara bort de värden som tillhör den bortflyttade klienten och starta sedan om så att motorn bygger upp tillståndet igen. Ta inte bort hela nyckeln och inaktivera inte Base Filtering Engine: Windows Firewall och Defender är beroende av den, och du skulle byta en störning mot en värre.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

I Linux tar du raden som iptables -S skrev ut och ersätter -A med -D. Att ta bort den enda regeln du identifierade är bättre än att tömma en kedja, eftersom din egen policy förblir intakt.

sudo iptables -D OUTPUT -p udp -j REJECT

Om drop-regeln ligger i en användardefinierad kedja, ta först bort hoppet till den kedjan och ta sedan bort kedjan med -X. Att sätta en kedjepolicy till ACCEPT medan drop-regler finns kvar hjälper bara paket som överhuvudtaget når policybeslutet. Att tömma alla tabeller är sista utvägen: det tar också bort regler du lade till av andra skäl, och med ufw aktiverat får det tjänsten att tro att den äger kedjor som inte längre finns.

Hitta ägaren som sätter tillbaka det

Efter den omedelbara reparationen, leta efter det som skulle återställa tillståndet. I Linux kontrollerar du om en beständighetsenhet är aktiverad, om klienten har en inställning för att återställa brandväggen vid inloggning och om en sparad regelfil finns under /etc. I Windows kontrollerar du startposter, tjänster och schemalagda uppgifter igen, startar sedan om och läser tillståndet med samma kommandon som tidigare.

Om blockeringen kommer tillbaka var borttagningen inte lösningen; ägaren var det. Anteckna vilken klient eller tjänst som installerar den och inaktivera funktionen där, i stället för att kämpa mot den på brandväggsnivå efter varje frånkoppling.

Verifiera med riktig trafik, inte en enda ping

Testa en namnsökning, en TCP-anslutning och en ny webbläsarsession, starta sedan om och upprepa samma tre kontroller. En ping som fungerar medan HTTPS misslyckas pekar på ett filter på transportlagret och inte på nätverket, och en blockering som först dyker upp igen efter omstarten pekar på en ägare du ännu inte hittat.

Spara bevisen: den exporterade BFE-nyckeln, eller iptables -S-utdata som fångades före ändringen. Innan du kallar det åtgärdat, bekräfta lagret du tog bort objektet från, ägaren som skulle kunna installera om det, tillståndet efter en ren omstart och att vanligt surfande fungerar utan att en VPN-process körs. Man-sidan för iptables(8) har den exakta syntaxen för borttagning och policy om du skriptar rensningen.