OpenVPN na inicialização do Ubuntu: NetworkManager ou systemd?

A maioria dos guias apresenta a escolha como cosmética: ou deixa o NetworkManager levantar o túnel, ou ativa uma instância systemd e fica por aí. Os dois percursos diferem numa coisa que decide o resultado numa máquina sem ecrã, e não tem nada a ver com qual ferramenta é mais recente. O NetworkManager desbloqueia segredos através de uma sessão; uma instância systemd não tem sessão para desbloquear. Escolha a que cujo tratamento dos segredos se adeque à máquina à sua frente.

Tudo o resto, da instalação de rotas ao comportamento de reconexão, decorre dessa primeira decisão.

O porta-chaves é a diferença de que ninguém fala

Quando o NetworkManager possui um perfil de VPN, a palavra-passe pode viver no porta-chaves de início de sessão, que é desbloqueado quando um utilizador inicia sessão. Isso funciona bem num portátil: a pessoa está presente, o porta-chaves abre, o túnel sobe. Num servidor que arranca sem supervisão não há ninguém para desbloquear nada, por isso o perfil espera por um segredo que nunca chega. A ligação parece configurada e nunca é ativada.

A instância systemd evita esse problema lendo um ficheiro de credenciais do disco, o que faz do ficheiro aquilo que protege. chmod 400 mais a propriedade por root é o mínimo, e o ficheiro deve ficar fora das cópias de segurança e dos modelos de imagem que não controla.

Associar a VPN a uma ligação não garante o arranque

Em nm-connection-editor, selecione a ligação com fios ou sem fios em vez da VPN, abra o separador General, marque a opção de ligar automaticamente a uma VPN e dê um nome ao perfil. O NetworkManager ativa então a VPN como ligação secundária quando a primária atinge o estado ligado. Isso é uma dependência, não uma regra de firewall. Os pacotes ainda podem sair nos segundos antes de o túnel subir, e um segredo guardado que não se desbloqueia deixa a máquina online sem ele.

Se o requisito é que nada saia sem o túnel, diga-o e construa um interruptor de emergência, porque esta definição não o fornece. Teste também a suspensão e a retoma, já que a ligação secundária é reavaliada no regresso.

A instância systemd precisa de um nome de ficheiro que corresponda

Coloque o perfil no diretório de cliente esperado pelo pacote, como /etc/openvpn/client/office.conf, e referencie lá dentro o ficheiro de credenciais com auth-user-pass office.cred. O nome da instância é o nome do ficheiro sem o sufixo, por isso openvpn-client@office lê office.conf. Ative-a com sudo systemctl enable --now openvpn-client@office e confirme a correspondência com systemctl cat openvpn-client@office em vez de confiar num exemplo de um blog.

Os caminhos dentro do perfil são resolvidos relativamente ao diretório de trabalho da unidade, e não ao próprio perfil, por isso uma linha relativa ca ou auth-user-pass pode falhar no arranque embora funcione quando a testa manualmente. Use caminhos absolutos para tudo o que a unidade tenha de encontrar. Depois leia journalctl -u openvpn-client@office -b após um arranque real; uma unidade que se declara ativa sem túnel costuma indicar um ficheiro em falta nesse registo.

Os pacotes mais antigos trazem outro nome de modelo, por isso systemctl list-unit-files 'openvpn*' decide qual existe neste anfitrião.

O comportamento de reconexão é uma decisão separada

Um perfil com ping-restart reconstrói o túnel depois de cair, e uma unidade com uma diretiva de reinício faz algo semelhante ao nível do serviço. São políticas que escolhe, não predefinições que herda. Se a ligação só deve subir a pedido, remova deliberadamente o comportamento de reinício e registe porquê. Se a unidade arranca antes de a rede estar utilizável, precisa de uma política de novas tentativas, porque uma tentativa falhada no arranque não se repete sozinha.

Parar é igualmente literal: sudo systemctl disable --now openvpn-client@office para a instância em execução e remove a ligação de arranque. Desativar sozinho deixa o túnel a funcionar até ao próximo reinício, o que surpreende quem testa desativando e vê a interface continuar no ar.

Reinicie e depois verifique quatro coisas por ordem

Reiniciar o serviço testa o serviço; reiniciar a máquina testa o percurso de arranque. Após o reinício, confirme que a unidade subiu, depois que existe uma rota para a sub-rede remota, depois que endereço a máquina apresenta à internet e, por fim, que os nomes se resolvem através do túnel. Essas quatro verificações falham nessa ordem quando algo está errado, o que torna a primeira falha a útil.

Uma unidade ativa sem rota costuma significar que o perfil se ligou mas o servidor não empurrou qualquer rota, ou que a rota foi instalada numa interface que depois desapareceu. Uma rota sem resolução de nomes funcional aponta para a configuração de DNS e não para o próprio túnel.

Decida antecipadamente o que deve acontecer quando o túnel não consegue subir. Recuar para a conetividade simples é uma política, e deve ser escrita em vez de ficar ao critério do gestor que arrancou primeiro.