La aplicación VPN se ha colgado: ¿sigue activo el kill switch?

Empiece donde empieza el usuario: la ventana del cliente ya no está, el icono de la bandeja ha desaparecido y el navegador o carga o no carga. Esa observación por sí sola no puede decirle si el bloqueo sobrevivió. La respuesta depende de qué componente guarda las reglas, de si ese componente murió con la ventana y de si la plataforma mantiene la imposición fuera de la aplicación. Avance desde la ventana hasta el proceso, luego hasta el cortafuegos y luego hasta la ruta real.

No reinicie primero; un reinicio suele destruir las pruebas.

Empiece por lo que sigue ejecutándose

Abra la lista de procesos antes de tocar nada. Un cliente de escritorio suele dividirse en un proceso de interfaz de usuario y un servicio o demonio, y un cuelgue en el primero no detiene necesariamente el segundo. En Windows el servicio puede seguir en la lista, en Linux la unidad puede seguir activa y en Android el túnel pertenece al sistema una vez dado el consentimiento. Lea esos tres hechos en ese orden.

Si el demonio está vivo, el túnel probablemente también lo está, y la ventana que falta es solo cosmética.

Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40

Lea el bloqueo en quien lo impone, no en la aplicación

Si el cliente implementa su kill switch insertando reglas de cortafuegos, esas reglas pertenecen al sistema operativo y sobreviven al proceso que las creó. Un cuelgue le deja entonces bloqueado sin ninguna interfaz para desactivarlo, lo que parece una red rota más que una protección. Si en cambio el bloqueo vive dentro de la propia ruta de paquetes del cliente, matar el proceso elimina el bloqueo en el mismo momento.

Android lo gestiona aún de otra manera: la opción always-on VPN con lockdown es un ajuste de la plataforma, así que el bloqueo persiste con independencia del proceso de la aplicación, y el sistema puede reiniciar el servicio. Consulte la documentación de la plataforma para el comportamiento exacto en lugar de suponer que coincide con un cliente de escritorio.

Distinga una salida limpia de un cuelgue

Un Quit normal suele ejecutar la ruta de apagado del cliente, que elimina reglas y cierra el túnel a propósito. Un cuelgue se salta esa ruta y deja lo que el impositor ya había instalado. La diferencia se ve en las marcas de tiempo de las reglas respecto a la salida del proceso, y en si todavía existe una interfaz de túnel antigua sin propietario.

Esa distinción decide su recuperación: una salida limpia puede necesitar una conexión nueva, mientras que un cuelgue puede necesitar que las reglas sobrantes se eliminen mediante la acción de reparación admitida por el cliente.

Recupere sin romper otros controles

Reinicie el cliente mediante su flujo de trabajo documentado y luego compruebe las dos mitades del requisito: el túnel transporta tráfico y el bloqueo sigue aplicándose cuando debe. Vaciar todo el cortafuegos para recuperar la conectividad también elimina controles no relacionados, y ese intercambio rara vez merece la pena.

Ante un cuelgue repetido, reúna la versión del cliente, la compilación de la plataforma y los registros acotados que pida el proveedor. Un perfil de cliente, una clave privada o un registro completo de conexión de otra cuenta no son necesarios para un informe de cuelgue, e incluirlos convierte un caso de soporte en un problema de tratamiento de datos.

Un cuelgue no es prueba de una fuga. La prueba es un paquete observado que sale por una ruta que la política debía impedir, capturado en el momento en que el cliente estaba caído. Pruébelo a propósito, con un destino inofensivo, y anote qué capa de imposición aguantó.