Overlever en VPN-nødafbryder en genstart? Sådan kontrollerer du det

Genstart er den mest almindelige måde, folk tester en nødafbryder på, og det er den test, der oftest lyver. Afkrydsningsfeltet i klienten er en indstilling; det afgørende er, om noget håndhæver en blokering mellem det øjeblik, netværksstakken rejser sig, og det øjeblik, tunnelen faktisk er etableret. På Windows er det noget normalt et filter i Windows Filtering Platform, på Linux et regelsæt indlæst af en unit, på macOS et pf-anker, på Android systemets egne flag for altid-til og låsning. Disse ordninger opfører sig meget forskelligt gennem en genstart, og kun dem på platformsniveau er på plads, før nogen kan logge ind.

En genstart stiller tre separate spørgsmål

Del spørgsmålet. For det første, findes politikken på disken i en form, som noget læser ved opstart? For det andet, kører den læser, før nogen trafik kan forlade maskinen? For det tredje, dækker politikken den trafik, du bekymrer dig om, altså hver proces, begge adressefamilier og DNS. Et ja til det første og et nej til det andet giver præcis den fejl, folk rapporterer som en nødafbryder, der ikke overlever en genstart: trafik slipper ud i et par sekunder ved opstart, og ingen bemærker det, før nogen går på jagt.

Hold lagene adskilt. Et gemt firewall-regelsæt, en tjeneste, der starter ved opstart, og en klientindstilling er tre forskellige objekter med tre forskellige liv. Indstillingen overlever genstarter, fordi den er en værdi i en konfigurationsfil. Reglerne er det eneste, der blokerer pakker, og de forsvinder sammen med den kerne, der holdt dem.

Find det objekt, der gendanner blokeringen

På Linux lever netfilter-regler i kernen. Intet skriver dem tilbage ved opstart, medmindre du har sørget for det: iptables-save plus netfilter-persistent, nftables.service indlæser /etc/nftables.conf, eller en systemd-unit, der kører dit eget script. Kontrollér, hvad der er aktiveret, i stedet for hvad du husker, du konfigurerede.

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

Et tomt regelsæt få sekunder efter opstart er svaret på spørgsmålet i titlen. På Windows skal du spørge klienttjenesten, hvordan den starter, og derefter dumpe platformsfilterets tilstand, mens tunnelen er nede.

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

Den anden kommando skriver wfpstate.xml til den aktuelle mappe. Se efter filtre med en blokeringshandling, der allerede findes, før klienten opretter forbindelse. Base Filtering Engine starter tidligt ved opstart og gendanner filtre, der blev tilføjet med det vedvarende flag, og derfor blokerer nogle nødafbrydere trafik, før noget klientvindue findes, mens andre ikke gør. På macOS sudo pfctl -s info rapporterer, om pf er aktiveret, sudo pfctl -s rules viser, hvad der er indlæst, og VPN-klienter knytter normalt deres regler til et anker i stedet for hovedregelsættet. En regel, der navngiver utun3 kan pege på en anden grænseflade efter næste opstart, fordi det nummer tildeles ved kørsel.

Hold øje med hullet mellem netværk oppe og tunnel oppe

Det farlige interval er ikke hele genstarten, det er hullet. Grænsefladen får en leje og en standardrute på et tidspunkt, VPN-tjenesten starter på et andet, og tunnelen autentificerer senere endnu, nogle gange først efter at en bruger har logget ind, og en legitimationsagent er kørt. Hvis blokeringen anvendes sidst, forlader alt i hullet ukrypteret.

På systemd-værter skal du læse rækkefølgen i stedet for at gætte den. Kør systemctl cat på VPN- og firewall-units og se efter After= eller Before= over for network-pre.target og network-online.target. En firewall-unit, der er ordnet efter network-online.target taber til grænsefladen; den, der er krævet af og ordnet før network-pre.target vinder. På Windows er de tilsvarende spørgsmål tjenestens starttype og dens afhængigheder, fordi en tjeneste sat til Manual ikke kan blokere en opstartsproces. Hvis dit krav omfatter trafik før login, opfyldes det kun af en ordning på enhedsniveau: en Always On VPN-enhedstunnel autentificerer med et maskincertifikat og forbinder, før brugeren logger ind, og Microsoft dokumenterer konfigurationen af enhedstunnelen separat fra brugertunnelen. Android tager den anden vej og håndhæver altid-til VPN og blokerer forbindelser uden den fra systemet i stedet for fra en applikationsproces.

Kør testen, og sammenlign derefter to tidslinjer

Genstart med en destination, der ikke koster noget, hvis den lækker, og optag tilstanden i hullet i stedet for efter det. Den reneste metode er en opstartsprobe: en oneshot-unit eller en planlagt opgave, der starter så tidligt, platformen tillader, registrerer standardruten og firewall-tilstanden, forsøger én anmodning med en kort timeout og tilføjer en linje til en lokal fil. Sammenlign den registrering med VPN-tjenestens starttid fra journalctl -b -u eller Systemloggen.

Kør derefter den sædvanlige test: tunnel oppe, afbryd forbindelsen, se, om direkte trafik blokeres, gendan. At bestå den anden og fejle den første er det normale resultat, og det betyder, at håndhævelsen er på klientsiden, anvendt når klienten forbinder i stedet for ved opstart. På den sidste maskine, jeg reviderede, kom blokeringen fra et NetworkManager-dispatcherscript: til stede og korrekt og ubrugeligt i de sekunder, før grænsefladen kom op. Skriv begge resultater ned, fordi at overleve en genstart kun betyder noget, når du siger hvilket lag, der overlevede, og fra hvilket øjeblik.

Luk hullet uden at afskære vejen tilbage

Hvis blokeringen mangler ved opstart, skal du flytte håndhævelsen et lag ned i stedet for at tilføje en anden klientregel. Gem regelsættet, og indlæs det fra en unit, der er ordnet, før netværket er brugbart, og sørg for, at den unit ikke har brug for et DNS-opslag eller et netværksmonter, som den skal beskytte. Omfang betyder lige så meget som timing: regler, der matcher et bruger-ID eller en cgroup, lader hver systemdæmon være uden for blokeringen, og et regelsæt, der kun håndterer IPv4, lader IPv6 og DNS være tilgængelige.

Efterlad en vej tilbage til dig selv. En maskine, der blokerer alt ved opstart og derefter ikke kan autentificere, har slet ikke noget netværk, og løsningen er ikke at slette blokeringen, men at reparere legitimationsoplysningerne eller rækkefølgen. Hold en dokumenteret procedure for den lokale konsol og en snæver, bevidst undtagelse for det, tunnelen virkelig har brug for, såsom serveradressen og den resolver, der bruges, før tunnelen findes.

Før du stoler på opsætningen, skal du bekræfte fire ting i rækkefølge. Politikken er gemt et sted, opstarten læser. Den læser kører, før grænsefladen er brugbar. Blokeringen dækker begge adressefamilier og DNS. VPN kan stadig autentificere, mens blokeringen er aktiv. Når alle fire holder, ændrer en genstart intet.