OpenVPN: el bind local falla al arrancar: esperar o reintentar

Para un servidor OpenVPN que no arranca, se ofrecen dos soluciones: esperar la dirección o dejar que el servicio reintente hasta que el enlace tenga éxito. Ambas abordan el mismo síntoma con distinto comportamiento ante el fallo. La espera codifica un requisito previo concreto y falla de forma ruidosa cuando falta; el reintento oculta el requisito y sigue intentándolo. Cuál de las dos corresponde a su unidad depende de si esa dirección es una dependencia diseñada o una casualidad de temporización.

Ambas superan a un sleep fijo, que ni espera nada ni informa de qué estaba esperando.

Qué exige realmente la opción local

local nombra la dirección a la que el demonio enlaza su socket, y enlazar a una dirección que aún no existe falla de inmediato con un error sobre la dirección solicitada. Cuando la opción falta, el demonio escucha en todas las direcciones, por eso el mismo perfil funciona en una máquina cuya interfaz aún no ha subido: escucha en todas partes en lugar de en la única dirección que usted nombró. Esa diferencia es todo el fallo, y permanece invisible hasta un reinicio.

El requisito no es que la interfaz esté activa en un sentido general. La dirección debe estar asignada a la interfaz correcta en el momento del enlace, y debe ser la interfaz subyacente y no un túnel que el mismo demonio crearía después. Una comprobación hecha minutos después del inicio de sesión no demuestra nada sobre la secuencia de arranque.

Esperar la dirección o reintentar el enlace

Esperar significa un ExecStartPre que sondea hasta que aparece la dirección, con un número acotado de intentos y una salida distinta de cero cuando se agota el tiempo. Reintentar significa dejar que el proceso principal falle y pedir al gestor de servicios que lo inicie de nuevo, por ejemplo Restart=on-failure con RestartSec=5. El primero informa de un requisito ausente como unidad fallida, mientras que el segundo lo informa como una serie de reinicios que finalmente se detiene, lo cual es más ruidoso en el registro pero sobrevive a una dirección que llega tarde por motivos que no puede predecir.

Prefiera esperar cuando la dirección es una dependencia diseñada, y prefiera reintentar cuando la dirección suele aparecer pero su temporización varía. Combinarlas es razonable: una espera acotada cubre el caso común y una política de reinicio cubre la excepción. Lo que ninguna debería hacer es ejecutarse para siempre, porque una unidad que reintenta indefinidamente oculta una mala configuración en lugar de informarla.

Por qué network-online.target no basta

network-online.target promete lo que la implementación de red activa entiende por en línea, y nada más. Con systemd-networkd, systemd-networkd-wait-online decide cuándo se alcanza ese objetivo, y su noción predeterminada de en línea puede satisfacerse antes de que exista su dirección concreta. Bajo NetworkManager, el servicio wait-online aplica sus propias reglas. Ordenar después del objetivo es una base sólida, no una garantía de que una dirección, una respuesta DNS o un par remoto esté listo.

El mismo razonamiento descarta las alternativas habituales. Una entrada de inicio automático de escritorio espera una sesión de usuario que quizá nunca se abra en un servidor, y un comando cron retrasado añade tiempo transcurrido sin nombrar el recurso cuya aparición esperaba. Ambas pueden parecer exitosas durante meses y luego fallar en el único arranque que importa.

Compruebe el enlace tras un arranque en frío

Verifique con un arranque en frío real en lugar de un reinicio del servicio, porque un reinicio hereda una dirección que la secuencia de arranque tuvo que crear. Tras el arranque, ss -lntp o ss -lunp muestra la dirección local a la que cada oyente se enlazó realmente, y journalctl -b -u openvpn-server@server muestra si el primer intento falló. Compare la dirección enlazada con la del perfil y luego repita la comparación tras una reconexión de red.

Si el perfil nunca necesitó una dirección fija, eliminar local es una simplificación legítima, pero conviértalo en una decisión de seguridad en lugar de una costumbre de diagnóstico.

Ampliar el oyente cambia quién puede alcanzarlo, así que combine ese cambio con la política de cortafuegos que debería haberlo restringido. Un servicio que arranca de forma fiable en todas las interfaces no ha resuelto el problema original; ha trasladado el problema al borde de la red.