Always-on VPN eller kill switch: hva slags slo du egentlig på?

Always-on og kill switch står to linjer fra hverandre på samme innstillingsskjerm, så folk leser dem som to navn på én funksjon. Det er de ikke. Always-on er en policy for gjenoppkobling: start tunnelen ved oppstart, få den tilbake etter en krasj eller nettverksendring, og fortsett å prøve mens den feiler. Kill switch er en trafikkpolicy: den navngir pakkene som fortsatt kan forlate maskinen mens tunnelen er nede. Du kan slå på den første uten den andre, og på de fleste plattformer slipper standardresultatet fortsatt trafikk ut i mellomtiden.

Kontroll 1: er blokken en egen bryter?

På Android 10 og nyere åpner en lagret VPN-profil to uavhengige brytere bak tannhjulikonet: Always-on VPN og Block connections without VPN. Bare den andre er kill switch. Med bare always-on kommer tunnelen riktignok tilbake etter et brudd, og enhver app midt i en forespørsel kan nå nettet via Wi-Fi eller mobildata til den gjør det.

Administrerte enheter beholder samme deling i policy-API-et. setAlwaysOnVpnPackage() tar pakkenavnet og et lockdownEnabled-flagg; en administrator som setter pakken og lar flagget være false har bygget en varig tunnel, ikke en lukket enhet. Ordlyden i konsollen gjør sjelden den forskjellen synlig.

Les tilstanden fra enheten, ikke fra konsollen: adb shell settings get global always_on_vpn_app og adb shell settings get global always_on_vpn_lockdown. Hvis den første returnerer null, er ingen pakke håndhevet på plattformnivå; hvis den andre returnerer 0, blokkerer ikke plattformen noe. Android VPN-veiledningen beskriver disse som separate egenskaper, ikke én modus.

Kontroll 2: hvilket lag eier blokken?

Etikettene bor i klienten og blokkene vanligvis i brannmuren, og derfor betyr samme ord forskjellige ting på hver plattform. Radene nedenfor er de som er verdt å bekrefte før du stoler på noen av dem.

Windows er det klareste eksempelet på en etikett som ikke blokkerer. Der beskriver Always On tunnelens varighet: en enhetstunnel for maskinautentisering og en brukertunnel for den påloggede kontoen, satt opp via profil-XML eller Add-VpnConnection. Ingenting i den profilen stopper en utgående pakke når tunnelen mangler, og utgående filtrering er ikke på som standard, så en bærbar PC på Wi-Fi fortsetter å virke mens VPN-en er nede.

WireGuard deler seg på samme måte, men per klient. WireGuard for Windows har et Block untunneled traffic-valg per tunnel som installerer filterregler; Linux-verktøyene har ingen tilsvarende bryter. wg-quick legger til en rute for hver AllowedIPs-oppføring pluss en fwmark-regel, og wg-quick down fjerner begge, så den fysiske standardruten tar over igjen uten at en eneste pakke går tapt.

På Apple-plattformer kommer always-on som en funksjon i administrasjonsprofilen for overvåkede enheter og uttrykkes som on-demand-regler i stedet for en avkrysningsboks. Spørsmålet du må svare på fra nyttelasten er om en mislykket tunnel nekter trafikk eller bare ber om en annen tilkobling. Menytittelen vil ikke fortelle deg det.

Kontroll 3: mål gapet, ikke ikonet

Fire overganger betyr noe, og de feiler ulikt: oppstart før noen logger på, dvale og oppvåkning, bytte fra Wi-Fi til mobildata, og en klientkrasj som etterlater tunnelgrensesnittet halvkonfigurert. En ren gjenoppkobling på én av dem beviser ingenting om de tre andre.

Den billigste testen stopper tunnelen med vilje og prøver så å komme ut. Med tunnelen nede betyr curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com som returnerer 200 at policyen er fail-open; tidsavbrudd eller en avvist tilkobling betyr at noe fortsatt blokkerer. ip route get 1.1.1.1 navngir grensesnittet som ville bære pakken, noe som vanligvis er mer informativt enn ikonet i systemkurven, og systemctl status wg-quick@wg0 viser om grensesnittet ble fjernet rent.

Kjør samme kontroll i et andre vindu mens nettet endrer seg, ikke bare etter at det har stabilisert seg. Intervallet mellom bruddet og det nye forsøket er det som betyr noe, og navneoppslag er den raskeste måten å oppdage at trafikk slapp ut: hvis den lokale resolveren svarer mens tunnelen er nede, er blokken ikke fullstendig.

Kontroll 4: bestem unntakene før du låser

To unntak er strukturelle. Klienten må nå VPN-serveren selv, så et regelsett som slipper alt, hindrer også gjenoppkoblingen som ville gjenopprette beskyttelsen. En captive portal er heller ikke tilgjengelig gjennom en tunnel som ikke er oppe, så en låst enhet på hotell-Wi-Fi trenger en dokumentert måte å åpne portalen på, ikke en improvisert.

En minimal form, endepunktet tillatt og alt annet sluppet:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

Behandle den endepunktlinjen som en variabel, ikke en konstant. Leverandører rullerer adresser, og et utdatert unntak er den vanlige grunnen til at en fungerende kill switch blir en enhet som ikke kan kobles til på nytt. Lokale skrivere, NAS-delinger og utviklingstjenester hører hjemme på samme skrevne liste, ellers blir de oppdaget én støttebillett om gangen.

Kontroll 5: skriv ned hva du faktisk beviste

Hold en tabell med fire kolonner og fyll den ut ved testing: tilstand, forventet atferd, observert atferd, bevis. Radene er overgangene fra kontroll 3 pluss én bevisst feil. En rad du ikke kan fylle med kommandoutdata er en rad du ikke har testet, og en enhet som består gjenoppkoblingsraden men feiler på oppstartsraden er vanlig nok til å være verdt de ekstra ti minuttene.

Før du kaller det ferdig:

• Bekreft at blokkeringsinnstillingen er separat fra gjenoppkoblingsinnstillingen, og les verdien på enheten.
• Vit hvilket lag som håndhever blokken - klientvalg, enhetspolicy eller brannmur - og hvor det laget konfigureres.
• Behold én kontrollkommando som beviser blokken, og kjør den under en overgang, ikke etter.
• Skriv ned unntakslisten, endepunktet inkludert, og noter hvem som oppdaterer den.
• På administrert maskinvare lar du den håndhevede policyen være; å fjerne blokken endrer kravet i stedet for å reparere tunnelen.