Systemd ou NetworkManager: quem inicia a VPN no arranque?
Três mecanismos conseguem levantar o mesmo perfil de Ubuntu, cada um com um gatilho diferente. Compare-os, mantenha um único proprietário e retire o duplicado.
Duas máquinas Ubuntu da mesma imagem, um perfil de VPN, resultados opostos ao iniciar sessão: numa o túnel já está ativo antes de o ambiente gráfico aparecer, na outra nunca sobe. O perfil não é a variável aqui. O que difere é qual de três componentes recebeu ordem para o iniciar, e esses três não partilham um interruptor.
Compará-los lado a lado é mais rápido do que adivinhar. Cada um falha de forma reconhecível, e é isso que torna a comparação útil.
Três iniciadores com três gatilhos diferentes
O serviço openvpn empacotado é a via mais antiga. O seu script de init lê uma lista de arranque automático de /etc/default/openvpn. Se essa lista estiver comentada ou vazia, o script inicia todas as configurações que encontra nesse diretório em vez da única que acrescentou. Um ficheiro acrescentado para um túnel pode levantar vários sem aviso.
| Starter | What triggers it | Typical failure |
|---|---|---|
| Init script and templated units | Boot, plus anything in the autostart list | Starts every config, not the one you meant |
| NetworkManager secondary | Activation of the base Wi-Fi or Ethernet profile | Nothing happens until that base link comes up |
| Hand-written unit or wrapper | Whatever its WantedBy and ExecStart say | Runs a different binary or environment than your shell |
A segunda linha é a que as pessoas configuram mal. O NetworkManager detém o perfil importado e irá iniciá-lo, mas apenas como secundário de outra ligação, o que significa que o gatilho pertence à ligação de rede e não à VPN.
Compare o custo de configuração e o alcance
A via do script de init custa uma linha e cobre todas as configurações da máquina. Isso serve para um router e está errado para um portátil que se liga a redes diferentes. A via do NetworkManager custa uma pesquisa de UUID e liga o túnel a uma ligação base. Sobe na Wi-Fi do escritório e fica em baixo numa rede de hotel.
Uma unit escrita à mão custa mais e compra o máximo controlo, incluindo a ordenação face a outros serviços. O alcance é o fator decisivo. Se a máquina tem uma rede e um túnel, o serviço empacotado é honesto e previsível. Se o túnel deve seguir uma rede Wi-Fi concreta, o secundário é o único dos três que exprime essa condição sem scripting adicional.
Escolha um proprietário e remova os outros
Um perfil iniciado por dois proprietários produz um timing que muda entre arranques, o que é pior do que qualquer dos mecanismos isolado. Escolha o proprietário e depois desative a via concorrente de propósito, não por acidente.
# who is configured to start something?
grep -v '^#' /etc/default/openvpn
systemctl list-units 'openvpn*'
nmcli -g connection.secondaries connection show 'Work Wi-Fi'
# NetworkManager: attach the tunnel to the base link by UUID
TUNNEL=$(nmcli -g UUID connection show 'Corp Tunnel')
nmcli connection modify 'Work Wi-Fi' +connection.secondaries "$TUNNEL"
Se a via retirada for a empacotada, faça-o pela ordem correta: coloque AUTOSTART em none, execute systemctl daemon-reload para que as units geradas recolham a nova lista e depois desative a instância de modelo de que já não precisa. Saltar o recarregamento deixa as units antigas ativas, e parece que a alteração não teve efeito nenhum.
Uma paragem que fica pendurada é um problema à parte com uma resposta limitada. TimeoutStopSec limita quanto tempo o systemd espera antes de enviar SIGKILL. Um ficheiro drop-in é o sítio certo para o definir, porque editar a unit empacotada perde a alteração na atualização seguinte.
Verifique o que realmente arrancou
Reinicie e leia as provas em vez de confiar no ficheiro de configuração. A unit dona do túnel mostrará um estado ativo e um registo de início coerente com o arranque, e a interface de VPN existirá antes de iniciar sessão.
systemctl is-enabled openvpn-client@office
systemctl status openvpn-client@office --no-pager
nmcli -f GENERAL.STATE,connection.secondaries connection show 'Work Wi-Fi'
ip -brief link show tun0
Cabe aqui mais uma verificação: confirme que o ExecStart da unit aponta para o binário que pensa. Um cliente compilado localmente ou um pacote snap precisa muitas vezes de um caminho explícito ou de um invólucro snap run, porque o systemd não herda a ordem de pesquisa da sua shell. Comparar command -v openvpn com o ficheiro da unit resolve isso em segundos.
Escreva o proprietário escolhido nas notas da máquina, ao lado do nome do perfil. A próxima pessoa que depurar um túnel em falta começará por essa linha em vez de repetir a comparação.