Overlever en VPN-nødutkobling en omstart? Slik verifiserer du det

Omstart er den vanligste måten folk tester en nødutkobling på, og det er testen som oftest lyver. Avkrysningsboksen i klienten er en innstilling; det som betyr noe er om noe håndhever en blokkering mellom det øyeblikket nettverksstakken reiser seg og det øyeblikket tunnelen faktisk er etablert. På Windows er det noe vanligvis et filter i Windows Filtering Platform, på Linux et regelsett lastet av en enhet, på macOS et pf-anker, på Android systemets egne flagg for alltid-på og låsing. Disse ordningene oppfører seg svært ulikt gjennom en omstart, og bare de på plattformnivå er på plass før noen kan logge inn.

En omstart stiller tre separate spørsmål

Del spørsmålet. For det første, finnes policyen på disken i en form som noe leser ved oppstart? For det andre, kjører den leseren før noen trafikk kan forlate maskinen? For det tredje, dekker policyen trafikken du bryr deg om, altså hver prosess, begge adressefamiliene og DNS. Et ja på det første og et nei på det andre gir nøyaktig den feilen folk rapporterer som en nødutkobling som ikke overlever omstart: trafikken slipper ut i noen sekunder ved oppstart, og ingen merker det før noen går for å se etter.

Hold lagene atskilt. Et lagret brannmurregelsett, en tjeneste som starter ved oppstart og en klientinnstilling er tre forskjellige objekter med tre forskjellige levetider. Innstillingen overlever omstarter fordi den er en verdi i en konfigurasjonsfil. Reglene er det eneste som blokkerer pakker, og de forsvinner sammen med kjernen som holdt dem.

Finn objektet som gjenoppretter blokkeringen

På Linux lever netfilter-regler i kjernen. Ingenting skriver dem tilbake ved oppstart med mindre du har ordnet det: iptables-save pluss netfilter-persistent, nftables.service laster /etc/nftables.conf, eller en systemd-enhet som kjører ditt eget skript. Sjekk hva som er aktivert i stedet for hva du husker at du konfigurerte.

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

Et tomt regelsett noen sekunder etter oppstart er svaret på spørsmålet i tittelen. På Windows spør klienttjenesten hvordan den starter, og dump deretter plattformfilterets tilstand mens tunnelen er nede.

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

Den andre kommandoen skriver wfpstate.xml til gjeldende katalog. Se etter filtre med en blokkeringshandling som allerede finnes før klienten kobler til. Base Filtering Engine starter tidlig ved oppstart og gjenoppretter filtre som ble lagt til med det vedvarende flagget, og derfor blokkerer noen nødutkoblinger trafikk før det finnes noe klientvindu, mens andre ikke gjør det. På macOS sudo pfctl -s info rapporterer om pf er aktivert, sudo pfctl -s rules viser hva som er lastet, og VPN-klienter knytter vanligvis reglene sine til et anker i stedet for hovedregelsettet. En regel som navngir utun3 kan etter neste oppstart peke på et annet grensesnitt, fordi det nummeret tildeles ved kjøring.

Følg med på gapet mellom nettverk oppe og tunnel oppe

Det farlige intervallet er ikke hele omstarten, det er gapet. Grensesnittet får en lease og en standardrute på ett tidspunkt, VPN-tjenesten starter på et annet, og tunnelen autentiserer senere ennå, noen ganger først etter at en bruker har logget inn og en legitimasjonsagent har kjørt. Hvis blokkeringen brukes sist, går alt i gapet ut ukryptert.

På systemd-verter bør du lese rekkefølgen i stedet for å gjette den. Kjør systemctl cat på VPN- og brannmurenhetene og se etter After= eller Before= mot network-pre.target og network-online.target. En brannmurenhet som er ordnet etter network-online.target taper mot grensesnittet; den som kreves av og er ordnet før network-pre.target vinner. På Windows er de tilsvarende spørsmålene tjenestens starttype og dens avhengigheter, fordi en tjeneste satt til Manual ikke kan blokkere en oppstartsprosess. Hvis kravet ditt omfatter trafikk før innlogging, er det bare en ordning på enhetsnivå som oppfyller det: en Always On VPN-enhetstunnel autentiserer med et maskinsertifikat og kobler til før brukeren logger inn, og Microsoft dokumenterer konfigurasjonen av enhetstunnelen separat fra brukertunnelen. Android tar den andre veien, håndhever alltid-på VPN og blokkerer tilkoblinger uten den fra systemet og ikke fra en applikasjonsprosess.

Kjør testen, og sammenlign deretter to tidslinjer

Start på nytt med et mål som ikke koster noe hvis det lekker, og ta opp tilstanden i gapet i stedet for etterpå. Den reneste metoden er en oppstartsprobe: en oneshot-enhet eller en planlagt oppgave som starter så tidlig plattformen tillater, registrerer standardruten og brannmurtilstanden, forsøker én forespørsel med kort tidsavbrudd og legger til en linje i en lokal fil. Sammenlign den registreringen med VPN-tjenestens starttid fra journalctl -b -u eller systemloggen.

Kjør deretter den vanlige testen: tunnel oppe, bryt tilkoblingen, se om direkte trafikk blokkeres, gjenopprett. Å bestå den andre og feile den første er det normale resultatet, og det betyr at håndhevelsen er på klientsiden, brukt når klienten kobler til og ikke ved oppstart. På den siste maskinen jeg reviderte, kom blokkeringen fra et NetworkManager-utsenderskript: til stede og riktig og ubrukelig for sekundene før grensesnittet kom opp. Skriv ned begge resultatene, fordi å overleve en omstart bare betyr noe når du sier hvilket lag som overlevde og fra hvilket øyeblikk.

Lukk gapet uten å kutte veien tilbake

Hvis blokkeringen mangler ved oppstart, flytt håndhevelsen ett lag ned i stedet for å legge til en andre klientregel. Lagre regelsettet og last det fra en enhet som er ordnet før nettverket er brukbart, og sørg for at den enheten ikke trenger et DNS-oppslag eller en nettverksmontering den skal beskytte. Omfang betyr like mye som tidspunkt: regler som samsvarer med en bruker-ID eller en cgroup lar hver systemdemon være utenfor blokkeringen, og et regelsett som bare håndterer IPv4 lar IPv6 og DNS være tilgjengelige.

La deg selv beholde en vei tilbake. En maskin som blokkerer alt ved oppstart og deretter ikke kan autentisere, har ikke noe nettverk i det hele tatt, og rettelsen er ikke å slette blokkeringen, men å reparere legitimasjonen eller rekkefølgen. Hold en dokumentert prosedyre for den lokale konsollen og et smalt, bevisst unntak for det tunnelen virkelig trenger, slik som serveradressen og resolveryen som brukes før tunnelen finnes.

Før du stoler på ordningen, bekreft fire ting i rekkefølge. Policyen er lagret et sted oppstarten leser. Den leseren kjører før grensesnittet er brukbart. Blokkeringen dekker begge adressefamilier og DNS. VPN kan fortsatt autentisere mens blokkeringen er aktiv. Når alle fire holder, endrer en omstart ingenting.