Reiniciar un servicio en OpenVPN up: los hooks superan a tun0.device

Conectar un servicio dependiente a tun0.device parece suscribirse al túnel, y no lo es. Una unidad de dispositivo refleja que la interfaz existe, lo que puede seguir siendo cierto durante una conexión fallida y la reconexión que la sigue. Entonces el servicio actúa en el momento equivocado, o nunca, según si la interfaz desapareció mientras tanto. El hook que describe el evento que realmente te importa es el que llama OpenVPN, no el que infiere systemd.

Decide qué condición necesita el servicio antes de elegir el disparador, porque los tres candidatos no son intercambiables.

Qué sigue realmente la unidad de dispositivo

systemd crea una unidad de dispositivo a partir de la visión del kernel sobre una interfaz de red, así que tun0.device se activa cuando aparece la interfaz y se desactiva cuando se elimina. Con persist-tun, un reinicio suave mantiene la interfaz en su sitio, así que la unidad nunca oscila y nada vinculado a ella se dispara. Incluso sin persistencia, la unidad no dice nada sobre rutas, DNS ni si el extremo remoto responde.

Eso la convierte en un mal sustituto de 'la VPN está lista'. Un oyente que solo necesita la dirección local puede conformarse con la existencia de la interfaz, mientras que un servicio que llama a una aplicación en la red remota necesita rutas y accesibilidad, que la unidad de dispositivo no puede expresar.

up, route-up y up-restart significan cosas distintas

up se ejecuta después de que se abra el dispositivo TUN/TAP y se configure la interfaz, que es el momento adecuado para un oyente que vincula la dirección asignada. route-up se ejecuta después de instalar las rutas, sujeto a cualquier retardo de ruta configurado, y encaja con un trabajo que necesita la etapa de rutas completa. Ninguno de los dos demuestra que la aplicación remota responda. Elegir entre ellos es una cuestión de qué necesita el servicio, no de qué hook suena más terminado.

Con persist-tun, los reinicios reutilizan el dispositivo, así que up no se ejecuta de nuevo a menos que se establezca up-restart. Esa opción habilita el script up para el ciclo de vida de reinicio documentado, y su entorno es reducido en comparación con un primer arranque. Un script que asume el entorno completo funciona en la primera conexión y falla en la siguiente.

Enviar la acción sin esperar por ella

Un hook que llama a systemctl restart de forma síncrona puede bloquearse contra una unidad cuyo orden espera el túnel. systemctl --no-block try-restart vpn-dependent.service pone el trabajo en cola y vuelve, lo que impide que el hook bloquee la conexión a la que reaccionaba. try-restart actúa solo sobre una unidad en ejecución, mientras que restart también inicia una inactiva; elige a propósito, no por costumbre.

Poner en cola no es verificar. El hook devuelve éxito en cuanto se acepta el trabajo, así que la comprobación debe ocurrir en el journal de la unidad objetivo o en su estado real de escucha.

La política de reinicio vive en la unidad, no en el hook

Una unidad oneshot con RemainAfterExit=yes permanece activa después de que su comando salga, y una segunda solicitud de inicio no hace nada porque systemd la considera ya iniciada. Eso es una propiedad con la que hay que diseñar, no un defecto que se sortee con llamadas de inicio repetidas. Si la acción debe ejecutarse por conexión, la unidad necesita una forma que lo permita.

After= ordena unidades y BindsTo= ata vidas, pero ninguno de los dos significa 'reinicia esto cada vez que la VPN se reconecte'. Una unidad vinculada al túnel se detiene cuando el túnel se detiene; no se reinicia sola cuando el túnel vuelve, a menos que algo la inicie de nuevo.

Prueba tres reconexiones, no una

El arranque en frío, un reinicio completo del cliente y una reconexión suave ejercitan cada uno un camino distinto. La reconexión suave es la que expone un up-restart ausente, un entorno reducido o una unidad de dispositivo que nunca se desactivó. Ejecuta las tres y confirma ambas direcciones: el servicio actúa cuando el túnel sube, y no se reinicia ante cambios de enlace no relacionados como un roaming de Wi-Fi.

Mantén una ruta de recuperación independiente cuando el servicio dependiente lleva tu propio acceso administrativo. Un hook que reinicia aquello por lo que estás conectado es un cambio que puede dejarte fuera.