Always-on VPN eller kill switch: vad slog du egentligen på?

Always-on och kill switch står två rader från varandra på samma inställningsskärm, så folk läser dem som två namn på en och samma funktion. Det är de inte. Always-on är en återanslutningspolicy: starta tunneln vid uppstart, få tillbaka den efter en krasch eller nätverksändring och fortsätt försöka så länge den misslyckas. Kill switch är en trafikpolicy: den namnger de paket som fortfarande får lämna maskinen medan tunneln ligger nere. Du kan slå på den första utan den andra, och på de flesta plattformar släpper standardresultatet fortfarande ut trafik under den luckan.

Kontroll 1: är blockeringen en egen brytare?

På Android 10 och senare öppnar en sparad VPN-profil två oberoende reglage bakom kugghjulsikonen: Always-on VPN och Block connections without VPN. Bara den andra är kill switch. Med bara always-on kommer tunneln visserligen tillbaka efter ett avbrott, och vilken app som helst mitt i en förfrågan kan nå nätet via Wi-Fi eller mobildata tills det sker.

Hanterade enheter behåller samma delning i policy-API:t. setAlwaysOnVpnPackage() tar paketnamnet och en lockdownEnabled-flagga; en administratör som sätter paketet och lämnar flaggan på false har byggt en varaktig tunnel, inte en stängd enhet. Formuleringarna i konsolen gör sällan den skillnaden synlig.

Läs tillståndet från enheten, inte från konsolen: adb shell settings get global always_on_vpn_app och adb shell settings get global always_on_vpn_lockdown. Om den första returnerar null är inget paket påtvingat på plattformsnivå; om den andra returnerar 0 blockerar plattformen ingenting. Androids VPN-guide beskriver dessa som separata förmågor, inte som ett läge.

Kontroll 2: vilket lager äger blockeringen?

Etiketterna bor i klienten och blockeringarna oftast i brandväggen, och därför betyder samma ord olika saker på varje plattform. Raderna nedan är de som är värda att bekräfta innan du litar på någon av dem.

Windows är det tydligaste exemplet på en etikett som inte blockerar. Där beskriver Always On tunnelns varaktighet: en enhetstunnel för maskinautentisering och en användartunnel för det inloggade kontot, konfigurerade via profil-XML eller Add-VpnConnection. Inget i den profilen stoppar ett utgående paket när tunneln saknas, och utgående filtrering är inte på som standard, så en bärbar dator på Wi-Fi fortsätter fungera medan VPN:en ligger nere.

WireGuard delar sig på samma sätt, men per klient. WireGuard for Windows har ett Block untunneled traffic-val per tunnel som installerar filterregler; Linux-verktygen har ingen motsvarande brytare. wg-quick lägger till en rutt för varje AllowedIPs-post plus en fwmark-regel, och wg-quick down tar bort båda, så den fysiska standardrutten tar över igen utan att ett enda paket tappas.

På Apple-plattformar kommer always-on som en funktion i hanteringsprofilen för övervakade enheter och uttrycks som on-demand-regler i stället för en kryssruta. Frågan du måste svara på utifrån nyttolasten är om en misslyckad tunnel nekar trafik eller bara ber om en annan anslutning. Menytiteln berättar det inte.

Kontroll 3: mät luckan, inte ikonen

Fyra övergångar spelar roll, och de misslyckas olika: uppstarten innan någon loggar in, vila och uppvaknande, bytet från Wi-Fi till mobildata och en klientkrasch som lämnar tunnelgränssnittet halvkonfigurerat. En ren återanslutning på en av dem bevisar ingenting om de andra tre.

Det billigaste testet stoppar tunneln med avsikt och försöker sedan komma ut. Med tunneln nere betyder curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com som returnerar 200 att policyn är fail-open; en timeout eller en nekad anslutning betyder att något fortfarande blockerar. ip route get 1.1.1.1 namnger gränssnittet som skulle bära paketet, vilket oftast är mer informativt än ikonen i aktivitetsfältet, och systemctl status wg-quick@wg0 visar om gränssnittet togs bort rent.

Kör samma kontroll i ett andra fönster medan nätet ändras, inte bara efter att det har lugnat sig. Intervallet mellan avbrottet och det nya försöket är det som spelar roll, och namnuppslagning är det snabbaste sättet att märka att trafik slapp ut: om den lokala resolvern svarar medan tunneln ligger nere är blockeringen inte fullständig.

Kontroll 4: bestäm undantagen innan du låser

Två undantag är strukturella. Klienten måste nå själva VPN-servern, så en regeluppsättning som släpper allt hindrar också återanslutningen som skulle återställa skyddet. En captive portal går inte heller att nå genom en tunnel som inte är uppe, så en låst enhet på hotell-Wi-Fi behöver ett dokumenterat sätt att öppna portalen, inte ett improviserat.

En minimal form, slutpunkten tillåten och allt annat släppt:

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
  }
}

Behandla den slutpunktsraden som en variabel, inte en konstant. Leverantörer roterar adresser, och ett föråldrat undantag är det vanliga skälet till att en fungerande kill switch blir en enhet som inte kan återansluta. Lokala skrivare, NAS-delningar och utvecklingstjänster hör hemma på samma skrivna lista, annars upptäcks de en supportbiljett i taget.

Kontroll 5: skriv ner vad du faktiskt bevisade

Håll en tabell med fyra kolumner och fyll den genom att testa: tillstånd, förväntat beteende, observerat beteende, bevis. Raderna är övergångarna från kontroll 3 plus ett avsiktligt fel. En rad du inte kan fylla med kommandoutdata är en rad du inte har testat, och en enhet som klarar återanslutningsraden men fallerar på uppstartsraden är vanligt nog att vara värt de extra tio minuterna.

Innan du kallar det klart:

• Bekräfta att blockeringsinställningen är separat från återanslutningsinställningen och läs av värdet på enheten.
• Vet vilket lager som genomdriver blockeringen - klientval, enhetspolicy eller brandvägg - och var det lagret konfigureras.
• Behåll ett kontrollkommando som bevisar blockeringen och kör det under en övergång, inte efter.
• Skriv ner undantagslistan, slutpunkten inkluderad, och notera vem som uppdaterar den.
• På hanterad hårdvara låter du den påtvingade policyn vara; att ta bort blockeringen ändrar kravet i stället för att laga tunneln.