OpenVPN al arrancar en Ubuntu: ¿NetworkManager o systemd?

La mayoría de las guías presentan la elección como algo cosmético: o deja que NetworkManager levante el túnel, o habilita una instancia de systemd y ya está. Los dos caminos difieren en una cosa que decide el resultado en una máquina sin pantalla, y no tiene nada que ver con qué herramienta sea más nueva. NetworkManager desbloquea secretos mediante una sesión; una instancia de systemd no tiene sesión que desbloquear. Elija la que cuyo manejo de secretos encaje con la máquina que tiene delante.

Todo lo demás, desde la instalación de rutas hasta el comportamiento de reconexión, se deriva de esa primera decisión.

El llavero es la diferencia que nadie menciona

Cuando NetworkManager posee un perfil de VPN, la contraseña puede vivir en el llavero de inicio de sesión, que se desbloquea cuando un usuario inicia sesión. Eso funciona bien en un portátil: la persona está presente, el llavero se abre, el túnel sube. En un servidor que arranca sin supervisión no hay nadie que desbloquee nada, así que el perfil espera un secreto que nunca llega. La conexión parece configurada y nunca se activa.

La instancia de systemd evita ese problema leyendo un archivo de credenciales del disco, lo que convierte el archivo en lo que usted protege. chmod 400 más la propiedad de root es el mínimo, y el archivo debería quedar fuera de copias de seguridad y plantillas de imagen que usted no controle.

Adjuntar la VPN a una conexión no garantiza el arranque

En nm-connection-editor, seleccione la conexión por cable o inalámbrica en lugar de la VPN, abra la pestaña General, marque la opción de conectarse automáticamente a una VPN y ponga nombre al perfil. NetworkManager entonces activa la VPN como conexión secundaria cuando la primaria alcanza un estado conectado. Eso es una dependencia, no una regla de cortafuegos. Los paquetes todavía pueden salir durante los segundos previos a que el túnel esté levantado, y un secreto guardado que no se desbloquea deja la máquina en línea sin él.

Si el requisito es que nada salga sin el túnel, dígalo y construya un interruptor de emergencia, porque este ajuste no se lo dará. Pruebe también la suspensión y la reanudación, ya que la conexión secundaria se reevalúa al volver.

La instancia de systemd necesita un nombre de archivo que coincida

Coloque el perfil en el directorio de cliente que espera el paquete, como /etc/openvpn/client/office.conf, y haga referencia desde dentro al archivo de credenciales con auth-user-pass office.cred. El nombre de la instancia es el nombre del archivo sin el sufijo, así que openvpn-client@office lee office.conf. Actívela con sudo systemctl enable --now openvpn-client@office y confirme la correspondencia con systemctl cat openvpn-client@office en lugar de fiarse de un ejemplo de un blog.

Las rutas dentro del perfil se resuelven respecto al directorio de trabajo de la unidad, no respecto al propio perfil, así que una línea relativa ca o auth-user-pass puede fallar al arrancar mientras funciona cuando la prueba a mano. Use rutas absolutas para todo lo que la unidad deba encontrar. Luego lea journalctl -u openvpn-client@office -b tras un arranque real; una unidad que informa estar activa sin túnel suele nombrar un archivo ausente en ese registro.

Los paquetes más antiguos traen otro nombre de plantilla, así que systemctl list-unit-files 'openvpn*' decide cuál existe en este equipo.

El comportamiento de reconexión es una decisión aparte

Un perfil con ping-restart reconstruye el túnel después de caer, y una unidad con una directiva de reinicio hace algo similar a nivel de servicio. Son políticas que usted elige, no valores por defecto que hereda. Si la conexión solo debe subir a demanda, quite deliberadamente el comportamiento de reinicio y escriba por qué. Si la unidad arranca antes de que la red sea utilizable, necesita una política de reintentos, porque un intento fallido al arrancar no se repite solo.

Detener es igual de literal: sudo systemctl disable --now openvpn-client@office detiene la instancia en ejecución y elimina el enlace de arranque. Desactivar por sí solo deja el túnel funcionando hasta el siguiente reinicio, lo que sorprende a cualquiera que pruebe desactivando y mirando cómo la interfaz sigue levantada.

Reinicie y luego compruebe cuatro cosas en orden

Reiniciar el servicio prueba el servicio; reiniciar la máquina prueba la ruta de arranque. Tras el reinicio, confirme que la unidad subió, luego que existe una ruta para la subred remota, luego qué dirección presenta la máquina a internet y por último que los nombres se resuelven a través del túnel. Esas cuatro comprobaciones fallan en ese orden cuando algo va mal, lo que hace que el primer fallo sea el útil.

Una unidad activa sin ruta suele significar que el perfil se conectó pero el servidor no empujó ninguna ruta, o que la ruta se instaló en una interfaz que después desapareció. Una ruta sin búsqueda de nombres funcional apunta a la configuración de DNS y no al túnel en sí.

Decida de antemano qué debe pasar cuando el túnel no pueda subir. Volver a la conectividad simple es una política, y debería escribirse en lugar de dejarla al gestor que haya arrancado primero.