Always-on VPN of kill switch: wat heb je nu echt aangezet?

Always-on en kill switch staan twee regels van elkaar op hetzelfde instellingenscherm, dus mensen lezen ze als twee namen voor één functie. Dat zijn ze niet. Always-on is een herverbindingsbeleid: start de tunnel bij het opstarten, haal hem terug na een crash of netwerkwijziging en blijf het proberen zolang het mislukt. Een kill switch is een verkeersbeleid: het benoemt de pakketten die de machine nog mogen verlaten terwijl de tunnel plat ligt. Je kunt het eerste aanzetten zonder het tweede, en op de meeste platforms laat het standaardresultaat in dat gat nog steeds verkeer naar buiten.

Controle 1: is de blokkade een eigen schakelaar?

Op Android 10 en later opent een opgeslagen VPN-profiel twee onafhankelijke schakelaars achter het tandwielpictogram: Always-on VPN en Block connections without VPN. Alleen de tweede is de kill switch. Met alleen always-on komt de tunnel na een onderbreking inderdaad terug, en elke app midden in een verzoek kan via Wi-Fi of mobiele data het netwerk bereiken totdat dat gebeurt.

Beheerde apparaten houden dezelfde splitsing in de beleids-API. setAlwaysOnVpnPackage() neemt de pakketnaam en een lockdownEnabled-vlag; een beheerder die het pakket instelt en de vlag op false laat, heeft een blijvende tunnel gebouwd, geen gesloten apparaat. De formulering in de console maakt dat verschil zelden zichtbaar.

Lees de status van het apparaat, niet uit de console: adb shell settings get global always_on_vpn_app en adb shell settings get global always_on_vpn_lockdown. Geeft de eerste null terug, dan wordt er op platformniveau geen pakket afgedwongen; geeft de tweede 0 terug, dan blokkeert het platform niets. De Android VPN-gids beschrijft deze als aparte mogelijkheden, niet als één modus.

Controle 2: welke laag bezit de blokkade?

Labels zitten in de client en blokkades meestal in de firewall, daarom betekent hetzelfde woord op elk platform iets anders. De rijen hieronder zijn de rijen die het waard zijn om te bevestigen voordat je een ervan vertrouwt.

Windows is het duidelijkste voorbeeld van een label dat niet blokkeert. Daar beschrijft Always On de persistentie van de tunnel: een apparaattunnel voor machineauthenticatie en een gebruikerstunnel voor het aangemelde account, ingesteld via profiel-XML of Add-VpnConnection. Niets in dat profiel houdt een uitgaand pakket tegen als de tunnel ontbreekt, en uitgaande filtering staat standaard niet aan, dus een laptop op Wi-Fi blijft werken terwijl de VPN plat ligt.

WireGuard splitst op dezelfde manier, maar per client. WireGuard for Windows heeft per tunnel een optie Block untunneled traffic die filterregels installeert; de Linux-gereedschappen hebben geen equivalente schakelaar. wg-quick voegt een route toe voor elke AllowedIPs-vermelding plus een fwmark-regel, en wg-quick down verwijdert beide, zodat de fysieke standaardroute het weer overneemt zonder dat er één pakket verloren gaat.

Op Apple-platforms komt always-on als functie van een beheerprofiel voor gecontroleerde apparaten en wordt het uitgedrukt als on-demand-regels in plaats van een selectievakje. De vraag die je uit de payload moet beantwoorden is of een mislukte tunnel verkeer weigert of alleen om een andere verbinding vraagt. De menutitel vertelt het je niet.

Controle 3: meet het gat, niet het pictogram

Vier overgangen doen ertoe, en ze falen verschillend: opstarten voordat iemand inlogt, slaap en hervatten, de overgang van Wi-Fi naar mobiele data, en een clientcrash die de tunnelinterface half geconfigureerd achterlaat. Een schone herverbinding op één daarvan bewijst niets over de andere drie.

De goedkoopste test stopt de tunnel met opzet en probeert dan naar buiten te gaan. Ligt de tunnel plat, dan betekent curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com dat 200 teruggeeft dat het beleid fail-open is; een time-out of een geweigerde verbinding betekent dat er nog iets blokkeert. ip route get 1.1.1.1 noemt de interface die het pakket zou dragen, wat meestal informatiever is dan het pictogram in de systeemvak, en systemctl status wg-quick@wg0 laat zien of de interface netjes is verwijderd.

Voer dezelfde controle uit in een tweede venster terwijl het netwerk verandert, niet alleen nadat het tot rust is gekomen. Het interval tussen de onderbreking en de nieuwe poging is het deel dat ertoe doet, en naamresolutie is de snelste manier om te merken dat verkeer ontsnapte: als de lokale resolver antwoordt terwijl de tunnel plat ligt, is de blokkade niet compleet.

Controle 4: bepaal de uitzonderingen voordat je afsluit

Twee uitzonderingen zijn structureel. De client moet de VPN-server zelf bereiken, dus een regelset die alles laat vallen verhindert ook de herverbinding die de bescherming zou herstellen. Een captive portal is evenmin bereikbaar via een tunnel die niet overeind staat, dus een vergrendeld apparaat op hotel-Wi-Fi heeft een gedocumenteerde manier nodig om het portaal te openen, geen geïmproviseerde.

Een minimale vorm, het endpoint toegestaan en al het overige laten vallen:

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

Behandel die endpointregel als een variabele, niet als een constante. Providers wisselen adressen en een verouderde uitzondering is de gebruikelijke reden dat een werkende kill switch een apparaat wordt dat niet meer kan herverbinden. Lokale printers, NAS-shares en ontwikkeldiensten horen op dezelfde geschreven lijst, anders worden ze één supportticket per keer ontdekt.

Controle 5: leg vast wat je werkelijk hebt bewezen

Houd een tabel met vier kolommen bij en vul die door te testen: toestand, verwacht gedrag, waargenomen gedrag, bewijs. De rijen zijn de overgangen uit controle 3 plus één bewuste fout. Een rij die je niet met commando-uitvoer kunt vullen is een rij die je niet hebt getest, en een apparaat dat de herverbindingsrij haalt maar de opstartrij faalt, komt vaak genoeg voor om de extra tien minuten waard te zijn.

Voordat je het af noemt:

• Bevestig dat de blokkeringsinstelling losstaat van de herverbindingsinstelling en lees de waarde op het apparaat.
• Weet welke laag de blokkade afdwingt - clientoptie, apparaatbeleid of firewall - en waar die laag wordt geconfigureerd.
• Bewaar één controlecommando dat de blokkade bewijst en voer het uit tijdens een overgang, niet erna.
• Schrijf de uitzonderingenlijst op, endpoint inbegrepen, en noteer wie die vernieuwt.
• Laat op beheerde hardware het afgedwongen beleid met rust; de blokkade weghalen verandert de eis in plaats van de tunnel te repareren.