¿Por qué muere OpenVPN cuando el portátil despierta?

Suspende el equipo, reanúdalo y después comprueba tres cosas en este orden antes de tocar ninguna configuración: si tun0 aún existe, si la ruta hacia una dirección interna todavía lo elige y si el servidor todavía lista este peer. Un dispositivo que sobrevive a la suspensión mientras la ruta apunta a otra parte es un resto, no un túnel. Cuando la ruta es correcta y el tráfico muere igualmente, la avería está por encima del túnel y reiniciar el cliente no la cambiará. Automatizar un reinicio solo tiene sentido después de que una prueba manual haya mostrado cuál de esos tres casos tienes.

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

Reproduce la reanudación antes de automatizarla

La suspensión termina la sesión cifrada más a menudo de lo que elimina el dispositivo. El flujo UDP que mantenía vivo el túnel se detiene, el servidor puede descartar el peer y el cliente o bien lo nota y se reconecta o bien conserva una interfaz sin nada detrás. Una comprobación de la interfaz por sí sola demuestra poco, porque un dispositivo obsoleto se ve exactamente igual que uno que funciona hasta que los paquetes tienen que atravesarlo. Ejecuta la consulta de ruta más una petición real a través del túnel y luego lee el registro alrededor del momento de la reanudación.

Si el cliente vuelve solo, un hook añade agitación en lugar de fiabilidad. Si nunca se recupera, la automatización es la solución honesta.

Dónde vive realmente un hook de suspensión de systemd

Muchas guías antiguas apuntan a /etc/pm/sleep.d, un directorio propiedad de pm-utils que una suspensión basada en systemd nunca consulta. systemd lee los hooks de /usr/lib/systemd/system-sleep/ y /etc/systemd/system-sleep/, pasando primero la fase y después la operación, así que pre y post son los únicos valores sobre los que un hook se ramifica. Mantén la copia local bajo /etc en lugar de editar un archivo empaquetado y recuerda que el script se ejecuta como root en mitad de la transición, así que debe volver rápido.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart solo toca una unidad cuando ya está activa, así que un túnel que detuviste a propósito sigue detenido durante la reanudación. --no-block evita que el hook espere mientras el cliente negocia, lo que importa cuando la red aún no ha subido. Juntos, los dos indicadores significan un hook que falla en silencio en lugar de retener toda la secuencia de reanudación. Cuando la unidad ya está parada no ocurre absolutamente nada, que es exactamente el resultado que quieres ahí.

Recupera el servicio, deja tun0 en paz

Bajar tun0 a mano deja al demonio supervisando una interfaz que ya no posee, y el siguiente cambio de estado produce errores confusos. Apunta al servicio o a su perfil de conexión en lugar de a la interfaz; comprueba primero el nombre exacto de la unidad, porque los paquetes de distribución, OpenVPN 3 y NetworkManager eligen nombres distintos. Un perfil de NetworkManager vuelve cuando se recicla esa conexión, así que la unidad de systemd no es el objetivo ahí. Sea cual sea el mecanismo, debería ser la misma acción que verificaste a mano.

Un reinicio reinstala las rutas que el cliente empujó al conectarse. La mayoría de reanudaciones quieren eso. Una máquina donde añadiste rutas propias no, así que vuelve a comprobarlas en lugar de suponer que la recuperación las restauró, y escríbelas donde la siguiente reanudación pueda encontrarlas.

Gestiona el momento que no puedes controlar

La asociación inalámbrica y DHCP a menudo terminan después de que el hook se haya ejecutado, así que un reinicio puede fallar mientras todavía no existe camino al servidor. Espera brevemente esa dirección, reintenta una vez y registra el resultado.

La resolución de nombres es una carrera aparte, porque la pila de red del escritorio puede restaurar el DNS después de que el túnel ya esté arriba. Prueba las consultas por separado con resolvectl query internal.example en lugar de deducirlas de una ruta funcional. Un túnel que enruta correctamente y no resuelve nada es un problema de DNS, no un problema del hook.

Mantén visible la decisión del hook escribiendo la fase, el nombre de la unidad y el resultado en el registro. Anota en las notas de la máquina qué prueba de reanudación ejecutaste, para que una recuperación funcional se distinga de una afortunada. Elige la acción menos disruptiva que devuelva el servicio y deja que un cliente que se recupera solo lo haga. Un reinicio completo descarta las sesiones en curso, que es un coste real en un portátil que se reanuda varias veces al día.