VPN always-on o kill switch: ¿cuál activó en realidad?

Always-on y kill switch están a dos líneas en la misma pantalla de ajustes, así que la gente los lee como dos nombres de una sola función. No lo son. Always-on es una política de reconexión: inicia el túnel al arrancar, lo recupera tras una caída o un cambio de red y sigue intentándolo mientras falla. Un kill switch es una política de tráfico: nombra los paquetes que aún pueden salir del equipo mientras el túnel está caído. Puede activar el primero sin el segundo, y en la mayoría de plataformas el resultado de fábrica todavía deja salir tráfico durante el hueco.

Comprobación 1: ¿el bloqueo es un interruptor propio?

En Android 10 y posteriores, un perfil de VPN guardado abre tras el icono del engranaje dos interruptores independientes: VPN always-on y Bloquear conexiones sin VPN. Solo el segundo es el kill switch. Con solo always-on el túnel vuelve tras una caída, pero cualquier aplicación a mitad de una petición llega a la red por Wi-Fi o datos móviles hasta que eso ocurre.

Los equipos gestionados mantienen la misma división en la API de políticas. setAlwaysOnVpnPackage() toma el nombre del paquete y un indicador lockdownEnabled; quien fija el paquete y deja el indicador en falso ha construido un túnel persistente, no un equipo cerrado. La redacción de la consola rara vez hace visible esa diferencia.

Lea el estado desde el dispositivo y no desde la consola: adb shell settings get global always_on_vpn_app y adb shell settings get global always_on_vpn_lockdown. Si el primero devuelve null, no hay ningún paquete impuesto a nivel de plataforma; si el segundo devuelve 0, la plataforma no bloquea nada. La guía de VPN de Android describe estas como capacidades separadas y no como un solo modo.

Comprobación 2: ¿qué capa posee el bloqueo?

Las etiquetas viven en el cliente y los bloqueos suelen vivir en el cortafuegos, por eso la misma palabra significa cosas distintas en cada plataforma. Las filas de abajo merecen confirmación antes de fiarse de cualquiera.

Windows es el ejemplo más claro de una etiqueta que no bloquea. Always On allí describe la persistencia del túnel: un túnel de dispositivo para la autenticación de la máquina, un túnel de usuario para la cuenta iniciada, configurados por XML de perfil o Add-VpnConnection. Nada en ese perfil detiene un paquete saliente cuando falta el túnel, y el filtrado de salida no está activo por defecto, así que un portátil en Wi-Fi sigue funcionando mientras la VPN está caída.

WireGuard se divide igual, pero por cliente. WireGuard para Windows lleva una opción por túnel, Bloquear tráfico no tunelizado, que instala reglas de filtro; las herramientas de Linux no tienen ese interruptor. wg-quick añade una ruta por cada entrada AllowedIPs más una regla fwmark, y wg-quick down elimina ambas, así que la ruta física por defecto vuelve a mandar sin perder ningún paquete entre medias.

En las plataformas de Apple, always-on llega como función de perfil de gestión para equipos supervisados y se expresa como reglas bajo demanda, no como una casilla. La pregunta que hay que responder desde la carga es si un túnel fallido deniega el tráfico o solo pide otra conexión. El título del menú no se lo dirá.

Comprobación 3: mida el hueco, no el icono

Cuatro transiciones importan y fallan de forma distinta: arranque antes de que nadie inicie sesión, suspensión y reanudación, un cambio de Wi-Fi a datos móviles y una caída del cliente que deja la interfaz del túnel a medio configurar. Una reconexión limpia en una de ellas no demuestra nada sobre las otras tres.

La prueba más barata detiene el túnel a propósito y luego intenta salir. Con el túnel caído, curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com devolviendo 200 significa que la política es fail-open; un tiempo agotado o una conexión rechazada significa que algo sigue bloqueando. ip route get 1.1.1.1 nombra la interfaz que llevaría el paquete, lo que suele decir más que el icono de la bandeja, y systemctl status wg-quick@wg0 muestra si la interfaz se retiró limpiamente.

Ejecute la misma prueba en una segunda ventana mientras la red cambia, no solo después. El intervalo entre la caída y el reintento es la parte que importa, y una consulta de nombre es la forma más rápida de notar que el tráfico se escapó: si el resolutor local responde mientras el túnel está caído, el bloqueo no está completo.

Comprobación 4: decida las excepciones antes de cerrar

Dos excepciones son estructurales. El cliente tiene que alcanzar el propio servidor de VPN, así que un conjunto de reglas que descarta todo también impide la reconexión que restauraría la protección. Un portal cautivo tampoco es alcanzable por un túnel que no está levantado, así que un equipo bloqueado en el Wi-Fi de un hotel necesita una forma documentada de abrir el portal, no improvisada.

Una forma mínima, punto final permitido y todo lo demás descartado:

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

Trate esa línea de punto final como una variable, no como una constante. Los proveedores rotan direcciones, y una excepción obsoleta es la razón habitual de que un kill switch que funcionaba se convierta en un equipo que no puede reconectar. Las impresoras locales, los recursos compartidos NAS y los servicios de desarrollo pertenecen a la misma lista escrita, o se descubren un ticket de soporte a la vez.

Comprobación 5: registre qué demostró de verdad

Mantenga una tabla de cuatro columnas y llénela probando: estado, comportamiento esperado, comportamiento observado, evidencia. Las filas son las transiciones de la comprobación 3 más un fallo deliberado. Una fila que no puede llenar con salida de comando es una fila que no ha probado, y un equipo que pasa la fila de reconexión y falla la de arranque es lo bastante común para valer los diez minutos extra.

Antes de darlo por hecho:

• Confirme que el ajuste de bloqueo está separado del de reconexión, y lea su valor en el dispositivo.
• Sepa qué capa aplica el bloqueo - opción del cliente, política del equipo o cortafuegos - y dónde se configura esa capa.
• Guarde un comando de prueba que demuestre el bloqueo, y ejecútelo durante una transición y no después.
• Escriba la lista de excepciones, punto final incluido, y anote quién la actualiza.
• En hardware gestionado, deje la política impuesta en paz; quitar el bloqueo cambia el requisito en lugar de arreglar el túnel.