OpenVPN não inicia: leia a primeira linha, não a configuração

Uma VPN que morre no primeiro segundo é um animal diferente de uma que se conecta e depois falha, e o erro habitual é tratar as duas como a mesma coisa. Aqui não há handshake, nem troca de certificados, nem rota para examinar. Uma linha no journal decide qual de várias reparações não relacionadas se aplica, e ignorá-la custa uma tarde editando uma configuração que nunca foi lida. Leia essa linha primeiro.

Três comandos somente leitura levam você até lá: primeiro journalctl -u openvpn@server -b --no-pager, depois systemctl status openvpn@server, e ss -lunp para os ouvintes UDP e seus proprietários.

A primeira linha escolhe o ramo

Um conflito de portas e um binário ausente matam o início em menos de um segundo, e deixam primeiras linhas diferentes. Uma mensagem de que o endereço já está em uso nomeia a porta; um executável ausente nomeia um caminho que não existe mais; uma condição falhada ou um arquivo de configuração ausente nomeia o arquivo. Essas três levam a reparações diferentes, e nenhuma melhora reinstalando o cliente. Copie a primeira falha para as suas notas antes de executar qualquer outra coisa.

Observe o laço de novas tentativas que esconde a linha original. Uma unidade com uma política de reinício pode enterrar a primeira falha sob uma dúzia de idênticas, então journalctl -b filtrado pela unidade e lido do topo vence a cauda.

Quem mais está com a porta 1194

O culpado normalmente não é um segundo servidor que alguém configurou de propósito. Espere um cliente iniciado à mão ainda vivo noutro terminal, um segundo perfil que escolheu a mesma porta, ou um pacote de fornecedor cujo próprio túnel segura a 1194. O proprietário do socket aparece em ss -lunp; passe esse PID ao systemctl status para saber se uma unidade é responsável. Derrube-o pelo próprio caminho de controle e não com um sinal.

Um sinal a um processo gerido por uma unidade costuma provocar um reinício, e a mesma falha reaparece momentos depois como um problema novo. Use systemctl stop para uma unidade, o comando de serviço do próprio pacote para uma instalação de fornecedor, e um sinal apenas para algo que você mesmo iniciou naquele shell.

Unidades que restam após uma remoção

Uma remoção apaga binários; os arquivos de unidade escritos à mão, normalmente em /etc/systemd/system, sobrevivem a ela. O Systemd tenta então novamente uma unidade que aponta para um caminho que já não existe, e a mensagem diz respeito a esse arquivo ausente e não à remoção de ontem. O systemctl status mostra o caminho do fragmento da unidade perto do topo, portanto verifique-o com dpkg -S antes de apagar alguma coisa. Assim que o órfão desaparece, systemctl daemon-reload e systemctl reset-failed limpam o estado; caso contrário, cada verificação de estado posterior herda-o.

Quando which openvpn responde com algo sob /usr/local, o binário em causa veio de um instalador do fornecedor e não do apt. Esse instalador costuma trazer o seu próprio ouvinte, a sua própria entrada de arranque e o seu próprio diretório de configuração, portanto remover o comando visível deixa o socket ocupado.

Desinstale-o conforme o fornecedor documenta, confirme que a porta está livre com ss -lunp, e acrescente o cliente da distribuição apenas se precisar dele.

Ponha o estado em ordem antes de tentar de novo

Limpe o estado de falha antes de tirar conclusões dele: systemctl reset-failed remove os contadores, e systemctl status passa então a relatar o estado atual da unidade e não o histórico. Inicie-a uma vez e leia o journal dessa execução em vez do estado agregado da máquina. Uma unidade que relata estar ativa enquanto o túnel não transporta nada é um problema à parte, e muito mais comum. Os dois fundem-se nos relatórios de erros porque ambos terminam com o utilizador a dizer que a VPN não funciona.

Anote o ramo que tomou: conflito de portas, binário ausente, configuração ausente. Da próxima vez será mais rápido reconhecê-lo.