Testar a recuperação do servidor VPN após reiniciar: o que verificar primeiro

Reinicie o servidor sem que ninguém tenha sessão iniciada e depois ligue-se a partir de uma rede que não controla. Esse único teste responde se a recuperação é real, porque um túnel que só funciona depois de alguém executar um comando à mão não é recuperação, é uma reparação. A maioria das verificações para demasiado cedo: o serviço mostra-se ativo, a interface aparece e a página continua a não carregar. A lacuna está quase sempre na persistência das peças em torno do túnel, não no próprio comando do túnel.

Quatro proprietários, quatro testes diferentes

Antes do reinício, nomeie o que deve trazer o túnel de volta. O teste que executa e a correção que aplica dependem ambos dessa resposta, e há quatro proprietários comuns: uma unidade systemd para o serviço VPN, uma unidade de instância wg-quick para uma interface WireGuard, um runtime de contentores ou um perfil de gestor de rede. Se não conseguir nomear o proprietário, pare e encontre-o, porque um teste de reinício sem um caminho de arranque esperado só lhe diz que algo aconteceu.

Cada proprietário guarda a sua configuração num local diferente. Um servidor OpenVPN gerido por systemd lê a configuração no arranque, pelo que o que estiver no ficheiro no momento do arranque é o que corre. Uma interface wg-quick obtém os endereços, as rotas e o DNS do mesmo ficheiro, o que significa que uma interface levantada à mão a partir de uma shell e nunca ativada como unidade não voltará. Um contentor recupera o seu ponto de entrada, mas não as alterações de firewall do anfitrião, a menos que estas vivam fora do contentor.

Primeiro a linha de base, ou o resultado não significa nada

Registe o estado de funcionamento enquanto funciona: endereços no túnel, rotas para a sub-rede de clientes, regras NAT ou de encaminhamento, o socket à escuta e o sysctl de encaminhamento. ip addr show wg0, ip route, nft list ruleset ou iptables-save, ss -lunp e sysctl net.ipv4.ip_forward chegam na maioria dos anfitriões.

Registe como o serviço está configurado para arrancar, não apenas que está em execução. systemctl is-enabled wg-quick@wg0 e systemctl is-active wg-quick@wg0 respondem a perguntas diferentes, e o estado ativado é o que importa no arranque, como descrito em systemctl(1). Para OpenVPN, verifique que modelo o anfitrião usa, pois openvpn@server e openvpn-server@server são unidades diferentes com predefinições diferentes.

Execute o reinício e leia a primeira falha

Reinicie de propósito, numa janela que escolheu, com uma consola ou um caminho fora de banda aberto. Observe a ordem dos acontecimentos em vez do estado final: anfitrião alcançável, unidade ativada, interface presente, rotas instaladas, regras de firewall presentes, ouvinte ligado, cliente aceite. O primeiro passo que não acontece é o achado; tudo depois disso é ruído.

Um serviço pode estar ativo enquanto o túnel é inutilizável, e essa é a falsa aprovação mais comum. O arranque pode terminar antes de a rede estar online se a unidade esperar apenas por network.target em vez de network-online.target. Ficheiros referenciados como certificados, chaves ou uma CRL podem estar ilegíveis nesse momento porque uma montagem ou um caminho de segredos ainda não está pronto. Nenhum dos dois problemas aparece em systemctl status até ler o registo da unidade.

Teste de fora do anfitrião. Um cliente na mesma LAN pode ter sucesso por uma rota que nenhum cliente remoto usaria, e uma sessão SSH para a máquina não prova nada sobre o túnel. Ligue-se, resolva um nome interno, alcance o recurso privado e volte a ligar-se uma vez para confirmar que o estado de revogação e as chaves ainda se aplicam.

As três condições que decidem a sua correção

Se o túnel volta mas os clientes não alcançam nada, a falha está no encaminhamento ou na persistência do NAT. Se os clientes nem conseguem concluir um handshake, a falha está na interface ou no material de autenticação. Se o serviço nunca arranca, a falha está no ficheiro da unidade ou nas suas dependências. Estes três ramos levam a correções diferentes, e é por isso que um reinício cego sem linha de base custa mais tempo do que poupa.

Faça a correção onde a definição é propriedade. Coloque o encaminhamento num drop-in de sysctl, coloque as regras NAT no conjunto de regras que carrega no arranque, ative a unidade em vez de a iniciar, e guarde os segredos num caminho que exista antes de a unidade arrancar. Acrescentar uma espera à unidade esconde uma dependência em vez de a declarar.

Registe o resultado no runbook

Escreva o que voltou sozinho, o que teve de iniciar e quanto tempo durou a lacuna. Inclua os comandos exatos que usou para verificar, para que a próxima pessoa repita o teste em vez de inventar um. Se algum passo precisou de um comando manual, esse comando pertence à configuração, não ao runbook como passo permanente.

Depois agende o próximo teste para depois da próxima alteração à pilha de rede do anfitrião, não para uma data de calendário daqui a seis meses. O modo de falha contra o qual se protege é um comando temporário que parecia permanente, e esses aparecem exatamente quando alguém edita regras de firewall ou move um serviço para uma nova unidade.