Överlever en VPN-nödstopp en omstart? Så verifierar du det

Att starta om är det vanligaste sättet folk testar en nödstopp, och det är testet som oftast ljuger. Kryssrutan i klienten är en inställning; det som spelar roll är om något upprätthåller en blockering mellan det ögonblick då nätverksstacken reser sig och det ögonblick då tunneln faktiskt är upprättad. På Windows är det något vanligen ett filter i Windows Filtering Platform, på Linux en regeluppsättning som laddas av en enhet, på macOS ett pf-ankare, på Android systemets egna flaggor för alltid-på och låsning. Dessa arrangemang beter sig mycket olika genom en omstart, och bara de på plattformsnivå finns på plats innan någon kan logga in.

En omstart ställer tre separata frågor

Dela upp frågan. För det första, finns policyn på disken i en form som något läser vid uppstart? För det andra, körs den läsaren innan någon trafik kan lämna maskinen? För det tredje, täcker policyn den trafik du bryr dig om, det vill säga varje process, båda adressfamiljerna och DNS. Ett ja på den första och ett nej på den andra ger precis det fel folk rapporterar som en nödstopp som inte överlever en omstart: trafiken slipper ut i några sekunder vid uppstart, och ingen märker det förrän någon går för att titta.

Håll lagren åtskilda. En sparad brandväggsregeluppsättning, en tjänst som startar vid uppstart och en klientinställning är tre olika objekt med tre olika livslängder. Inställningen överlever omstarter eftersom den är ett värde i en konfigurationsfil. Reglerna är det enda som blockerar paket, och de försvinner tillsammans med den kärna som höll dem.

Hitta objektet som återställer blockeringen

På Linux lever netfilterregler i kärnan. Ingenting skriver tillbaka dem vid uppstart om du inte har ordnat det: iptables-save plus netfilter-persistent, nftables.service laddar /etc/nftables.conf, eller en systemd-enhet som kör ditt eget skript. Kontrollera vad som är aktiverat i stället för vad du minns att du konfigurerade.

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

En tom regeluppsättning några sekunder efter uppstart är svaret på frågan i rubriken. På Windows fråga klienttjänsten hur den startar och dumpa sedan plattformsfiltrets tillstånd medan tunneln är nere.

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

Det andra kommandot skriver wfpstate.xml till aktuell katalog. Leta efter filter med en blockeringsåtgärd som redan finns innan klienten ansluter. Base Filtering Engine startar tidigt vid uppstart och återställer filter som lades till med den beständiga flaggan, vilket är varför vissa nödstopp blockerar trafik innan något klientfönster finns och andra inte. På macOS rapporterar sudo pfctl -s info om pf är aktiverat, visar sudo pfctl -s rules vad som är laddat, och VPN-klienter kopplar vanligtvis sina regler till ett ankare i stället för huvudregeluppsättningen. En regel som namnger utun3 kan efter nästa uppstart peka på ett annat gränssnitt, eftersom det numret tilldelas vid körning.

Håll koll på gapet mellan nätverk uppe och tunnel uppe

Det farliga intervallet är inte hela omstarten, det är gapet. Gränssnittet får en lease och en standardrutt vid en tidpunkt, VPN-tjänsten startar vid en annan, och tunneln autentiserar ännu senare, ibland först efter att en användare loggat in och en autentiseringsagent har kört. Om blockeringen tillämpas sist går allt i gapet ut okrypterat.

På systemd-värdar bör du läsa ordningen i stället för att gissa den. Kör systemctl cat på VPN- och brandväggsenheterna och leta efter After= eller Before= gentemot network-pre.target och network-online.target. En brandväggsenhet som är ordnad efter network-online.target förlorar mot gränssnittet; den som krävs av och är ordnad före network-pre.target vinner. På Windows är motsvarande frågor tjänstens starttyp och dess beroenden, eftersom en tjänst inställd på Manual inte kan blockera en uppstartsprocess. Om ditt krav omfattar trafik före inloggning uppfylls det bara av ett arrangemang på enhetsnivå: en Always On VPN-enhetstunnel autentiserar med ett maskincertifikat och ansluter innan användaren loggar in, och Microsoft dokumenterar konfigurationen av enhetstunneln separat från användartunneln. Android tar den andra vägen, upprätthåller alltid-på-VPN och blockerar anslutningar utan det från systemet och inte från en applikationsprocess.

Kör testet och jämför sedan två tidslinjer

Starta om med ett mål som inte kostar något om det läcker, och fånga tillståndet under gapet i stället för efteråt. Den renaste metoden är en uppstartsprob: en oneshot-enhet eller en schemalagd uppgift som startar så tidigt plattformen tillåter, registrerar standardrutten och brandväggens tillstånd, försöker med en begäran med kort tidsgräns och lägger till en rad i en lokal fil. Jämför den registreringen med VPN-tjänstens starttid från journalctl -b -u eller systemloggen.

Kör sedan det vanliga testet: tunnel uppe, bryt anslutningen, se om direkt trafik blockeras, återställ. Att klara det andra och misslyckas med det första är det normala resultatet, och det betyder att upprätthållandet sker på klientsidan, tillämpas när klienten ansluter och inte vid uppstart. På den senaste maskinen jag granskade kom blockeringen från ett NetworkManager-dispatchskript: närvarande och korrekt och oanvändbart för de sekunder innan gränssnittet kom upp. Skriv ner båda resultaten, för att överleva en omstart betyder något först när du säger vilket lager som överlevde och från vilket ögonblick.

Stäng gapet utan att kapa vägen tillbaka

Om blockeringen saknas vid uppstart flyttar du upprätthållandet ett lager ner i stället för att lägga till en andra klientregel. Spara regeluppsättningen och ladda den från en enhet som är ordnad innan nätverket är användbart, och se till att den enheten inte behöver en DNS-fråga eller en nätverksmontering som den ska skydda. Omfattningen spelar lika stor roll som tidpunkten: regler som matchar ett användar-ID eller en cgroup lämnar varje systemdemon utanför blockeringen, och en regeluppsättning som bara hanterar IPv4 lämnar IPv6 och DNS nåbara.

Lämna en väg tillbaka åt dig själv. En maskin som blockerar allt vid uppstart och sedan inte kan autentisera har inget nätverk alls, och rättelsen är inte att ta bort blockeringen utan att reparera autentiseringsuppgiften eller ordningen. Håll en dokumenterad procedur för den lokala konsolen och ett smalt, medvetet undantag för det tunneln verkligen behöver, som serveradressen och den resolver som används innan tunneln finns.

Innan du litar på arrangemanget, bekräfta fyra saker i ordning. Policyn lagras där uppstarten läser. Den läsaren körs innan gränssnittet är användbart. Blockeringen täcker båda adressfamiljerna och DNS. VPN kan fortfarande autentisera medan blockeringen är aktiv. När alla fyra gäller ändrar en omstart ingenting.