Por qué una unidad de VPN arranca antes que la red y luego muere

Arranque la máquina, inicie sesión y compruebe que el túnel subió y murió unos segundos después. El perfil estaba bien, el certificado estaba bien, y el único rastro que queda es el registro de ese arranque. Lo que suele ocurrir es una carrera: la unidad arrancó antes de que la máquina tuviera una dirección, y el orden que declaraba no significaba lo que parece. Todo lo que sigue trata de demostrar esa carrera con pruebas y cerrarla correctamente.

El objetivo es un punto de encuentro, no un gestor

network-online.target no tiene ni idea de qué es una red. Es un punto de coordinación que reúne el servicio que debe retrasar el arranque hasta que el enlace sea utilizable, y delega la definición en el gestor de red que sea dueño de la máquina. En la mayoría de equipos de escritorio y servidores eso significa un servicio de espera que entrega NetworkManager o systemd-networkd. No active ninguno y el objetivo no tendrá nada que esperar, así que se completa en el momento en que algo lo arrastre, lo que puede ser mucho antes de que DHCP responda. La línea de ordenación de su unidad era honesta y aun así inútil.

La primera pregunta, por tanto, no es qué declara su unidad. Es si algo en esta máquina está haciendo de verdad la espera.

Lea el último arranque en lugar del archivo de la unidad

Los archivos de unidad describen la intención, y el registro describe lo que ocurrió. Pida solo ese arranque, con marcas de tiempo monótonas para que cada mensaje se sitúe en un mismo reloj. Después busque dos líneas: el momento en que la unidad del túnel empezó a arrancar y el momento en que apareció la dirección o terminó el servicio de espera. Ordene esos dos números y la carrera queda confirmada o descartada.

La vista de dependencias lo corrobora. Si una cadena crítica para la unidad del túnel no contiene ningún servicio de espera, nada en ese camino retrasó el arranque, y el objetivo no hizo el trabajo que usted suponía. Dos vistas, una conclusión.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

Añada la espera, luego el reintento

Use un drop-in en lugar de editar una unidad empaquetada, para que una actualización del paquete no descarte el cambio en silencio. Importan dos directivas: la unidad debe ir ordenada después del objetivo y debe atraer el objetivo a la misma transacción. El orden por sí solo no invoca el objetivo; el deseo sí.

La unidad empaquetada del cliente OpenVPN ya lleva ambas. Las unidades escritas a mano suelen llevar una o ninguna, lo que vale la pena comprobar antes de añadir nada.

[Service]
Restart=on-failure
RestartSec=15

Por qué un sueño fijo es una trampa

Un sueño en ExecStartPre se siente como una corrección de orden y se comporta como un retraso con pasos extra. Frena cada arranque, incluidos los que eran sanos, y aun así pierde cuando el enlace tarda más que el número que eligió.

Peor aún, oculta si el servicio de espera funciona, así que el siguiente fallo se presenta como un problema completamente nuevo en lugar del mismo con otro momento. Un retraso corto de reinicio es el mejor instrumento: no cuesta nada en un arranque sano y convierte una carrera perdida en otro intento. Mantenga el intervalo modesto y deje que la unidad tenga éxito. Si se reinicia para siempre, el perfil está roto y ninguna cantidad de reintentos lo cambiará, así que lea el registro en lugar de subir el intervalo.

Cuando el orden es correcto y los nombres siguen fallando

Una unidad activa con una ruta de túnel significa que la ordenación hizo su trabajo y que el fallo restante está una capa más arriba. La forma habitual es un ajuste de resolución que aplica el script up del túnel antes de que el enlace o el resolutor estuvieran listos para conservarlo. Compare el estado del resolutor durante el fallo con el estado tras reiniciar la unidad del túnel.

Si el reinicio arregla las consultas, tiene un defecto de ordenación de arranque y no un servidor DNS equivocado, y esos dos necesitan arreglos distintos. Después demuestre todo con un arranque en frío en lugar de reiniciar el servicio, porque reiniciar corre contra una red que ya está levantada y ocultará justo el defecto que persigue. Repítalo con el enlace deliberadamente lento y trate una unidad que solo funciona cuando la red es rápida como todavía rota.