Kill-switchen blokkerer framleis trafikk etter at VPN-en vert kopla frå

Tunnelen er borte, nettverksikonet ser normalt ut, og ingenting lastar. Du kopla frå VPN-en, avinstallerte han eller starta på nytt, og blokkeringa som skulle verna deg under eit brot står framleis. Klientvindauget kan ikkje forklare det, fordi det ikkje er klienten som blokkerer deg: avgjerda vart skriven inn i kjernen i namnet ditt, og ingenting vart late att for å fjerne ho. I Windows ligg denne tilstanden i Windows Filtering Platform; i Linux er det eit regelsett i iptables eller nftables, ofte med eit augneblinksbilete som vert spela av ved oppstart. Det følgjande er rekkjefølgja eg brukar: les tilstanden, slett den minste gjenstanden som forklarer feilen, og finn deretter det som stadig set han tilbake.

Ein kill-switch er kjernetilstand, ikkje ei innstilling

Skrivebordsklientar blokkerer ved å leggje til filter som avviser trafikk utanfor tunnelen. I Windows er det WFP-filter på connect-redirect- og transportlaga, og nokre av dei er varige: dei vert registrerte i Base Filtering Engine-policyen og gjenoppretta når maskinen startar, før noka VPN-programvare køyrer. Klientane er ulike på når dei ryddar opp. Nokre fjernar filter ved fråkopling, nokre berre ved ei rein avslutning, og nokre berre om kill-switchen vert slått av først. Avinstaller medan blokkeringa er aktiv, eller drep prosessen, og filtra vert ståande.

Linux-ekvivalenten er ein drop- eller reject-regel i utgangsbana, iblant ein forwarding-regel, iblant ein endra kjedepolicy. Desse reglane lever lengre enn prosessen som la dei til, fordi dei er kjernetilstand: drep klienten, krasj han eller kutt straumen, og kjernen held fram med å droppe pakkar utan at noko er att for å angre det. Ein varig pakke legg til eit andre lag av varigheit ved å ta eit augneblinksbilete av det gjeldande regelsettet og gjenopprette det ved oppstart, slik at neste start byrjar med blokkeringa allereie installert.

Les WFP-tilstanden før du slettar noko

Windows kjem med verktya du treng. Køyr ei forhøgd ledetekst og dump plattformtilstanden; dumpen hamnar som wfpstate.xml i arbeidskatalogen.

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

Søk i XML-en etter namnet på leverandøren som er borte, etter ei Block-handling og etter laget. Filter på connect-redirect og transport er dei som bryt vanleg trafikk; eit filter på eit receive-accept-lag er vanlegvis ikkje årsaka. Viss Base Filtering Engine ikkje køyrer i det heile, sjå ein annan stad, fordi ingenting anna kan handheve desse filtra.

Kryssjekk òg den vanlege brannmurvisinga, sidan folk flest berre undersøkjer éin av dei to:

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

Når dei innebygde profilane er på og ingen regel svarar til trafikken som feilar, kjem blokkeringa frå ein tredjepartsleverandør og ikkje frå Windows Firewall. Den skilnaden avgjer kva verkty du brukar til reparasjonen.

Les Linux-reglane i syntaksen du skal slette med

iptables -S skriv ut reglar i same form som dei vart lagde til, noko som gjer utdataa direkte gjenbrukbare for ei sletting. iptables -L -v -n legg til pakketeljarar, og dei teljarane fortel deg om ein regel faktisk treff dei mislukka førespurnadene dine eller berre sit i kjeda.

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

Les kjedepolicyane, ikkje berre reglane: -P OUTPUT DROP blokkerer trafikk sjølv når ingen regel treff. Undersøk IPv6 separat, fordi ein klient som installerer begge familiane, kan la IPv6-blokkeringa stå etter at IPv4-reglane er borte, og symptomet avheng då av kva familie ein applikasjon føretrekkjer. Der nftables er i bruk, køyr òg nft list ruleset; dei to verktya finst side om side gjennom eit kompatibilitetslag, og éi liste viser ikkje nødvendigvis kvar regel som kan droppe ein pakke.

Slett den minste gjenstanden som forklarer feilen

I Windows er første steg framleis leverandøren sin eigen fjerningsveg: køyr installasjonsprogrammet på nytt og bruk repair eller uninstall, eller køyr oppryddingsverktyet viss leverandøren publiserer eitt. Attverande tenester og planlagde oppgåver er vanlege, og ei oppgåve som startar klienten ved pålogging, installerer filtra på nytt ved neste oppstart. Ei avinstallering som feilar medan ho les registernøkkelen til klienten, tyder vanlegvis at ei teneste eller oppgåve framleis held han, ikkje at registeret er skadd.

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

Varige filter er siste utveg. Dei ligg under HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, éin verdi per filter med GUID som nøkkel. Eksporter nøkkelen først, noter GUID-ane du fjernar, slett berre verdiane som høyrer til den bortflytta klienten, og start på nytt slik at motoren byggjer opp tilstanden på nytt. Ikkje slett heile nøkkelen og ikkje deaktiver Base Filtering Engine: Windows Firewall og Defender er avhengige av han, og du ville bytt ein driftsstans mot ein verre.

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

I Linux tek du lina som iptables -S skreiv ut, og erstattar -A med -D. Å slette den eine regelen du identifiserte, er betre enn å tømme ei kjede, fordi din eigen policy held seg intakt.

sudo iptables -D OUTPUT -p udp -j REJECT

Viss drop-regelen ligg i ei brukardefinert kjede, slettar du hoppet til den kjeda først og fjernar kjeda med -X etterpå. Å setje ein kjedepolicy til ACCEPT medan drop-reglar framleis finst, hjelper berre pakkar som i det heile når policyavgjerda. Å tømme alle tabellar er siste utveg: det fjernar òg reglar du la til av andre grunnar, og med ufw aktivert lèt det tenesta tru at ho eig kjeder som ikkje lenger finst.

Finn eigaren som set han tilbake

Etter den umiddelbare reparasjonen, sjå etter det som ville gjenopprette tilstanden. I Linux sjekkar du om ei varig eining er aktivert, om klienten har ei innstilling for å gjenopprette brannmuren ved pålogging, og om ei lagra regelfil finst under /etc. I Windows sjekkar du oppstartsoppføringar, tenester og planlagde oppgåver igjen, og startar deretter på nytt og les tilstanden med dei same kommandoane som før.

Viss blokkeringa kjem tilbake, var ikkje slettinga løysinga; eigaren var det. Noter kva klient eller teneste som installerar henne, og deaktiver funksjonen der, i staden for å kjempe mot han på brannmurnivå etter kvar fråkopling.

Stadfest med ekte trafikk, ikkje éin ping

Test eit namneoppslag, ei TCP-tilkopling og ei ny nettlesarøkt, og start deretter på nytt og gjer dei same tre sjekkane på nytt. Ein ping som verkar medan HTTPS feilar, peikar på eit filter på transportlaget og ikkje på nettverket, og ei blokkering som først dukkar opp igjen etter omstarten, peikar på ein eigar du enno ikkje har funne.

Ta vare på prova: den eksporterte BFE-nøkkelen, eller iptables -S-utdataa som vart fanga før endringa. Før du kallar det fiksa, stadfest laget du fjerna gjenstanden frå, eigaren som kan installere han på nytt, tilstanden etter éin rein omstart, og at vanleg nettlesing fungerer utan at ein VPN-prosess køyrer. Man-sida for iptables(8) har den nøyaktige syntaksen for sletting og policy viss du skriptar oppryddinga.