La VPN se cae al apagar la pantalla: ¿qué ciclo de vida?
Una pantalla bloqueada puede suspender al cliente, caducar una asignación o matar una sesión de aplicación. Una prueba controlada los separa antes de tocar cualquier ajuste.
La transferencia se detiene en el momento en que la pantalla se oscurece, y la insignia llega unos segundos después. Tres cosas distintas producen esa imagen: el proceso cliente queda restringido, la ruta queda inactiva y pierde su asignación, o la aplicación pierde una sesión que el túnel nunca notó. Cada una tiene sus propias pruebas, y cada arreglo pertenece a una capa distinta. El orden siguiente las separa con una sola prueba controlada en lugar de una revisión a ciegas de todos los ajustes.
Tres fallos que parecen idénticos
Un proceso en segundo plano restringido deja de enviar keepalives, y el otro extremo acaba declarando muerto el túnel. Una asignación inactiva en la ruta puede caducar mientras el dispositivo duerme, así que el tráfico de vuelta nunca llega a un cliente que sigue perfectamente vivo. Una aplicación puede perder su propia conexión mientras el túnel sigue en pie, lo que produce un diálogo de error con una insignia de VPN sana detrás. Desde el asiento del usuario, las tres se leen como la VPN que se cayó al apagar la pantalla.
La distinción importa porque los remedios se contradicen en la práctica. Eximir al cliente de las restricciones de energía arregla el primer caso y no hace nada por una asignación que caducó. Alargar los keepalives arregla el segundo y desperdicia batería en el tercero, donde nada relacionado con la red estaba mal desde el principio.
Compare activo e inactivo bajo control
Mantenga todo constante: mismo dispositivo, misma red, mismo extremo, misma aplicación. Bloquee la pantalla durante un intervalo corto y fijo y anote tres observaciones: si el cliente informa de una desconexión, si una petición nueva funciona al desbloquear y si se reanudó la transferencia existente. Luego repita con un keepalive o una petición periódica en marcha y compare las dos ejecuciones. Una variable cambiada entre dos ejecuciones vale más que una semana de informes anecdóticos.
El momento pertenece al registro. Una caída a los noventa segundos huele a asignación o a intervalo de keepalive, mientras que una caída en el momento del bloqueo apunta a la suspensión del proceso. Anote tanto el desencadenante como el intervalo, porque el siguiente intento necesita algo con lo que comparar.
Lea la política de segundo plano de la plataforma
En Android, el ciclo de vida del servicio VPN forma parte de la plataforma, y always-on y block-without-VPN son interruptores separados con efectos separados. Un cliente que no es always-on puede detenerse cuando el sistema recupera recursos, y ningún ajuste dentro de la aplicación cambia eso. iOS aplica sus propios límites en segundo plano al proveedor del túnel, y el comportamiento documentado difiere de un demonio de escritorio que simplemente sigue ejecutándose. Lea la documentación de la plataforma para el componente en cuestión, no una guía genérica de optimización de batería.
Los dispositivos gestionados añaden otra capa. Una política puede anular un ajuste personal, así que un cambio que parece funcionar revierte en la siguiente actualización de la política. Use el proceso de excepción admitido por la organización si el requisito es real, y anote por qué existe la excepción.
Qué hace el dispositivo después de despertar
La reconexión automática no es lo mismo que bloquear el tráfico durante el hueco. Compruebe ambas cosas: si el túnel vuelve y si una aplicación que intentó enviar durante el hueco salió sin protección. Un cliente que se reconecta en dos segundos pero deja escapar una consulta DNS en el primero tiene la política de fallo equivocada para un dispositivo de trabajo. Pruebe con peticiones inocuas y un destino que usted controle.
La recuperación de la aplicación es la tercera pregunta. Un túnel que vuelve no repara una sesión SSH que ha caducado, y los usuarios suelen informar de esa pérdida de sesión como el fallo de la VPN. Mantenga juntos en el informe el desencadenante, la compilación del cliente y el momento exacto, porque esa combinación separa un ciclo de vida previsible de apagado de pantalla de un servidor que falla con independencia del dispositivo.