Overleeft een VPN-killswitch een herstart? Zo verifieert u het

Herstarten is de meest gebruikte manier waarop mensen een killswitch testen, en het is de test die het vaakst liegt. Het selectievakje in de client is een voorkeur; wat telt is of iets een blokkade afdwingt tussen het moment waarop de netwerkstack opkomt en het moment waarop de tunnel daadwerkelijk is opgezet. Op Windows is dat iets meestal een filter in het Windows Filtering Platform, op Linux een regelset die door een unit wordt geladen, op macOS een pf-anker, op Android de eigen vlaggen van het systeem voor altijd-aan en vergrendeling. Deze regelingen gedragen zich heel verschillend tijdens een herstart, en alleen die op platformniveau staan op hun plaats voordat iemand kan aanmelden.

Een herstart stelt drie afzonderlijke vragen

Splits de vraag. Ten eerste, bestaat het beleid op schijf in een vorm die iets bij het opstarten leest? Ten tweede, draait die lezer voordat er verkeer naar buiten kan? Ten derde, dekt het beleid het verkeer dat u belangrijk vindt, dat wil zeggen elk proces, beide adresfamilies en DNS. Een ja op de eerste en een nee op de tweede leveren precies de fout op die mensen melden als een killswitch die een herstart niet overleeft: verkeer ontsnapt bij het opstarten een paar seconden, en niemand merkt het tot iemand gaat kijken.

Houd de lagen gescheiden. Een opgeslagen firewallregelset, een dienst die bij het opstarten begint en een clientvoorkeur zijn drie verschillende objecten met drie verschillende levensduren. De voorkeur overleeft herstarts omdat het een waarde in een configuratiebestand is. De regels zijn het enige dat pakketten blokkeert, en ze verdwijnen samen met de kernel die ze vasthield.

Vind het object dat de blokkade herstelt

Op Linux leven netfilterregels in de kernel. Niets schrijft ze bij het opstarten terug, tenzij u dat hebt geregeld: iptables-save plus netfilter-persistent, nftables.service laadt /etc/nftables.conf, of een systemd-unit die uw eigen script uitvoert. Controleer wat is ingeschakeld in plaats van wat u zich herinnert te hebben geconfigureerd.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

Een lege regelset een paar seconden na het opstarten is het antwoord op de vraag in de titel. Vraag op Windows aan de clientdienst hoe die start en dump vervolgens de status van het platformfilter terwijl de tunnel neerligt.

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

Het tweede commando schrijft wfpstate.xml naar de huidige map. Zoek naar filters met een blokkeeractie die al bestaan voordat de client verbinding maakt. Base Filtering Engine start vroeg bij het opstarten en herstelt filters die met de persistente vlag zijn toegevoegd, waardoor sommige killswitches verkeer blokkeren voordat er enig clientvenster bestaat en andere niet. Op macOS meldt sudo pfctl -s info of pf is ingeschakeld, toont sudo pfctl -s rules wat er is geladen, en VPN-clients koppelen hun regels meestal aan een anker in plaats van aan de hoofdregelset. Een regel die utun3 noemt kan na de volgende herstart naar een andere interface wijzen, omdat dat nummer tijdens runtime wordt toegekend.

Let op de kloof tussen netwerk omhoog en tunnel omhoog

Het gevaarlijke interval is niet de hele herstart, het is de kloof. De interface krijgt op het ene moment een lease en een standaardroute, de VPN-dienst start op een ander, en de tunnel authenticeert nog later, soms pas nadat een gebruiker zich heeft aangemeld en een referentieagent heeft gedraaid. Wordt de blokkade als laatste toegepast, dan verlaat alles in de kloof het toestel onversleuteld.

Lees op systemd-hosts de volgorde in plaats van haar te raden. Voer systemctl cat uit op de VPN- en firewall-units en zoek naar After= of Before= ten opzichte van network-pre.target en network-online.target. Een firewall-unit die na network-online.target is geordend verliest van de interface; degene die door network-pre.target wordt vereist en ervoor is geordend, wint. Op Windows zijn de equivalente vragen het starttype van de dienst en de afhankelijkheden ervan, omdat een dienst op Manual geen opstartproces kan blokkeren. Als uw eis verkeer vóór aanmelding omvat, voldoet alleen een regeling op apparaatniveau: een Always On VPN-apparaattunnel authenticeert met een machinacertificaat en verbindt voordat de gebruiker zich aanmeldt, en Microsoft documenteert de configuratie van de apparaattunnel apart van de gebruikerstunnel. Android neemt de andere route, dwingt altijd-aan-VPN af en blokkeert verbindingen zonder die VPN vanuit het systeem en niet vanuit een applicatieproces.

Voer de test uit en vergelijk daarna twee tijdlijnen

Herstart met een bestemming die niets kost als ze lekt, en leg de toestand tijdens de kloof vast in plaats van erna. De schoonste methode is een opstartprobe: een oneshot-unit of een geplande taak die zo vroeg start als het platform toestaat, de standaardroute en de firewallstatus vastlegt, één verzoek met een korte time-out probeert en een regel aan een lokaal bestand toevoegt. Vergelijk die registratie met de starttijd van de VPN-dienst uit journalctl -b -u of het systeemlogboek.

Voer daarna de gewone test uit: tunnel omhoog, verbreek de verbinding, kijk of direct verkeer wordt geblokkeerd, herstel. De tweede halen en de eerste falen is het normale resultaat, en het betekent dat de handhaving aan de clientkant zit, toegepast wanneer de client verbinding maakt en niet bij het opstarten. Op de laatste machine die ik heb geaudit, kwam de blokkade van een dispatcherscript van NetworkManager: aanwezig en correct en nutteloos voor de seconden voordat de interface opkwam. Schrijf beide resultaten op, want een herstart overleven betekent pas iets als u zegt welke laag heeft overleefd en vanaf welk moment.

Dicht de kloof zonder uw weg terug af te snijden

Ontbreekt de blokkade bij het opstarten, verplaats de handhaving dan een laag naar beneden in plaats van een tweede clientregel toe te voegen. Sla de regelset op en laad die uit een unit die is geordend voordat het netwerk bruikbaar is, en zorg dat die unit geen DNS-opzoeking of netwerkmount nodig heeft die zij hoort te beschermen. Bereik is net zo belangrijk als timing: regels die op een gebruikers-ID of een cgroup passen, laten elke systeemdaemon buiten de blokkade, en een regelset die alleen IPv4 afhandelt, laat IPv6 en DNS bereikbaar.

Laat uzelf een weg terug. Een machine die bij het opstarten alles blokkeert en daarna niet kan authenticeren heeft helemaal geen netwerk, en de oplossing is niet de blokkade wissen maar de referentie of de volgorde repareren. Houd een gedocumenteerde procedure voor de lokale console aan en een smalle, bewuste uitzondering voor wat de tunnel echt nodig heeft, zoals het serveradres en de resolver die wordt gebruikt voordat de tunnel bestaat.

Bevestig vier dingen in volgorde voordat u de opzet vertrouwt. Het beleid is opgeslagen op een plek die het opstarten leest. Die lezer draait voordat de interface bruikbaar is. De blokkade dekt beide adresfamilies en DNS. De VPN kan nog authenticeren terwijl de blokkade actief is. Als alle vier gelden, verandert een herstart niets.