Sikkerhedsafbryderen blokerer stadig trafik, efter at VPN’en er afbrudt

Tunnelen er væk, netværksikonet ser normalt ud, og intet indlæses. Du afbrød VPN’en, afinstallerede den eller genstartede, og den blokering, der skulle beskytte dig under et afbrud, står stadig. Klientvinduet kan ikke forklare det, for det er ikke klienten, der blokerer dig: beslutningen blev skrevet ind i kernen i dit navn, og der blev ikke efterladt noget til at fjerne den. I Windows ligger den tilstand i Windows Filtering Platform; i Linux er det et regelsæt i iptables eller nftables, ofte med et snapshot, der afspilles ved opstart. Det følgende er den rækkefølge, jeg bruger: læs tilstanden, slet det snævreste objekt, der forklarer fejlen, og find så alt, der bliver ved med at sætte det tilbage.

En sikkerhedsafbryder er kerne-tilstand, ikke en indstilling

Skrivebordsklienter implementerer blokering ved at tilføje filtre, der afviser trafik uden for tunnelen. I Windows er det WFP-filtre på forbindelsesomdirigerings- og transportlaget, og nogle af dem er vedvarende: de registreres i Base Filtering Engines politiklager og gendannes, når maskinen starter, før nogen VPN-software kører. Klienter er forskellige med hensyn til, hvornår de rydder op. Nogle fjerner filtre ved afbrydelse, andre kun ved en ren afslutning, og andre kun når sikkerhedsafbryderen først slås fra. Afinstaller, mens blokeringen er aktiv, eller dræb processen, og filtrene bliver.

Linux-ækvivalenten er en drop- eller reject-regel i udgangsstien, nogle gange en videresendelsesregel, nogle gange en ændret kædepolitik. De regler overlever den proces, der tilføjede dem, fordi de er kerne-tilstand: dræb klienten, crash den, eller skær strømmen, og kernen bliver ved med at droppe pakker, uden at der er noget tilbage til at fortryde det. En persistence-pakke tilføjer et andet lag af permanens ved at tage et snapshot af det aktuelle regelsæt og gendanne det ved opstart, så den næste start begynder med blokeringen allerede installeret.

Læs WFP-tilstanden, før du sletter noget

Windows leverer de værktøjer, du har brug for. Kør en forhøjet prompt, og dump platformens tilstand; dumpet lander som wfpstate.xml i arbejdsbiblioteket.

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

Søg i XML’en efter den afgåede udbyders navn, en Block-handling og laget. Filtre på forbindelsesomdirigering og transport er dem, der ødelægger normal trafik; et filter på et receive-accept-lag er normalt ikke din årsag. Hvis Base Filtering Engine slet ikke kører, så se et andet sted, for intet andet kan håndhæve de filtre.

Tjek også den almindelige firewall-visning, for de fleste undersøger kun en af de to:

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

Når de indbyggede profiler er slået til, og ingen regel matcher den svigtende trafik, kommer blokeringen fra en tredjepartsudbyder og ikke fra Windows Firewall. Den forskel afgør, hvilket værktøj du bruger til reparationen.

Læs Linux-regler i den syntaks, du vil slette med

iptables -S udskriver regler i samme form, som bruges til at tilføje dem, hvilket gør outputtet direkte genbrugeligt til en sletning. iptables -L -v -n tilføjer pakketællere, og de tællere fortæller dig, om en regel faktisk matcher dine mislykkede anmodninger, eller blot sidder i kæden.

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

Læs kædepolitikkerne, ikke kun reglerne: -P OUTPUT DROP blokerer trafik, selv når ingen regel matcher. Undersøg IPv6 separat, for en klient, der installerer begge familier, kan efterlade IPv6-blokeringen, efter at IPv4-reglerne er væk, og symptomet afhænger så af, hvilken familie et program foretrækker. Hvor nftables bruges, skal du også køre nft list ruleset; de to værktøjer eksisterer side om side gennem et kompatibilitetslag, og én visning viser ikke nødvendigvis hver regel, der kan droppe en pakke.

Slet det snævreste objekt, der forklarer fejlen

I Windows er det første skridt stadig udbyderens egen fjernelsesvej: kør installationsprogrammet igen, og brug reparation eller afinstallation, eller kør oprydningsværktøjet, hvis udbyderen udgiver et. Efterladte tjenester og planlagte opgaver er almindelige, og en opgave, der starter klienten ved logon, geninstallerer dens filtre ved næste opstart. En afinstallation, der fejler, mens den læser klientens registreringsnøgle, betyder normalt, at en tjeneste eller opgave stadig holder den, ikke at registreringsdatabasen er beskadiget.

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

Vedvarende filtre er den sidste udvej. De ligger under HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, én værdi for hvert filter med GUID som nøgle. Eksportér nøglen først, notér de GUID’er, du fjerner, slet kun de værdier, der tilhører den afgåede klient, og genstart så, så motoren genopbygger sin tilstand. Slet ikke hele nøglen, og deaktiver ikke Base Filtering Engine: Windows Firewall og Defender afhænger af den, og du ville bytte et udfald for et værre.

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

På Linux tager du den linje, iptables -S udskriver, og erstatter -A med -D. At slette den ene regel, du har identificeret, er bedre end at skylle en kæde, fordi det lader din egen politik være intakt.

sudo iptables -D OUTPUT -p udp -j REJECT

Hvis droppet ligger i en brugerdefineret kæde, skal du først slette springet til den kæde og derefter fjerne kæden med -X. At sætte en kædepolitik til ACCEPT, mens drop-regler stadig er til stede, hjælper kun pakker, der overhovedet når politikbeslutningen. At skylle hver tabel er en sidste udvej: det fjerner også regler, du tilføjede af andre grunde, og med ufw aktiveret efterlader det tjenesten i den tro, at den ejer kæder, der ikke findes længere.

Find ejeren, der sætter det tilbage

Efter den øjeblikkelige reparation skal du lede efter alt, der ville gendanne tilstanden. På Linux skal du kontrollere, om en persistence-enhed er aktiveret, om klienten har en indstilling til at gendanne firewallen ved login, og om der findes en gemt regelfil under /etc. På Windows skal du igen kontrollere opstartsindgange, tjenester og planlagte opgaver, derefter genstarte og læse tilstanden igen med de samme kommandoer som før.

Hvis blokeringen vender tilbage, var sletningen ikke løsningen; ejeren var. Notér, hvilken klient eller tjeneste der installerer den, og deaktiver funktionen der i stedet for at bekæmpe den på firewall-laget efter hver afbrydelse.

Verificér med rigtig trafik, ikke et enkelt ping

Test et navneopslag, en TCP-forbindelse og en frisk browsersession, og genstart derefter og gentag de samme tre tjek. Et ping, der virker, mens HTTPS fejler, peger på et transportlagsfilter og ikke på netværket, og en blokering, der kun kommer tilbage efter genstarten, peger på en ejer, du ikke har fundet endnu.

Gem beviserne: den eksporterede BFE-nøgle eller iptables -S-outputtet, der blev fanget før ændringen. Før du kalder det løst, skal du bekræfte det lag, du fjernede objektet fra, den ejer, der kunne geninstallere det, tilstanden efter én ren genstart, og at almindelig browsing virker uden nogen kørende VPN-proces. Manualsiden iptables(8) har den præcise slette- og politiksyntaks, hvis du scriptar oprydningen.