Always-on VPN eller kill switch: hvilken en har du egentlig slået til?

Always-on og kill switch står to linjer fra hinanden på samme indstillingsskærm, så folk læser dem som to navne for én funktion. Det er de ikke. Always-on er en genopkoblingspolitik: start tunnelen ved boot, hent den tilbage efter et nedbrud eller et netværksskift, og bliv ved med at prøve, mens det fejler. En kill switch er en trafikpolitik: den navngiver de pakker, der stadig må forlade maskinen, mens tunnelen er nede. Du kan slå det første til uden det andet, og på de fleste platforme lukker standardresultatet stadig trafik ud i mellemrummet.

Kontrol 1: er blokeringen sin egen kontakt?

På Android 10 og senere åbner en gemt VPN-profil to uafhængige kontakter bag tandhjulet: Always-on VPN og Bloker forbindelser uden VPN. Kun den anden er kill switch. Med kun always-on kommer tunnelen tilbage efter et udfald, men enhver app midt i en anmodning når netværket via Wi-Fi eller mobildata, indtil den gør.

Administrerede enheder beholder samme opdeling i politik-API’et. setAlwaysOnVpnPackage() tager pakkenavnet og et lockdownEnabled-flag; en administrator, der sætter pakken og lader flaget være falsk, har bygget en vedvarende tunnel, ikke en lukket enhed. Konsollens ordlyd gør sjældent den forskel synlig.

Læs tilstanden på enheden i stedet for i 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 håndhævet på platformsniveau; returnerer den anden 0, blokerer platformen intet. Android VPN-vejledningen beskriver disse som separate evner, ikke én tilstand.

Kontrol 2: hvilket lag ejer blokeringen?

Etiketter bor i klienten, og blokeringer bor normalt i firewallen, og derfor betyder samme ord noget forskelligt på hver platform. Rækkerne nedenfor er værd at bekræfte, før du tror på nogen af dem.

Windows er det tydeligste eksempel på en etiket, der ikke blokerer. Always On beskriver der tunnellens vedholdenhed: en enhedstunnel til maskinautentificering, en brugertunnel til den loggede konto, konfigureret via profil-XML eller Add-VpnConnection. Intet i den profil stopper en udgående pakke, når tunnelen mangler, og udgående filtrering er ikke slået til som standard, så en laptop på Wi-Fi fortsætter, mens VPN’en er nede.

WireGuard deler sig på samme måde, men pr. klient. WireGuard til Windows har en indstilling pr. tunnel, Bloker trafik uden for tunnelen, som installerer filterregler; Linux-værktøjerne har ingen tilsvarende kontakt. wg-quick tilføjer en rute for hver AllowedIPs-post plus en fwmark-regel, og wg-quick down fjerner begge, så den fysiske standardrute tager over igen uden en tabt pakke imellem.

På Apple-platforme kommer always-on som en administrationsprofilfunktion til overvågede enheder og udtrykkes som regler på anmodning, ikke som et afkrydsningsfelt. Spørgsmålet fra nyttelasten er, om en mislykket tunnel afviser trafik eller blot anmoder om en anden forbindelse. Menutitlen fortæller det ikke.

Kontrol 3: mål mellemrummet, ikke ikonet

Fire overgange betyder noget, og de fejler forskelligt: boot før nogen logger ind, dvale og genoptagelse, et skift fra Wi-Fi til mobildata og et klientnedbrud, der efterlader tunnelegrænsefladen halvt konfigureret. En ren genopkobling på én af dem beviser intet om de andre tre.

Den billigste test stopper tunnelen med vilje og prøver så at komme ud. Med tunnelen nede betyder curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com, der returnerer 200, at politikken er fail-open; en timeout eller en afvist forbindelse betyder, at noget stadig blokerer. ip route get 1.1.1.1 navngiver den grænseflade, der ville bære pakken, hvilket normalt siger mere end bakkeikonet, og systemctl status wg-quick@wg0 viser, om grænsefladen blev fjernet rent.

Kør samme prøve i et andet vindue, mens netværket skifter, ikke kun bagefter. Intervallet mellem udfaldet og nyt forsøg er den vigtige del, og et navneopslag er den hurtigste måde at opdage, at trafik slap ud: svarer den lokale resolver, mens tunnelen er nede, er blokeringen ikke komplet.

Kontrol 4: beslut undtagelserne, før du låser

To undtagelser er strukturelle. Klienten skal nå selve VPN-serveren, så et regelsæt, der dropper alt, også forhindrer den genopkobling, der ville genskabe beskyttelsen. En captive portal kan heller ikke nås gennem en tunnel, der ikke er oppe, så en låst enhed på hotel-Wi-Fi har brug for en dokumenteret måde at åbne portalen på, ikke en improviseret.

En minimal form, slutpunkt tilladt og alt andet 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
  }
}

Behandl den slutpunktslinje som en variabel, ikke en konstant. Udbyderne roterer adresser, og en forældet undtagelse er den sædvanlige grund til, at en fungerende kill switch bliver en enhed, der ikke kan genopkoble. Lokale printere, NAS-delinger og udviklingstjenester hører i samme skrevne liste, ellers opdages de en supportbillet ad gangen.

Kontrol 5: skriv ned, hvad du faktisk beviste

Hold en tabel med fire kolonner og fyld den ved at teste: tilstand, forventet adfærd, observeret adfærd, bevis. Rækkerne er overgangene fra kontrol 3 plus én bevidst fejl. En række, du ikke kan fylde med kommandouddata, er en række, du ikke har testet, og en enhed, der består genopkoblingsrækken og fejler bootrækken, er almindelig nok til at være de ekstra ti minutter værd.

Før du kalder det færdigt:

• Bekræft, at blokeringsindstillingen er adskilt fra genopkoblingsindstillingen, og læs dens værdi på enheden.
• Vid, hvilket lag der håndhæver blokeringen - klientindstilling, enhedspolitik eller firewall - og hvor det lag konfigureres.
• Hold én prøvekommando, der beviser blokeringen, og kør den under en overgang, ikke efter.
• Skriv undtagelseslisten ned, slutpunkt inkluderet, og noter, hvem der opdaterer den.
• På administreret hardware, lad den håndhævede politik være; at fjerne blokeringen ændrer kravet i stedet for at reparere tunnelen.