¿Sobrevive un kill switch de VPN a un reinicio? Cómo comprobarlo

Reiniciar es la forma más común en que la gente prueba un kill switch, y es la prueba que miente con más frecuencia. La casilla del cliente es una preferencia; lo que importa es si algo impone un bloqueo entre el momento en que la pila de red sube y el momento en que el túnel está realmente establecido. En Windows ese algo suele ser un filtro en Windows Filtering Platform, en Linux un conjunto de reglas cargado por una unidad, en macOS un ancla de pf, en Android los indicadores propios del sistema de always-on y bloqueo. Estos arreglos se comportan de forma muy distinta a lo largo de un reinicio, y solo los de nivel de plataforma están en su sitio antes de que nadie pueda iniciar sesión.

Un reinicio plantea tres preguntas separadas

Divida la pregunta. Primero, ¿existe la política en disco en una forma que algo lea al arrancar? Segundo, ¿se ejecuta ese lector antes de que pueda salir tráfico alguno? Tercero, ¿cubre la política el tráfico que le importa, es decir, cada proceso, ambas familias de direcciones y DNS. Un sí a la primera y un no a la segunda producen exactamente el fallo que la gente reporta como un kill switch que no sobrevive a un reinicio: el tráfico se escapa durante unos segundos al arrancar, y nadie se da cuenta hasta que alguien va a mirar.

Mantenga las capas separadas. Un conjunto de reglas de cortafuegos guardado, un servicio que arranca con el sistema y una preferencia del cliente son tres objetos distintos con tres vidas distintas. La preferencia sobrevive a los reinicios porque es un valor de un archivo de configuración. Las reglas son lo único que bloquea paquetes, y desaparecen con el núcleo que las sostenía.

Encuentre el objeto que restablece el bloqueo

En Linux las reglas de netfilter viven en el núcleo. Nada las reescribe al arrancar salvo que usted lo haya dispuesto: iptables-save más netfilter-persistent, nftables.service carga /etc/nftables.conf, o una unidad de systemd que ejecuta su propio script. Compruebe qué está habilitado en lugar de lo que recuerda haber configurado.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

Un conjunto de reglas vacío unos segundos después de arrancar es la respuesta a la pregunta del título. En Windows pregunte al servicio del cliente cómo arranca y luego vuelque el estado del filtro de plataforma mientras el túnel está caído.

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

El segundo comando escribe wfpstate.xml en el directorio actual. Busque filtros con una acción de bloqueo que ya existan antes de que el cliente se conecte. Base Filtering Engine arranca temprano y restaura los filtros añadidos con la marca persistente, por eso algunos kill switches bloquean el tráfico antes de que exista cualquier ventana de cliente y otros no. En macOS, sudo pfctl -s info informa de si pf está habilitado, sudo pfctl -s rules muestra qué hay cargado, y los clientes de VPN suelen asociar sus reglas a un ancla en lugar del conjunto principal. Una regla que nombra utun3 puede apuntar a otra interfaz tras el siguiente arranque, porque ese número se asigna en tiempo de ejecución.

Vigile el hueco entre la subida de la red y la del túnel

El intervalo peligroso no es todo el reinicio, es el hueco. La interfaz recibe un arrendamiento y una ruta predeterminada en un momento, el servicio de VPN arranca en otro, y el túnel se autentica aún más tarde, a veces solo después de que un usuario inicie sesión y se ejecute un agente de credenciales. Si el bloqueo se aplica al final, todo lo que hay en el hueco sale en claro.

En equipos con systemd, lea el orden en lugar de adivinarlo. Ejecute systemctl cat en las unidades de VPN y de cortafuegos y busque After= o Before= frente a network-pre.target y network-online.target. Una unidad de cortafuegos ordenada después de network-online.target pierde contra la interfaz; la que es requerida por y ordenada antes de network-pre.target gana. En Windows las preguntas equivalentes son el tipo de inicio del servicio y sus dependencias, porque un servicio puesto en Manual no puede bloquear un proceso de arranque. Si su requisito incluye tráfico antes de iniciar sesión, solo lo satisface un arreglo a nivel de dispositivo: un túnel de dispositivo Always On VPN se autentica con un certificado de máquina y se conecta antes de que el usuario inicie sesión, y Microsoft documenta la configuración del túnel de dispositivo por separado del túnel de usuario. Android toma la otra vía, imponiendo la VPN always-on y bloqueando las conexiones sin ella desde el sistema y no desde un proceso de aplicación.

Ejecute la prueba y luego compare dos cronologías

Reinicie con un destino que no cuesta nada si se filtra, y capture el estado durante el hueco en lugar de después. El método más limpio es una sonda de arranque: una unidad oneshot o una tarea programada que arranca tan pronto como la plataforma lo permite, registra la ruta predeterminada y el estado del cortafuegos, intenta una petición con un tiempo de espera corto y añade una línea a un archivo local. Compare ese registro con la hora de inicio del servicio de VPN de journalctl -b -u o del registro del sistema.

Después haga la prueba habitual: túnel arriba, corte la conexión, observe si el tráfico directo queda bloqueado, restaure. Pasar la segunda y fallar la primera es el resultado normal, y significa que la imposición es del lado del cliente, aplicada cuando el cliente se conecta y no al arrancar. En la última máquina que audité, el bloqueo venía de un script despachador de NetworkManager: presente y correcto e inútil para los segundos previos a que la interfaz subiera. Anote ambos resultados, porque sobrevivir a un reinicio solo significa algo cuando dice qué capa sobrevivió y desde qué momento.

Cierre el hueco sin cortar su camino de vuelta

Si falta el bloqueo al arrancar, baje la imposición una capa en lugar de añadir una segunda regla de cliente. Guarde el conjunto de reglas y cárguelo desde una unidad ordenada antes de que la red sea utilizable, y asegúrese de que esa unidad no necesita una consulta DNS ni un montaje de red que se supone que protege. El alcance importa tanto como el momento: las reglas que coinciden con un ID de usuario o un cgroup dejan fuera del bloqueo a todos los demonios del sistema, y un conjunto de reglas que solo trata IPv4 deja IPv6 y DNS accesibles.

Déjese un camino de vuelta. Una máquina que bloquea todo al arrancar y luego no puede autenticarse no tiene red alguna, y la solución no es borrar el bloqueo sino reparar la credencial o el orden. Mantenga un procedimiento documentado de consola local y una excepción estrecha y deliberada para lo que el túnel necesita de verdad, como la dirección del servidor y el resolutor usado antes de que exista el túnel.

Antes de confiar en la configuración, confirme cuatro cosas en orden. La política está almacenada donde el arranque lee. Ese lector se ejecuta antes de que la interfaz sea utilizable. El bloqueo cubre ambas familias de direcciones y DNS. La VPN aún puede autenticarse mientras el bloqueo está activo. Cuando las cuatro se cumplen, un reinicio no cambia nada.