Noodskakelaar hou steeds verkeer teen ná die VPN ontkoppel

Die tonnel is weg, die netwerkikoon lyk normaal, en niks laai nie. Jy het die VPN ontkoppel, of gedeïnstalleer, of herbegin, en die blok wat jou tydens 'n onderbreking moes beskerm, staan steeds. Die kliëntvenster kan dit nie verduidelik nie, want die kliënt is nie wat jou blokkeer nie: die besluit is in jou naam in die kernel geskryf, en niks is agtergelaat om dit te verwyder nie. Op Windows sit daardie toestand in die Windows Filtering Platform; op Linux is dit 'n reëlstel in iptables of nftables, dikwels met 'n momentopname wat by die opstart herspeel word. Wat volg, is die volgorde wat ek gebruik: lees die toestand, verwyder die nouste objek wat die fout verklaar, en vind dan enigiets wat dit aanhou terugbring.

’n Noodskakelaar is kerneltoestand, nie ’n instelling nie

Lessenaarkliënte bewerkstellig blokkering deur filters by te voeg wat verkeer buite die tonnel weier. Op Windows is dit WFP-filters op die verbindingherleiding- en vervoerlae, en sommige daarvan is permanent: hulle word in die Base Filtering Engine se beleidstoor aangeteken en herstel wanneer die masjien opstart, voordat enige VPN-sagteware loop. Kliënte verskil in wanneer hulle opruim. Sommige verwyder filters by ontkoppeling, sommige net by 'n skoon afsluiting, en sommige net wanneer die noodskakelaar eers afgeskakel word. Deïnstalleer terwyl die blok aktief is, of maak die proses dood, en die filters bly staan.

Die Linux-ekwivalent is 'n drop- of reject-reël in die uitvoerpad, soms 'n forward-reël, soms 'n veranderde kettingbeleid. Daardie reëls oorleef die proses wat hulle bygevoeg het omdat hulle kerneltoestand is: maak die kliënt dood, laat dit crash, of sny die krag, en die kernel hou aan om pakkette te laat val sonder dat iets oorbly om dit ongedaan te maak. 'n Persistensiepakket voeg 'n tweede laag permanensie by deur die huidige reëlstel te snap en by die opstart te herstel, sodat die volgende begin met die blok reeds geïnstalleer.

Lees die WFP-toestand voordat jy enigiets verwyder

Windows lewer die gereedskap wat jy nodig het. Voer 'n verhoogde opdragprompt uit en stort die platformtoestand; die stort beland as wfpstate.xml in die werkmap.

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

Soek in die XML na die vertrekte verskaffer se naam, na 'n Block-aksie en na die laag. Filters op verbindingherleiding en vervoer is diegene wat gewone verkeer breek; 'n filter op 'n receive-accept-laag is gewoonlik nie jou oorsaak nie. As die Base Filtering Engine glad nie loop nie, kyk elders, want niks anders kan daardie filters afdwing nie.

Kontroleer ook die gewone firewall-aansig, want die meeste mense ondersoek net een van die twee:

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

Wanneer die ingeboude profiele aan is en geen reël pas by die mislukkende verkeer nie, kom die blok van 'n derdeparty-verskaffer eerder as van Windows Firewall. Daardie onderskeid bepaal watter gereedskap jy vir die herstel gaan gebruik.

Lees Linux-reëls in die sintaksis waarmee jy gaan verwyder

iptables -S druk reëls in dieselfde vorm as wat gebruik word om hulle by te voeg, wat die uitset direk herbruikbaar maak vir 'n verwydering. iptables -L -v -n voeg pakkettellers by, en daardie tellers sê vir jou of 'n reël werklik by jou mislukte versoeke pas of bloot in die ketting sit.

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

Lees die kettingbeleide, nie net die reëls nie: -P OUTPUT DROP blokkeer verkeer selfs wanneer geen reël pas nie. Ondersoek IPv6 afsonderlik, want 'n kliënt wat albei families installeer, kan die IPv6-blok laat staan nadat die IPv4-reëls weg is, en die simptoom hang dan daarvan af watter familie 'n toepassing verkies. Waar nftables in gebruik is, voer ook nft list ruleset uit; die twee gereedskap bestaan saam deur 'n versoenbaarheidslaag, en een lys wys nie noodwendig elke reël wat 'n pakket kan laat val nie.

Verwyder die nouste objek wat die fout verklaar

Op Windows is die eerste stap steeds die verskaffer se eie verwyderingspad: hardloop die installeerder weer en gebruik herstel of deïnstalleer, of voer die opruimgereedskap uit as die verskaffer een publiseer. Oorblywende dienste en geskeduleerde take is algemeen, en 'n taak wat die kliënt by aanmelding begin, installeer sy filters weer by die volgende opstart. 'n Deïnstallasie wat misluk terwyl dit die kliënt se registerleutel lees, beteken gewoonlik dat 'n diens of taak dit steeds vashou, nie dat die register beskadig is nie.

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

Permanente filters is die laaste uitweg. Hulle woon onder HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, een waarde per filter wat deur 'n GUID gesleutel is. Voer die sleutel eerste uit, teken die GUID's aan wat jy verwyder, verwyder net die waardes wat aan die vertrekte kliënt behoort, en herbegin dan sodat die enjin sy toestand herbou. Moenie die hele sleutel verwyder nie en moenie die Base Filtering Engine deaktiveer nie: Windows Firewall en Defender is daarvan afhanklik, en jy sou een onderbreking vir 'n erger een verruil.

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

Op Linux neem jy die reël wat deur iptables -S gedruk is en vervang -A met -D. Om die een reël te verwyder wat jy geïdentifiseer het, is beter as om 'n ketting te spoel, want dit laat jou eie beleid ongeskonde.

sudo iptables -D OUTPUT -p udp -j REJECT

As die drop in 'n gebruikergedefinieerde ketting woon, verwyder eers die sprong na daardie ketting en verwyder die ketting daarna met -X. Om 'n kettingbeleid op ACCEPT te stel terwyl drop-reëls nog daar is, help net pakkette wat die beleidsbeslissing hoegenaamd bereik. Om elke tabel te spoel is 'n laaste uitweg: dit verwyder ook reëls wat jy om ander redes bygevoeg het, en met ufw aan laat dit die diens glo dat hy kettings besit wat nie meer bestaan nie.

Vind die eienaar wat dit terug sit

Ná die onmiddellike herstel, soek na enigiets wat die toestand sou herstel. Op Linux, kyk of 'n persistensie-eenheid geaktiveer is, of die kliënt 'n instelling het om die firewall by aanmelding te herstel, en of 'n gestoorde reël-lêer onder /etc bestaan. Op Windows, kyk weer na outostart-inskrywings, dienste en geskeduleerde take, herbegin dan en lees die toestand weer met dieselfde opdragte as voorheen.

As die blok terugkom, was die verwydering nie die oplossing nie; die eienaar was. Teken aan watter kliënt of diens dit installeer en deaktiveer die funksie daar, eerder as om dit ná elke ontkoppeling op die firewall-laag te beveg.

Verifieer met werklike verkeer, nie 'n enkele ping nie

Toets 'n naamnavraag, 'n TCP-verbinding en 'n vars blaaier-sessie, herbegin dan en herhaal dieselfde drie kontroles. 'n Ping wat werk terwyl HTTPS misluk, wys op 'n vervoerlaagfilter eerder as op die netwerk, en 'n blok wat net ná die herbegin terugkeer, wys op 'n eienaar wat jy nog nie gevind het nie.

Hou die bewyse: die uitgevoerde BFE-sleutel, of die iptables -S-uitset wat voor die verandering vasgevang is. Voordat jy dit as opgelos beskou, bevestig die laag waaruit jy die objek verwyder het, die eienaar wat dit sou kon herinstalleer, die toestand ná een skoon herbegin, en dat gewone blaaiery werk met geen VPN-proses wat loop nie. Die iptables(8)-handleidingblad het die presiese verwyderings- en beleidsintaksis as jy die opruiming skrip.