Overlever ein VPN-naudbrytar ein omstart? Slik verifiserer du det

Omstart er den vanlegaste måten folk testar ein naudbrytar på, og det er testen som oftast lyg. Avkryssingsboksen i klienten er ei innstilling; det som tel er om noko handhevar ei blokkering mellom augneblinken nettverksstakken reiser seg og augneblinken tunnelen faktisk er etablert. På Windows er det noko vanlegvis eit filter i Windows Filtering Platform, på Linux eit regelsett lasta av ei eining, på macOS eit pf-anker, på Android systemet sine eigne flagg for alltid-på og låsing. Desse ordningane oppfører seg svært ulikt gjennom ein omstart, og berre dei på plattformnivå er på plass før nokon kan logge inn.

Ein omstart stiller tre separate spørsmål

Del spørsmålet. For det første, finst policyen på disken i ei form som noko les ved oppstart? For det andre, køyrer den lesaren før noko trafikk kan forlate maskinen? For det tredje, dekkjer policyen trafikken du bryr deg om, altså kvar prosess, begge adressefamiliane og DNS. Eit ja på det første og eit nei på det andre gjev nøyaktig den feilen folk rapporterer som ein naudbrytar som ikkje overlever omstart: trafikken slepp ut i nokre sekund ved oppstart, og ingen merkar det før nokon går for å sjå etter.

Hald laga åtskilde. Eit lagra brannmurregelsett, ein teneste som startar ved oppstart og ei klientinnstilling er tre ulike objekt med tre ulike levetider. Innstillinga overlever omstartar fordi ho er ein verdi i ei konfigurasjonsfil. Reglane er det einaste som blokkerer pakkar, og dei forsvinn saman med kjernen som heldt dei.

Finn objektet som gjenopprettar blokkeringa

På Linux lever netfilter-reglar i kjernen. Ingenting skriv dei tilbake ved oppstart med mindre du har ordna det: iptables-save pluss netfilter-persistent, nftables.service lastar /etc/nftables.conf, eller ei systemd-eining som køyrer ditt eige skript. Sjekk kva som er aktivert i staden for kva du hugsar at du konfigurerte.

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

Eit tomt regelsett nokre sekund etter oppstart er svaret på spørsmålet i tittelen. På Windows spør klienttenesta korleis ho startar, og dump deretter tilstanden til plattformfiltret medan tunnelen er nede.

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

Den andre kommandoen skriv wfpstate.xml til gjeldande katalog. Sjå etter filter med ei blokkeringshandling som allereie finst før klienten koplar til. Base Filtering Engine startar tidleg ved oppstart og gjenopprettar filter som vart lagde til med det varige flagget, og difor blokkerer nokre naudbrytarar trafikk før det finst noko klientvindauge, medan andre ikkje gjer det. På macOS rapporterer sudo pfctl -s info om pf er aktivert, viser sudo pfctl -s rules kva som er lasta, og VPN-klientar knyter vanlegvis reglane sine til eit anker i staden for hovudregelsettet. Ein regel som namngjev utun3 kan etter neste oppstart peike på eit anna grensesnitt, fordi det nummeret vert tildelt under køyring.

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

Det farlege intervallet er ikkje heile omstarten, det er gapet. Grensesnittet får ein lease og ei standardrute på eitt tidspunkt, VPN-tenesta startar på eit anna, og tunnelen autentiserer seinare ennå, nokre gonger først etter at ein brukar har logga inn og ein legitimasjonsagent har køyrt. Vert blokkeringa brukt sist, går alt i gapet ut ukryptert.

På systemd-vertar bør du lese rekkjefølgja i staden for å gjette ho. Køyr systemctl cat på VPN- og brannmureiningane og sjå etter After= eller Before= mot network-pre.target og network-online.target. Ei brannmureining som er ordna etter network-online.target tapar mot grensesnittet; den som vert kravd av og er ordna før network-pre.target vinn. På Windows er dei tilsvarande spørsmåla starttypen til tenesta og avhengnadene hennar, fordi ei teneste sett til Manual ikkje kan blokkere ein oppstartsprosess. Viss kravet ditt omfattar trafikk før innlogging, er det berre ei ordning på einingsnivå som oppfyller det: ein Always On VPN-einingstunnel autentiserer med eit maskinsertifikat og koplar til før brukaren loggar inn, og Microsoft dokumenterer konfigurasjonen av einingstunnelen separat frå brukartunnelen. Android tek den andre vegen, handhevar alltid-på VPN og blokkerer tilkoplingar utan han frå systemet og ikkje frå ein applikasjonsprosess.

Køyr testen, og samanlikn deretter to tidslinjer

Start på nytt med eit mål som ikkje kostar noko om det lekk, og ta opp tilstanden i gapet i staden for etterpå. Den reinaste metoden er ein oppstartsprobe: ei oneshot-eining eller ei planlagd oppgåve som startar så tidleg plattformen tillèt, registrerer standardruta og brannmurtilstanden, freistar éin førespurnad med kort tidsavbrot og legg til ei linje i ei lokal fil. Samanlikn den registreringa med starttida til VPN-tenesta frå journalctl -b -u eller systemloggen.

Køyr deretter den vanlege testen: tunnel oppe, bryt tilkoplinga, sjå om direkte trafikk vert blokkert, gjenopprett. Å bestå den andre og feile den første er det normale resultatet, og det betyr at handhevinga er på klientsida, brukt når klienten koplar til og ikkje ved oppstart. På den siste maskinen eg reviderte, kom blokkeringa frå eit NetworkManager-utsendarskript: til stades og riktig og ubrukeleg for sekunda før grensesnittet kom opp. Skriv ned begge resultata, fordi å overleve ein omstart berre betyr noko når du seier kva lag som overlevde og frå kva augneblink.

Lukk gapet utan å kutte vegen tilbake

Viss blokkeringa manglar ved oppstart, flytt handhevinga eitt lag ned i staden for å leggje til ein andre klientregel. Lagre regelsettet og last det frå ei eining som er ordna før nettverket er brukbart, og sørg for at den eininga ikkje treng eit DNS-oppslag eller ei nettverksmontering ho skal verne. Omfang betyr like mykje som tidspunkt: reglar som samsvarar med ein brukar-ID eller ein cgroup lèt kvar systemdemon vere utanfor blokkeringa, og eit regelsett som berre handterer IPv4 lèt IPv6 og DNS vere tilgjengelege.

Lat deg sjølv behalde ein veg tilbake. Ei maskin som blokkerer alt ved oppstart og deretter ikkje kan autentisere, har ikkje noko nettverk i det heile, og rettinga er ikkje å slette blokkeringa, men å reparere legitimasjonen eller rekkjefølgja. Hald ein dokumentert prosedyre for den lokale konsollen og eit smalt, medvite unntak for det tunnelen verkeleg treng, slik som serveradressa og resolveryen som vert brukt før tunnelen finst.

Før du stolar på ordninga, stadfest fire ting i rekkjefølgje. Policyen er lagra ein stad oppstarten les. Den lesaren køyrer før grensesnittet er brukbart. Blokkeringa dekkjer begge adressefamiliane og DNS. VPN kan framleis autentisere medan blokkeringa er aktiv. Når alle fire held, endrar ein omstart ingenting.