Always-on VPN o kill switch: quina heu activat de debò?

Always-on i kill switch són a dues línies de la mateixa pantalla de configuració, per això la gent els llegeix com dos noms d’una sola funció. No ho són. Always-on és una política de reconnexió: inicia el túnel en arrencar, el recupera després d’una caiguda o d’un canvi de xarxa i continua provant mentre falla. Un kill switch és una política de trànsit: anomena els paquets que encara poden sortir de la màquina mentre el túnel està caigut. Podeu activar el primer sense el segon, i a la majoria de plataformes el resultat de fàbrica encara deixa sortir trànsit durant el buit.

Comprovació 1: el bloqueig és un interruptor propi?

A Android 10 i posteriors, un perfil de VPN desat obre darrere la icona d’engranatge dos interruptors independents: Always-on VPN i Bloca les connexions sense VPN. Només el segon és el kill switch. Amb només always-on el túnel torna després d’una caiguda, però qualsevol aplicació enmig d’una petició arriba a la xarxa per Wi-Fi o dades mòbils fins que ho fa.

Els dispositius gestionats mantenen la mateixa divisió a l’API de polítiques. setAlwaysOnVpnPackage() pren el nom del paquet i un indicador lockdownEnabled; un administrador que fixa el paquet i deixa l’indicador fals ha construït un túnel persistent, no un dispositiu tancat. La redacció de la consola poques vegades fa visible aquesta diferència.

Llegiu l’estat des del dispositiu, no des de la consola: adb shell settings get global always_on_vpn_app i adb shell settings get global always_on_vpn_lockdown. Si el primer retorna null, no hi ha cap paquet imposat a nivell de plataforma; si el segon retorna 0, la plataforma no bloqueja res. La guia de VPN d’Android descriu aquestes com a capacitats separades i no com un sol mode.

Comprovació 2: quina capa posseeix el bloqueig?

Les etiquetes viuen al client i els bloqueigs solen viure al tallafoc, per això la mateixa paraula significa coses diferents a cada plataforma. Les files de sota són les que val la pena confirmar abans de confiar en qualsevol.

Windows és l’exemple més clar d’una etiqueta que no bloqueja. Always On allà descriu la persistència del túnel: un túnel de dispositiu per a l’autenticació de la màquina, un túnel d’usuari per al compte iniciat, configurats per XML de perfil o Add-VpnConnection. Res en aquest perfil atura un paquet de sortida quan falta el túnel, i el filtratge de sortida no és actiu per defecte, així que un portàtil amb Wi-Fi continua funcionant mentre la VPN està caiguda.

WireGuard es divideix igual, però per client. WireGuard per a Windows porta una opció per túnel, Bloqueja el trànsit no tunel·litzat, que instal·la regles de filtre; les eines de Linux no tenen cap interruptor equivalent. wg-quick afegeix una ruta per a cada entrada AllowedIPs més una regla fwmark, i wg-quick down elimina les dues, així que la ruta per defecte física torna a manar sense cap paquet perdut entremig.

A les plataformes d’Apple, always-on arriba com a funció de perfil de gestió per a dispositius supervisats i s’expressa com a regles sota demanda, no com una casella. La pregunta que cal respondre des del contingut és si un túnel fallit denega el trànsit o només demana una altra connexió. El títol del menú no ho dirà.

Comprovació 3: mesureu el buit, no la icona

Quatre transicions importen i fallen de maneres diferents: arrencada abans que ningú iniciï sessió, suspensió i represa, un canvi de Wi-Fi a dades mòbils i una caiguda del client que deixa la interfície del túnel mig configurada. Una reconnexió neta en una d’elles no demostra res sobre les altres tres.

La prova més barata atura el túnel a propòsit i després intenta sortir. Amb el túnel caigut, curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com que retorna 200 vol dir que la política és fail-open; un temps esgotat o una connexió refusada vol dir que alguna cosa encara bloqueja. ip route get 1.1.1.1 anomena la interfície que portaria el paquet, cosa que normalment diu més que la icona de la safata, i systemctl status wg-quick@wg0 mostra si la interfície es va eliminar netament.

Executeu la mateixa prova en una segona finestra mentre la xarxa canvia, no només després. L’interval entre la caiguda i el reintent és la part que importa, i una consulta de nom és la manera més ràpida de notar que el trànsit s’ha escapat: si el resolutor local respon mentre el túnel està caigut, el bloqueig no és complet.

Comprovació 4: decidiu les excepcions abans de tancar

Dues excepcions són estructurals. El client ha d’arribar al servidor de VPN mateix, així que un conjunt de regles que ho descarta tot també impedeix la reconnexió que restauraria la protecció. Un portal captiu tampoc no és accessible per un túnel que no està aixecat, així que un dispositiu bloquejat en un Wi-Fi d’hotel necessita una manera documentada d’obrir el portal, no improvisada.

Una forma mínima, punt final permès i tota la resta descartada:

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

Tracteu aquesta línia de punt final com una variable, no com una constant. Els proveïdors roten adreces, i una excepció obsoleta és la raó habitual per la qual un kill switch que funcionava es converteix en un dispositiu que no pot reconnectar. Les impressores locals, els recursos compartits NAS i els serveis de desenvolupament pertanyen a la mateixa llista escrita, o es descobreixen un tiquet de suport alhora.

Comprovació 5: registreu què heu demostrat realment

Manteniu una taula de quatre columnes i ompliu-la provant: estat, comportament esperat, comportament observat, evidència. Les files són les transicions de la comprovació 3 més una fallada deliberada. Una fila que no podeu omplir amb sortida de comanda és una fila que no heu provat, i un dispositiu que passa la fila de reconnexió i falla la d’arrencada és prou comú perquè valguin els deu minuts extra.

Abans de donar-ho per fet:

• Confirmeu que la configuració de bloqueig és separada de la de reconnexió, i llegiu-ne el valor al dispositiu.
• Saber quina capa aplica el bloqueig - opció del client, política del dispositiu o tallafoc - i on es configura aquesta capa.
• Manteniu una comanda de prova que demostri el bloqueig, i executeu-la durant una transició i no després.
• Escriviu la llista d’excepcions, punt final inclòs, i anoteu qui l’actualitza.
• En maquinari gestionat, deixeu la política imposada; treure el bloqueig canvia el requisit en lloc de reparar el túnel.