Kill-switch blokkeert nog steeds verkeer nadat de VPN is verbroken

De tunnel is weg, het netwerkpictogram ziet er normaal uit en niets laadt. Je hebt de VPN verbroken, verwijderd of opnieuw opgestart, en de blokkade die je tijdens een onderbreking moest beschermen staat er nog. Het clientvenster kan het niet verklaren, want de client is niet wat je blokkeert: de beslissing is in jouw naam in de kernel geschreven, en er is niets achtergelaten om die te verwijderen. Op Windows staat die status in het Windows Filtering Platform; op Linux is het een regelset in iptables of nftables, vaak met een momentopname die bij het opstarten opnieuw wordt toegepast. Wat volgt is de volgorde die ik gebruik: lees de status, verwijder het smalste object dat de fout verklaart en zoek daarna wat het steeds terugzet.

Een kill-switch is kernelstatus, geen instelling

Desktopclients blokkeren door filters toe te voegen die verkeer buiten de tunnel weigeren. Op Windows zijn dat WFP-filters op de connect-redirect- en transportlagen, en sommige zijn persistent: ze worden vastgelegd in de beleidsopslag van de Base Filtering Engine en hersteld wanneer de machine opstart, voordat enige VPN-software draait. Clients verschillen in wanneer ze opruimen. Sommige verwijderen filters bij verbreken, sommige alleen bij een nette afsluiting, en sommige alleen als eerst de kill-switch wordt uitgezet. Verwijder de software terwijl de blokkade actief is, of beëindig het proces, en de filters blijven.

Het Linux-equivalent is een drop- of reject-regel in het uitgaande pad, soms een forwarding-regel, soms een gewijzigd ketenbeleid. Die regels leven langer dan het proces dat ze toevoegde omdat ze kernelstatus zijn: beëindig de client, laat hem crashen of snijd de stroom af, en de kernel blijft pakketten laten vallen zonder dat er iets over is om dat ongedaan te maken. Een persistentiepakket voegt een tweede laag van duurzaamheid toe door de huidige regelset vast te leggen en bij het opstarten te herstellen, zodat de volgende start begint met de blokkade al geïnstalleerd.

Lees de WFP-status voordat je iets verwijdert

Windows wordt geleverd met het gereedschap dat je nodig hebt. Start een verhoogde prompt en dump de platformstatus; de dump komt als wfpstate.xml in de werkmap terecht.

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

Zoek in de XML naar de naam van de vertrokken leverancier, naar een Block-actie en naar de laag. Filters op connect-redirect en transport zijn degenen die gewoon verkeer breken; een filter op een receive-accept-laag is meestal niet je oorzaak. Als de Base Filtering Engine helemaal niet draait, zoek dan elders, want niets anders kan die filters afdwingen.

Controleer ook de gewone firewallweergave, want de meeste mensen bekijken er maar één van de twee:

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

Wanneer de ingebouwde profielen aan staan en geen regel overeenkomt met het falende verkeer, komt de blokkade van een derde partij en niet van Windows Firewall. Dat onderscheid bepaalt welk gereedschap je voor de reparatie gebruikt.

Lees Linux-regels in de syntaxis waarmee je gaat verwijderen

iptables -S print regels in dezelfde vorm als waarin ze zijn toegevoegd, waardoor de uitvoer direct hergebruikt kan worden voor een verwijdering. iptables -L -v -n voegt pakkettellers toe, en die tellers vertellen je of een regel echt overeenkomt met je mislukte verzoeken of alleen maar in de keten zit.

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

Lees de ketenbeleidsregels, niet alleen de regels: -P OUTPUT DROP blokkeert verkeer zelfs als geen regel overeenkomt. Controleer IPv6 apart, want een client die beide families installeert, kan de IPv6-blokkade laten staan nadat de IPv4-regels weg zijn, en het symptoom hangt dan af van welke familie een applicatie verkiest. Waar nftables wordt gebruikt, voer ook nft list ruleset uit; de twee gereedschappen bestaan naast elkaar via een compatibiliteitslaag, en één lijst toont niet noodzakelijk elke regel die een pakket kan laten vallen.

Verwijder het smalste object dat de fout verklaart

Op Windows is de eerste stap nog steeds het verwijderingspad van de leverancier zelf: voer het installatieprogramma opnieuw uit en gebruik repair of uninstall, of voer het opruimgereedschap uit als de leverancier dat publiceert. Achtergebleven services en geplande taken komen vaak voor, en een taak die de client bij aanmelding start, installeert de filters bij de volgende start opnieuw. Een verwijdering die faalt bij het lezen van de registersleutel van de client betekent meestal dat een service of taak die nog vasthoudt, niet dat het register beschadigd is.

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

Persistente filters zijn het laatste redmiddel. Ze staan onder HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter, één waarde per filter met een GUID als sleutel. Exporteer eerst de sleutel, noteer de GUID's die je verwijdert, verwijder alleen de waarden die bij de vertrokken client horen, en start daarna opnieuw zodat de engine zijn status opbouwt. Verwijder niet de hele sleutel en schakel de Base Filtering Engine niet uit: Windows Firewall en Defender zijn ervan afhankelijk, en je zou de ene storing met een ergere ruilen.

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

Neem op Linux de regel die iptables -S afdrukt en vervang -A door -D. De ene regel verwijderen die je hebt geïdentificeerd is beter dan een keten leegmaken, omdat je eigen beleid intact blijft.

sudo iptables -D OUTPUT -p udp -j REJECT

Als de drop in een door de gebruiker gedefinieerde keten zit, verwijder dan eerst de sprong naar die keten en verwijder de keten daarna met -X. Een ketenbeleid op ACCEPT zetten terwijl drop-regels nog aanwezig zijn, helpt alleen pakketten die de beleidsbeslissing überhaupt bereiken. Elke tabel leegmaken is een laatste redmiddel: het verwijdert ook regels die je om andere redenen hebt toegevoegd, en met ufw ingeschakeld laat het de service geloven dat hij ketens bezit die niet meer bestaan.

Zoek de eigenaar die het terugzet

Zoek na de onmiddellijke reparatie naar wat de status zou herstellen. Controleer op Linux of een persistentie-eenheid is ingeschakeld, of de client een instelling heeft om de firewall bij aanmelding te herstellen, en of er een opgeslagen regelbestand onder /etc staat. Controleer op Windows opnieuw de opstartitems, services en geplande taken, start daarna opnieuw en lees de status met dezelfde opdrachten als voorheen.

Als de blokkade terugkomt, was het verwijderen niet de oplossing; de eigenaar was het. Noteer welke client of service hem installeert en schakel de functie daar uit, in plaats van er na elke onderbreking op firewallniveau tegen te vechten.

Verifieer met echt verkeer, niet met één ping

Test een naamopzoeking, een TCP-verbinding en een nieuwe browsersessie, start daarna opnieuw en herhaal dezelfde drie controles. Een ping die werkt terwijl HTTPS faalt, wijst op een filter op de transportlaag en niet op het netwerk, en een blokkade die pas na de herstart terugkomt, wijst op een eigenaar die je nog niet hebt gevonden.

Bewaar het bewijs: de geëxporteerde BFE-sleutel, of de iptables -S-uitvoer die vóór de wijziging is vastgelegd. Voordat je het opgelost noemt, bevestig je de laag waaruit je het object hebt verwijderd, de eigenaar die het opnieuw kan installeren, de status na één schone herstart, en dat gewoon browsen werkt zonder draaiend VPN-proces. De man-pagina van iptables(8) heeft de exacte syntaxis voor verwijderen en beleid als je de opruiming script.