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.

StarterWhat triggers itTypical failure
Init script and templated unitsBoot, plus anything in the autostart listStarts every config, not the one you meant
NetworkManager secondaryActivation of the base Wi-Fi or Ethernet profileNothing happens until that base link comes up
Hand-written unit or wrapperWhatever its WantedBy and ExecStart sayRuns 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.

Artigos relacionados