Always-on VPN eller kill switch: kva slo du eigentleg på?

Always-on og kill switch står to linjer frå kvarandre på same innstillingsskjerm, så folk les dei som to namn på éin funksjon. Det er dei ikkje. Always-on er ein politikk for attkopling: start tunnelen ved oppstart, få han tilbake etter eit kræsj eller ei nettverksendring, og hald fram med å prøve medan han feilar. Kill switch er ein trafikkpolitikk: han namngir pakkane som framleis kan forlate maskina medan tunnelen er nede. Du kan slå på den første utan den andre, og på dei fleste plattformer slepp standardresultatet framleis trafikk ut i mellomtida.

Kontroll 1: er blokka ein eigen brytar?

På Android 10 og nyare opnar ein lagra VPN-profil to uavhengige brytarar bak tannhjulikonet: Always-on VPN og Block connections without VPN. Berre den andre er kill switch. Med berre always-on kjem tunnelen riktignok tilbake etter eit brot, og kvar app midt i ein førespurnad kan nå nettet via Wi-Fi eller mobildata til han gjer det.

Styrte einingar held på same delinga i policy-API-et. setAlwaysOnVpnPackage() tek pakkenamnet og eit lockdownEnabled-flagg; ein administrator som set pakken og lèt flagget vere false har bygd ein varig tunnel, ikkje ei lukka eining. Orda i konsollen gjer sjeldan den skilnaden synleg.

Les tilstanden frå eininga, ikkje frå konsollen: adb shell settings get global always_on_vpn_app og adb shell settings get global always_on_vpn_lockdown. Viss den første returnerer null, er ingen pakke handheva på plattformnivå; viss den andre returnerer 0, blokkerer ikkje plattforma noko. Android VPN-rettleiinga skildrar desse som separate eigenskapar, ikkje éin modus.

Kontroll 2: kva lag eig blokka?

Etikettene bur i klienten og blokkene vanlegvis i brannmuren, og difor tyder same ord noko anna på kvar plattform. Radene nedanfor er dei som er verd å stadfeste før du stolar på nokon av dei.

Windows er det klåraste dømet på ei etikett som ikkje blokkerer. Der skildrar Always On varigheita til tunnelen: ein einingstunnel for maskinautentisering og ein brukartunnel for den innlogga kontoen, sett opp via profil-XML eller Add-VpnConnection. Ingenting i den profilen stoppar ein utgåande pakke når tunnelen manglar, og utgåande filtrering er ikkje på som standard, så ein berbar PC på Wi-Fi held fram å verke medan VPN-en er nede.

WireGuard deler seg på same måte, men per klient. WireGuard for Windows har eit Block untunneled traffic-val per tunnel som installerer filterreglar; Linux-verktøya har ingen tilsvarande brytar. wg-quick legg til ei rute for kvar AllowedIPs-oppføring pluss ein fwmark-regel, og wg-quick down fjernar begge, så den fysiske standardruta tek over att utan at ein einaste pakke går tapt.

På Apple-plattformer kjem always-on som ein funksjon i administrasjonsprofilen for overvaka einingar og blir uttrykt som on-demand-reglar i staden for ein avkrysingsboks. Spørsmålet du må svare på frå nyttelasta er om ein mislukka tunnel nektar trafikk eller berre ber om ei anna tilkopling. Menytittelen vil ikkje fortelje deg det.

Kontroll 3: mål gapet, ikkje ikonet

Fire overgangar betyr noko, og dei feilar ulikt: oppstart før nokon loggar på, dvale og oppvakning, byte frå Wi-Fi til mobildata, og eit klientkræsj som lèt tunnelgrensesnittet halvkonfigurert att. Ei rein attkopling på éin av dei beviser ingenting om dei tre andre.

Den billegaste testen stoppar tunnelen med vilje og prøver så å kome ut. Med tunnelen nede betyr curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com som returnerer 200 at politikken er fail-open; tidsavbrot eller ei avvist tilkopling betyr at noko framleis blokkerer. ip route get 1.1.1.1 namngir grensesnittet som ville bera pakken, noko som vanlegvis er meir informativt enn ikonet i systemkurven, og systemctl status wg-quick@wg0 viser om grensesnittet vart fjerna reint.

Køyr same kontrollen i eit andre vindauge medan nettet endrar seg, ikkje berre etter at det har stabilisert seg. Intervallet mellom brotet og det nye forsøket er det som betyr noko, og namneoppslag er den raskaste måten å oppdage at trafikk slapp ut: viss den lokale resolvaren svarar medan tunnelen er nede, er blokka ikkje fullstendig.

Kontroll 4: avgjer unntaka før du låser

To unntak er strukturelle. Klienten må nå VPN-tenaren sjølv, så eit regelsett som slepp alt, hindrar også attkoplinga som ville gjere vernet tilbake. Ein captive portal er heller ikkje tilgjengeleg gjennom ein tunnel som ikkje er oppe, så ei låst eining på hotell-Wi-Fi treng ein dokumentert måte å opne portalen på, ikkje ein improvisert.

Ei minimal form, endepunktet tillate og alt anna slept:

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 endepunktlinja som ein variabel, ikkje ein konstant. Leverandørar rullerer adresser, og eit utdatert unntak er den vanlege grunnen til at ein fungerande kill switch blir ei eining som ikkje kan kople seg til på nytt. Lokale skrivarar, NAS-delingar og utviklingstenester høyrer heime på same skrivne lista, elles blir dei oppdaga éin støttebillett om gongen.

Kontroll 5: skriv ned kva du faktisk prova

Hald ein tabell med fire kolonnar og fyll han ut ved testing: tilstand, forventa åtferd, observert åtferd, bevis. Radene er overgangane frå kontroll 3 pluss éin medviten feil. Ei rad du ikkje kan fylle med kommando-utdata er ei rad du ikkje har testa, og ei eining som står gjennom attkoplingsrada men feilar på oppstartsrada er vanleg nok til å vere verd dei ekstra ti minutta.

Før du kallar det ferdig:

• Stadfest at blokkeringsinnstillinga er skild frå attkoplingsinnstillinga, og les verdien på eininga.
• Vit kva lag som handhevar blokka - klientval, einingapolicy eller brannmur - og kvar det laget blir konfigurert.
• Hald ein kontrollkommando som beviser blokka, og køyr han under ein overgang, ikkje etter.
• Skriv ned unntakslista, endepunktet inkludert, og noter kven som oppdaterer ho.
• På styrt maskinvare lèt du den handheva policyen vere; å fjerne blokka endrar kravet i staden for å reparere tunnelen.