Kill-switchen blokkerer fortsatt trafikk etter at VPN-en kobles fra

Tunnelen er borte, nettverksikonet ser normalt ut, og ingenting lastes. Du koblet fra VPN-en, avinstallerte den eller startet på nytt, og blokkeringen som skulle beskytte deg under et brudd står fortsatt. Klientvinduet kan ikke forklare det, fordi det ikke er klienten som blokkerer deg: avgjørelsen ble skrevet inn i kjernen i ditt navn, og ingenting ble igjen for å fjerne den. I Windows ligger denne tilstanden i Windows Filtering Platform; i Linux er det et regelsett i iptables eller nftables, ofte med et øyeblikksbilde som spilles av ved oppstart. Det følgende er rekkefølgen jeg bruker: les tilstanden, slett det minste objektet som forklarer feilen, og finn deretter det som stadig setter det tilbake.

En kill-switch er kjernetilstand, ikke en innstilling

Skrivebordsklienter blokkerer ved å legge til filtre som avviser trafikk utenfor tunnelen. I Windows er det WFP-filtre på connect-redirect- og transportlagene, og noen av dem er vedvarende: de registreres i Base Filtering Engine-policyen og gjenopprettes når maskinen starter, før noen VPN-programvare kjører. Klientene er forskjellige på når de rydder opp. Noen fjerner filtre ved frakobling, noen bare ved en ren avslutning, og noen bare hvis kill-switchen slås av først. Avinstaller mens blokkeringen er aktiv, eller drep prosessen, og filtrene blir stående.

Linux-ekvivalenten er en drop- eller reject-regel i utgangsbanen, iblant en forwarding-regel, iblant en endret kjedepolicy. Disse reglene lever lenger enn prosessen som la dem til, fordi de er kjernetilstand: drep klienten, krasj den eller kutt strømmen, og kjernen fortsetter å droppe pakker uten at noe er igjen for å angre det. En vedvarende pakke legger til et andre lag av varighet ved å ta et øyeblikksbilde av det gjeldende regelsettet og gjenopprette det ved oppstart, slik at neste start begynner med blokkeringen allerede installert.

Les WFP-tilstanden før du sletter noe

Windows leveres med verktøyene du trenger. Kjør en forhøyet ledetekst og dump plattformtilstanden; dumpen havner som wfpstate.xml i arbeidskatalogen.

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

Søk i XML-en etter navnet på leverandøren som er borte, etter en Block-handling og etter laget. Filtre på connect-redirect og transport er de som bryter vanlig trafikk; et filter på et receive-accept-lag er vanligvis ikke årsaken. Hvis Base Filtering Engine ikke kjører i det hele tatt, se et annet sted, fordi ingenting annet kan håndheve disse filtrene.

Kryssjekk også den vanlige brannmurvisningen, siden folk flest bare undersøker én av de to:

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

Når de innebygde profilene er på og ingen regel samsvarer med trafikken som feiler, kommer blokkeringen fra en tredjepartsleverandør og ikke fra Windows Firewall. Den forskjellen avgjør hvilket verktøy du bruker til reparasjonen.

Les Linux-reglene i syntaksen du skal slette med

iptables -S skriver ut regler i samme form som de ble lagt til, noe som gjør utdataene direkte gjenbrukbare for en sletting. iptables -L -v -n legger til pakketellere, og de tellerne forteller deg om en regel faktisk treffer de mislykkede forespørslene dine eller bare sitter i kjeden.

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

Les kjedepolicyene, ikke bare reglene: -P OUTPUT DROP blokkerer trafikk selv når ingen regel treffer. Undersøk IPv6 separat, fordi en klient som installerer begge familiene, kan la IPv6-blokkeringen stå etter at IPv4-reglene er borte, og symptomet avhenger da av hvilken familie en applikasjon foretrekker. Der nftables er i bruk, kjør også nft list ruleset; de to verktøyene eksisterer side om side gjennom et kompatibilitetslag, og én liste viser ikke nødvendigvis hver regel som kan droppe en pakke.

Slett det minste objektet som forklarer feilen

I Windows er første trinn fortsatt leverandørens egen fjerningsvei: kjør installasjonsprogrammet på nytt og bruk repair eller uninstall, eller kjør opprydningsverktøyet hvis leverandøren publiserer ett. Gjenværende tjenester og planlagte oppgaver er vanlige, og en oppgave som starter klienten ved pålogging, installerer filtrene på nytt ved neste oppstart. En avinstallering som feiler mens den leser klientens registernøkkel, betyr vanligvis at en tjeneste eller oppgave fortsatt holder den, ikke at registeret er skadet.

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

Vedvarende filtre er siste utvei. De ligger under HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, én verdi per filter med GUID som nøkkel. Eksporter nøkkelen først, noter GUID-ene du fjerner, slett bare verdiene som tilhører den bortflyttede klienten, og start på nytt slik at motoren bygger opp tilstanden på nytt. Ikke slett hele nøkkelen og ikke deaktiver Base Filtering Engine: Windows Firewall og Defender er avhengige av den, og du ville byttet en driftsstans mot en verre.

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

I Linux tar du linjen som iptables -S skrev ut, og erstatter -A med -D. Å slette den ene regelen du identifiserte, er bedre enn å tømme en kjede, fordi din egen policy forblir intakt.

sudo iptables -D OUTPUT -p udp -j REJECT

Hvis drop-regelen ligger i en brukerdefinert kjede, sletter du hoppet til den kjeden først og fjerner kjeden med -X etterpå. Å sette en kjedepolicy til ACCEPT mens drop-regler fortsatt finnes, hjelper bare pakker som i det hele tatt når policyavgjørelsen. Å tømme alle tabeller er siste utvei: det fjerner også regler du la til av andre grunner, og med ufw aktivert lar det tjenesten tro at den eier kjeder som ikke lenger finnes.

Finn eieren som setter det tilbake

Etter den umiddelbare reparasjonen, se etter det som ville gjenopprette tilstanden. I Linux sjekker du om en vedvarende enhet er aktivert, om klienten har en innstilling for å gjenopprette brannmuren ved pålogging, og om en lagret regelfil finnes under /etc. I Windows sjekker du oppstartsoppføringer, tjenester og planlagte oppgaver igjen, og starter deretter på nytt og leser tilstanden med de samme kommandoene som før.

Hvis blokkeringen kommer tilbake, var ikke slettingen løsningen; eieren var det. Noter hvilken klient eller tjeneste som installerer den, og deaktiver funksjonen der, i stedet for å kjempe mot den på brannmurnivå etter hver frakobling.

Verifiser med ekte trafikk, ikke én ping

Test et navneoppslag, en TCP-tilkobling og en ny nettleserøkt, og start deretter på nytt og gjenta de samme tre sjekkene. En ping som virker mens HTTPS feiler, peker på et filter på transportlaget og ikke på nettverket, og en blokkering som først dukker opp igjen etter omstarten, peker på en eier du ennå ikke har funnet.

Ta vare på bevisene: den eksporterte BFE-nøkkelen, eller iptables -S-utdataene som ble fanget før endringen. Før du kaller det fikset, bekreft laget du fjernet objektet fra, eieren som kan installere det på nytt, tilstanden etter én ren omstart, og at vanlig nettlesing fungerer uten at en VPN-prosess kjører. Man-siden for iptables(8) har den nøyaktige syntaksen for sletting og policy hvis du skriptlegger opprydningen.