La VPN se cae cuando la pantalla se apaga: ¿bloqueo, atenuación o suspensión?

Cuando alguien dice que la VPN murió cuando la pantalla se oscureció, la primera pregunta útil es cuál de los tres sucesos ocurrió en realidad: se bloqueó la sesión, se apagó el panel o todo el equipo entró en reposo. Son mecanismos separados con temporizadores separados, y solo uno de ellos puede impedir por completo que un proceso se planifique. Recorra las comprobaciones siguientes en orden. Deténgase en la primera que responda a la pregunta, porque cada comprobación posterior responde a otra cosa.

Primera comprobación: separe el bloqueo de la atenuación y del reposo

El bloqueo cambia quién puede usar la sesión; el compositor sigue dibujando, la pila de red sigue funcionando y el cliente de la VPN no se entera. La atenuación de la pantalla apaga el panel tras un intervalo de inactividad y deja el equipo completamente despierto. La suspensión detiene las CPU, lo que significa que ningún proceso de espacio de usuario se planifica, así que ningún keepalive puede dispararse por corto que sea el intervalo.

Esa tabla es la razón de que «la pantalla se oscureció» no sea un diagnóstico. Un escritorio configurado para atenuarse a los cinco minutos y suspenderse a los treinta mostrará una pantalla oscura en el minuto seis con un túnel perfectamente sano. El fallo en el minuto treinta es otro suceso con otra solución, y ambos se ven iguales desde el otro lado de la habitación.

Segunda comprobación: ponga los sucesos de energía y red en una sola línea temporal

Lea el registro de una ventana acotada en lugar de todo el arranque, e incluya tanto el gestor de inicio de sesión como el propietario de la conexión:

journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list

El primer comando muestra las peticiones de reposo, la reanudación y las transiciones de red que las siguieron. El segundo muestra qué mantiene actualmente un bloqueo inhibidor, lo que le dice si algo bloquea el reposo a propósito y qué programa es. Ajuste los nombres de unidad si el propietario de su conexión no es NetworkManager, y recuerde que leer la unidad de otro usuario o el registro del sistema depende de la política local.

Una línea ausente no es un resultado negativo. Si el registro de la unidad seleccionada no es visible para su cuenta, la ausencia de un registro de reposo no demuestra nada, y concluir «nunca durmió» a partir de un filtro vacío es como la gente acaba ajustando keepalives durante una semana.

Tercera comprobación: si se suspendió, decida si era lo previsto

Una vez que una transición de reposo está en la línea temporal, la pregunta cambia de por qué se rompió la VPN a si el equipo debería haber dormido. En un portátil la respuesta suele ser sí, y el corte del túnel es un comportamiento esperado del que el cliente debe recuperarse al reanudar. En una estación de trabajo que debe seguir siendo accesible, la política de reposo es lo que hay que cambiar. Decidir a cuál de esos dos equipos está mirando requiere una pregunta, y no es una pregunta que el registro pueda responder por usted.

Cámbielo mediante los controles que pertenecen a la sesión iniciada, o mediante un mecanismo avalado por el administrador si el requisito es para todo el equipo. Editar un ajuste del gestor de pantalla mientras tiene la sesión iniciada con otra cuenta no es la misma acción y parecerá que funcionó hasta que empiece la sesión siguiente. Desactivar por completo la gestión de energía es una primera reacción amplia que cuesta vida de batería y oculta la verdadera pregunta de política.

Cuarta comprobación: si siguió despierto, mire la red y el cliente

Un equipo despierto que perdió su túnel tiene una de tres historias: cayó la red de acceso, el cliente de la VPN se detuvo o se reinició, o el lado del servidor dejó expirar la asociación mientras el cliente seguía creyendo que estaba conectado. Compare las marcas de tiempo del suceso de enlace subyacente con el suceso del túnel, y sea preciso sobre cuál llegó primero.

Luego pruebe la ruta de recuperación por separado de la sesión original. Una petición nueva a través del túnel recuperado puede tener éxito mientras la sesión de aplicación de larga duración abierta antes del corte sigue rota, porque la aplicación mantiene un socket obsoleto o una dirección en caché. Eso es un problema de la aplicación, no una prueba de que el túnel no haya vuelto.

Qué contiene un informe útil

Escriba la secuencia con marcas de tiempo y propietarios: cuándo se bloqueó la sesión, cuándo se atenuó la pantalla, si se registró una petición de reposo, cuándo cayó y volvió el enlace, cuándo cambió de estado el túnel y qué hizo realmente la aplicación. Cada elemento tiene un propietario, así que cada elemento puede entregarse a la persona correcta en lugar de convertirse en una queja general sobre Linux.

Si falta cualquiera de esas filas, eso es lo siguiente que hay que medir y no lo siguiente que hay que cambiar. Una línea temporal con un hueco es más informativa que un cambio de ajustes hecho por corazonada.