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

Always-on og kill switch ligger to linjer fra hverandre på samme innstillingsside, og derfor leser folk dem som to navn på samme funksjon. Det er de ikke. Always-on er en regel for å koble til på nytt: start tunnelen ved oppstart, få den tilbake etter en krasj eller et nettverksbytte, og fortsett å prøve så lenge den svikter. Kill switch er en regel for trafikken: den peker ut hvilke pakker som fortsatt får forlate maskinen mens tunnelen er nede. Du kan slå på den første uten den andre, og på de fleste plattformer slipper standardoppsettet fortsatt trafikk ut i mellomtiden.

Sjekk 1: er sperren en egen bryter?

Fra Android 10 og oppover åpner en lagret VPN-profil to uavhengige brytere bak tannhjulikonet: Always-on VPN og Block connections without VPN. Det er bare den andre som er kill switch. Med bare always-on kommer tunnelen riktignok tilbake etter et avbrudd, men enhver app som er midt i en forespørsel kan nå nettet over Wi-Fi eller mobildata inntil den gjør det.

Administrerte enheter beholder den samme todelingen i policy-API-et. setAlwaysOnVpnPackage() tar imot pakkenavnet og et lockdownEnabled-flagg; en administrator som setter pakken og lar flagget stå på false har laget en varig tunnel, ikke en lukket enhet. Teksten i konsollen gjør sjelden den forskjellen synlig.

Les tilstanden fra enheten i stedet for konsollen: adb shell settings get global always_on_vpn_app og adb shell settings get global always_on_vpn_lockdown. Returnerer den første null, er ingen pakke påtvunget på plattformnivå; returnerer den andre 0, blokkerer ikke plattformen noe som helst. Android-veiledningen for VPN omtaler dette som atskilte egenskaper og ikke som én modus.

Sjekk 2: hvilket lag eier sperren?

Etikettene sitter i klienten og sperrene som regel i brannmuren, og det er grunnen til at samme ord betyr ulike ting på hver plattform. Radene nedenfor er de det er verdt å bekrefte før du stoler på noen av dem.

Windows er det tydeligste eksempelet på en etikett som ikke sperrer. Der beskriver Always On at tunnelen skal vare: en enhetstunnel for maskinautentisering og en brukertunnel for kontoen som er logget på, satt opp gjennom profil-XML eller Add-VpnConnection. Ingenting i profilen hindrer en utgående pakke når tunnelen mangler, og utgående filtrering er ikke slått på som standard, så en bærbar PC på Wi-Fi virker videre mens VPN-en er nede.

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

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

Sjekk 3: mål mellomrommet, ikke ikonet

Fire overganger betyr noe, og de svikter på hver sin måte: oppstarten før noen logger på, dvale og oppvåkning, byttet fra Wi-Fi til mobildata, og en klientkrasj som lar tunnelgrensesnittet ligge halvferdig konfigurert. En ren gjenoppkobling på én av dem beviser ingenting om de tre andre.

Den rimeligste testen stopper tunnelen med vilje og prøver deretter å komme ut. Når tunnelen er nede, betyr curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com som returnerer 200 at regelen er fail-open; tidsavbrudd eller en avvist tilkobling betyr at noe fortsatt sperrer. ip route get 1.1.1.1 peker på grensesnittet som ville bære pakken, noe som vanligvis gir mer informasjon enn ikonet i systemkurven, og systemctl status wg-quick@wg0 viser om grensesnittet ble fjernet på en ryddig måte.

Kjør den samme sjekken i et annet vindu mens nettet er i endring, ikke bare etter at det har roet seg. Tiden mellom bruddet og det nye forsøket er den delen som betyr noe, og navneoppslag er den raskeste måten å oppdage at trafikk har sluppet ut: svarer den lokale oppløseren mens tunnelen er nede, er sperren ikke fullstendig.

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

To unntak er strukturelle. Klienten må nå VPN-tjeneren selv, så et regelverk som dropper alt også hindrer gjenoppkoblingen som ville gjenopprettet 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 droppet:

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 og ikke en konstant. Leverandører bytter adresser, og et utdatert unntak er den vanlige årsaken til at en kill switch som virker, blir en enhet som ikke kan koble til igjen. Lokale skrivere, NAS-delinger og utviklingstjenester hører hjemme på samme skrevne liste, ellers blir de oppdaget én støttehenvendelse om gangen.

Sjekk 5: skriv ned hva du faktisk har bevist

Hold en tabell med fire kolonner og fyll den ut ved å teste: tilstand, forventet oppførsel, observert oppførsel, bevis. Radene er overgangene fra sjekk 3 pluss én bevisst feil. En rad du ikke kan fylle med kommandoutdata, er en rad du ikke har testet, og en enhet som klarer gjenoppkoblingsraden men feiler på oppstartsraden, er vanlig nok til at de ekstra ti minuttene er verdt det.

Før du kaller det ferdig:

• Bekreft at sperreinnstillingen er atskilt fra innstillingen for gjenoppkobling, og les verdien på enheten.
• Vit hvilket lag som håndhever sperren - klientvalg, enhetspolicy eller brannmur - og hvor det laget konfigureres.
• Ta vare på én sjekkekommando som beviser sperren, og kjør den under en overgang og ikke etterpå.
• Skriv ned unntakslisten, med endepunktet, og noter hvem som oppdaterer den.
• På administrert maskinvare lar du den påtvungne policyen være i fred; å fjerne sperren endrer kravet i stedet for å reparere tunnelen.