Que OpenVPN arranque antes que la red no es un fallo

Usted inicia el cliente al arrancar, la unidad informa de que está activa y el túnel no está. La conclusión natural es que el servicio no arrancó, y la solución natural es volver a iniciarlo. Ambas cosas son lo bastante a menudo erróneas como para merecer una regla: un cliente en marcha que reintenta se parece exactamente a uno roto desde fuera. La diferencia está en lo que hace el proceso, no en el estado de la unidad.

Mito: un servicio iniciado significa un túnel que funciona

Una unidad activa demuestra que el proceso se lanzó y no ha salido. No demuestra que el perfil se cargara, que el certificado se aceptara ni que el otro extremo respondiera. Un cliente empaquetado puede quedarse minutos en un bucle de reintentos mientras systemd no informa más que de éxito. Esa brecha entre estado y comportamiento es todo el asunto.

El caso contrario es igual de común. El proceso puede haber salido tras no poder leer una clave, y la unidad informa entonces de un estado fallido que no dice por qué. Ambos estados necesitan el registro para distinguirse.

Lea el registro de la instancia en lugar del estado de la unidad. La línea del motivo está en el registro, no en la etiqueta de estado.

Mito: los ajustes de reintento cubren todos los fallos

La resolución de nombres y los reintentos de transporte son controles separados con valores predeterminados separados. resolv-retry gobierna las búsquedas repetidas de un nombre de host remoto, y el valor documentado sigue intentándolo indefinidamente. connect-retry fija el intervalo entre intentos, mientras que connect-retry-max puede limitar cuántas veces se prueba cada entrada remota. Compruebe qué etapa nombra el registro antes de cambiar cualquiera de ellos.

Nada de eso se aplica a un perfil malformado, una clave privada ilegible o una cuenta rechazada. Estos necesitan una corrección, y un cliente que los reintenta no avanza.

Reintentar para siempre un certificado no aprobado no es motivo para quitar la verificación. Es motivo para leer el error.

Mito: un lanzador basta, así que añada otro

Una conexión ya gestionada por NetworkManager o por una unidad empaquetada no necesita un segundo lanzador conectado. Dos procesos que compiten por las mismas rutas producen interfaces duplicadas, registros confusos y un túnel que oscila por motivos que nadie ve. La segunda copia suele llegar como solución provisional porque la primera es lenta.

Decida qué componente posee el túnel antes de añadir nada. Después retire el otro lanzador en lugar de desactivarlo y esperar.

El propietario también determina de dónde vienen los reintentos y las credenciales, por eso esta decisión va antes de cualquier ajuste. La propiedad va primero exactamente por ese motivo.

Qué necesita realmente un orden

El orden puede esperar a una dirección configurada, y eso es todo lo que garantiza. network-online.target retrasa la activación hasta que el gestor considera que la red está levantada, y la definición de levantada depende del gestor. No dice nada sobre si se resuelve el nombre de host de la VPN, si el oyente responde o si un portal cautivo ha admitido el dispositivo.

Lea la unidad instalada y cualquier drop-in antes de añadir dependencias. Un After= amplio en cada servicio de red retrasa el arranque sin establecer la conexión que realmente necesita.

Ordene la dependencia que puede probar y compruebe todo lo demás con una sonda de disponibilidad. Una sonda que abre el túnel supera a un temporizador que adivina.

Qué ocurre después de que el túnel suba por primera vez

El arranque es un suceso entre muchos. El enlace de acceso cambia, una sesión de portal caduca, el par se reinicia. Distinga una reconexión interna de una salida de proceso que gestiona el gestor de servicios, porque ambas tienen propietarios distintos y dejan pruebas distintas.

La autenticación interactiva limita la recuperación desatendida. Una unidad en segundo plano no desbloquea un llavero de escritorio ni responde a un desafío MFA, así que siga el arreglo de credenciales aprobado para el contexto del servicio.

Decida por separado qué pueden hacer las aplicaciones mientras el túnel está caído. El reintento restaura una conexión, mientras que una política de bloqueo decide si se permite tráfico directo en ese hueco.