OpenVPN ao arrincar en Ubuntu: NetworkManager ou systemd?

A maioría das guías presentan a elección como algo cosmético: ou deixas que NetworkManager levante o túnel, ou activas unha instancia de systemd e xa está. Os dous camiños difiren nunha cousa que decide o resultado nunha máquina sen pantalla, e non ten nada que ver con que ferramenta sexa máis nova. NetworkManager desbloquea segredos mediante unha sesión; unha instancia de systemd non ten sesión que desbloquear. Escolla a que o seu tratamento dos segredos encaixe coa máquina que ten diante.

Todo o demais, desde a instalación de rutas ata o comportamento de reconexión, derívase desa primeira decisión.

O chaveiro é a diferenza que ninguén menciona

Cando NetworkManager posúe un perfil de VPN, o contrasinal pode vivir no chaveiro de inicio de sesión, que se desbloquea cando un usuario inicia sesión. Iso funciona ben nun portátil: a persoa está presente, o chaveiro ábrese, o túnel sobe. Nun servidor que arrinca sen supervisión non hai ninguén para desbloquear nada, así que o perfil espera un segredo que nunca chega. A conexión parece configurada e nunca se activa.

A instancia de systemd evita ese problema lendo un ficheiro de credenciais do disco, o que converte o ficheiro no que vostede protexe. chmod 400 máis a propiedade de root é o mínimo, e o ficheiro debería quedar fóra das copias de seguridade e dos modelos de imaxe que vostede non controle.

Anexar a VPN a unha conexión non garante o arrinque

En nm-connection-editor, seleccione a conexión por cable ou sen fíos en lugar da VPN, abra a pestana General, marque a opción de conectarse automaticamente a unha VPN e poña nome ao perfil. NetworkManager entón activa a VPN como conexión secundaria cando a primaria alcanza un estado conectado. Iso é unha dependencia, non unha regra de devasas. Os paquetes aínda poden saír durante os segundos previos a que o túnel estea levantado, e un segredo gardado que non se desbloquea deixa a máquina en liña sen el.

Se o requisito é que nada saia sen o túnel, dígao e constrúa un interruptor de emerxencia, porque este axuste non lle dará un. Probe tamén a suspensión e a reanudación, xa que a conexión secundaria se reevalúa ao volver.

A instancia de systemd necesita un nome de ficheiro que coincida

Coloque o perfil no directorio de cliente que espera o paquete, como /etc/openvpn/client/office.conf, e faga referencia desde dentro ao ficheiro de credenciais con auth-user-pass office.cred. O nome da instancia é o nome do ficheiro sen o sufixo, así que openvpn-client@office le office.conf. Actívea con sudo systemctl enable --now openvpn-client@office e confirme a correspondencia con systemctl cat openvpn-client@office en lugar de confiar nun exemplo dun blog.

As rutas dentro do perfil resólvense respecto do directorio de traballo da unidade, non respecto do propio perfil, así que unha liña relativa ca ou auth-user-pass pode fallar ao arrincar mentres funciona cando a proba a man. Use rutas absolutas para todo o que a unidade deba atopar. Logo lea journalctl -u openvpn-client@office -b tras un arrinque real; unha unidade que informa estar activa sen túnel adoita nomear un ficheiro ausente nese rexistro.

Os paquetes máis antigos traen outro nome de modelo, así que systemctl list-unit-files 'openvpn*' decide cal existe neste equipo.

O comportamento de reconexión é unha decisión aparte

Un perfil con ping-restart reconstrúe o túnel despois de caer, e unha unidade cunha directiva de reinicio fai algo similar a nivel de servizo. Son políticas que vostede escolle, non valores por defecto que herda. Se a conexión só debe subir a demanda, quite deliberadamente o comportamento de reinicio e escriba por que. Se a unidade arrinca antes de que a rede sexa utilizábel, necesita unha política de reintentos, porque un intento fallido ao arrincar non se repite só.

Deter é igual de literal: sudo systemctl disable --now openvpn-client@office detén a instancia en execución e elimina a ligazón de arrinque. Desactivar por si só deixa o túnel funcionando ata o seguinte reinicio, o que sorprende a calquera que probe desactivando e mirando como a interface segue levantada.

Reinicie e despois comprobe catro cousas en orde

Reiniciar o servizo proba o servizo; reiniciar a máquina proba o camiño de arrinque. Tras o reinicio, confirme que a unidade subiu, despois que existe unha ruta para a subrede remota, despois que enderezo presenta a máquina a internet e por último que os nomes se resolven a través do túnel. Esas catro comprobacións fallan nesa orde cando algo vai mal, o que fai que o primeiro fallo sexa o útil.

Unha unidade activa sen ruta adoita significar que o perfil se conectou pero o servidor non empurrou ningunha ruta, ou que a ruta se instalou nunha interface que despois desapareceu. Unha ruta sen busca de nomes funcional apunta á configuración de DNS e non ao túnel en si.

Decida de antemán que debe pasar cando o túnel non poida subir. Volver á conectividade simple é unha política, e debería escribirse en lugar de deixala ao xestor que arrincase primeiro.