A sua VPN só funciona depois do login por causa do porta-chaves

O comando funciona quando tem sessão iniciada, por isso coloca-o num script de arranque e vai para casa. Na manhã seguinte a máquina está online e o túnel não. O mito é que uma invocação que funciona é um serviço que funciona. Na prática, a diferença é geralmente uma de duas coisas: o perfil pertence à sua sessão de utilizador em vez do sistema, ou o segredo é desbloqueado por algo que só existe depois de iniciar sessão. Ambos funcionam perfeitamente num teste manual e falham exatamente no momento em que ninguém está a ver.

Porque é que o login o faz funcionar

Um login gráfico inicia um bus de sessão e um agente do serviço de segredos, e é aí que muitos clientes orientados para o ambiente de trabalho guardam a palavra-passe do perfil ou a frase-passe da chave privada. Uma ativação que corre como o seu utilizador após o login pode pedir o segredo a esse agente e ter sucesso. A mesma ativação executada por uma unidade de arranque não tem sessão, nem bus, nem agente, pelo que a procura falha ou bloqueia num pedido que ninguém vê.

Execute o mesmo perfil antes e depois do login e obtém dois resultados diferentes de uma única configuração. Essa é a assinatura de uma dependência de credenciais, não de um túnel avariado, e explica porque é que um teste manual num terminal prova menos do que parece. O túnel está bem; falta o que desbloqueia o seu segredo.

Decida qual proprietário inicia o túnel

Existem dois padrões suportados, e misturá-los é a outra forma de isto falhar. O NetworkManager pode ativar uma ligação ao nível do sistema, o que é adequado quando a máquina já centraliza aí a sua rede. Em alternativa, uma unidade systemd dedicada executa a VPN diretamente e possui a própria interface.

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

Não execute os dois proprietários contra uma configuração. Se o NetworkManager gere a interface e uma unidade também a levanta, vão lutar por rotas e DNS, e o estado resultante depende de quem terminou por último.

Coloque o segredo onde um serviço o possa ler

Um serviço em segundo plano não pode responder a um pedido. As frases-passe de certificados, as palavras-passe de contas e os ficheiros de autenticação referenciados precisam todos de uma organização de armazenamento que a unidade alcance sem um humano, pertencente à conta que executa o serviço e ilegível para todos os outros.

O atalho tentador é tornar o ficheiro legível por todos até o erro de permissões desaparecer. Isso troca uma falha de arranque por uma exposição de credenciais de longa duração, e é o tipo de alteração que ninguém revisita. Use o mecanismo em que a implementação já confia: um ficheiro de credenciais restrito, uma chave não cifrada protegida pelas permissões do ficheiro, ou uma ligação ao nível do sistema com o seu próprio armazém de segredos.

Teste o evento que acontece de facto

Iniciar o serviço manualmente depois do login não testa quase nada. Reinicie, ou desative o login gráfico durante um ciclo, e observe a unidade a subir sozinha. É o único teste que exercita em conjunto a disponibilidade de credenciais, a prontidão da rede e a ordem das unidades. É também o teste que reproduz a falha reportada pelo utilizador, o que um arranque manual nunca faz.

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

A ordem importa tanto como as credenciais. Uma unidade que arranca antes de a ligação ascendente subjacente estar configurada desiste, e algumas distribuições diferem quanto a esperarem pela conetividade. Se a unidade reporta falha no arranque mas tem sucesso quando a inicia à mão trinta segundos depois, encontrou um problema de ordem e não um problema de segredo.

Verifique rotas e DNS, não apenas a interface

Uma interface que existe não é um túnel a funcionar. Após um arranque sem supervisão, verifique as rotas, o estado do resolver e um destino por endereço antes de verificar um nome. Depois verifique a aplicação para a qual o túnel existe.

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

Se o endereço funciona e o nome não, o problema restante é a política de DNS e não o túnel. Anote qual proprietário inicia o serviço e onde vive o segredo, porque a próxima pessoa a reiniciar esta máquina vai precisar de ambos os factos.