Por qué su cliente OpenVPN se queda caído tras un solo tiempo de espera

Lunes por la mañana: el túnel que se levantó el viernes ha desaparecido, la interfaz sigue en la lista y nada en el registro dice que alguien lo notara. El host está en línea, el panel está en verde y todo lo que envió durante el fin de semana salió por la interfaz física. Aquí faltan dos decisiones independientes: una sobre si el proceso del cliente sobrevive a un fallo transitorio y otra sobre si algo por encima suyo vuelve a iniciar el proceso tras su salida. Arreglar solo una deja la otra brecha abierta.

Empiece por lo que la unidad hizo realmente, no por lo que afirma la monitorización. systemctl status openvpn-client@office y journalctl -u openvpn-client@office -n 50 muestran el motivo de salida y la última línea que el cliente escribió antes de irse.

El proceso salió antes de que nadie lo notara

Un cliente que desaparece sin error normalmente salió a propósito. El perfil decide ese comportamiento, no el gestor de servicios: ping-exit termina el proceso en cuanto el par deja de responder, mientras que ping-restart mantiene el proceso y se reconecta dentro de él. Los límites de sesión y los temporizadores de inactividad producen la misma imagen desde fuera: sin túnel y sin alarma.

Las dos directivas ping no pueden aparecer juntas en un solo perfil, así que elija una y anote la decisión. Mire también el servidor, porque su propio ping-exit cierra una sesión pida lo que pida el cliente, y solo el registro del servidor anota quién tomó esa decisión.

Elegir entre ping-exit y ping-restart

Elija ping-restart para un portátil o un sitio remoto que deba curarse solo, y reserve ping-exit para los casos en que un túnel muerto deba detener el proceso para que otra cosa pueda actuar sobre él. Los números importan menos que la relación: ping 10 con ping-restart 60 significa diez segundos de silencio antes de una sonda y sesenta antes del reinicio, lo que es agresivo en un enlace móvil con pérdidas y razonable en uno cableado. Escriba el motivo junto a la línea, porque de lo contrario el siguiente lector asumirá que los valores por defecto fueron deliberados.

Después confirme que lo que salió es realmente el proceso. Una unidad que informa de actividad mientras el túnel está muerto es un fallo distinto, tratado más abajo.

Supervisión que realmente reinicia la unidad

En un host con systemd, el cambio duradero más pequeño es un solo archivo drop-in: Restart=on-failure y RestartSec=10 en /etc/systemd/system/[email protected]/restart.conf. Un drop-in solo se lee cuando systemd recarga sus propias definiciones, así que ejecute systemctl daemon-reload después. Verifique con systemctl show -p Restart -p ExecMainStatus openvpn-client@office en lugar de suponer que el valor llegó. La instancia del nombre del archivo debe ser el perfil que la unidad carga realmente, de modo que un archivo escrito para office no hace nada por openvpn-client@home.

on-failure ignora un caso: una salida limpia con estado cero. Algunas rutas de desmontaje acaban así, por lo que conviene leer el estado registrado en lugar de fiarse de la redacción de una página de manual. Si su cliente se rinde con un cero, necesita Restart=always, y el costo es que un perfil realmente roto vuelve una y otra vez hasta que salta el límite de velocidad de inicio y el registro se llena.

Restart=always también se activa tras una parada deliberada. Use systemctl stop para mantenimiento, y enmascare la unidad si debe permanecer caída mientras trabaja.

Atrapar la fuga mientras el túnel está caído

La supervisión hace volver el túnel; no impide que el tráfico salga mientras el túnel no está. persist-tun mantiene el dispositivo y sus rutas entre reconexiones, lo que es cómodo y abre una ventana. El dispositivo sobrevive, las rutas siguen apuntando a él y los paquetes salen sin protección y sin aviso. Es una decisión de política, no un valor por defecto neutro.

Cuando un host no puede emitir ningún paquete sin protección, solo el cortafuegos puede garantizarlo. Una regla de salida que permite la interfaz del túnel y la dirección del servidor VPN mientras descarta todo lo demás sigue vigente después de que el cliente muera, y nada en la configuración del propio cliente puede filtrar el tráfico que el cliente no transporta.

Pruébelo deteniendo el cliente a propósito. Ejecute systemctl stop openvpn-client@office, luego curl -m 5 https://example.com, que debería fallar en lugar de funcionar por el enlace físico. Un éxito significa que la regla del cortafuegos falta o es demasiado permisiva.

Reconecte, confirme que el túnel vuelve a transportar tráfico y solo entonces añada la comprobación a la monitorización. Sondear ip addr desde cron para un dispositivo tun es la supervisión que falla con más frecuencia, porque con persist-tun el dispositivo sobrevive a la sesión y la sonda informa de salud mientras no se transporta nada.