O OpenVPN não inicia sem erro? Veja o journal

O comando retorna, o serviço aparece como falhado e nada que se pareça com uma explicação chega ao terminal. Esse silêncio é o sintoma que as pessoas descrevem como «o OpenVPN não inicia», e quase nunca significa que o programa morreu sem dizer nada. Significa que a mensagem foi para um canal que você não estava lendo, ou que o que você iniciou não era o que tinha configurado. Ambos os casos se diagnosticam em menos de um minuto assim que você deixa de tratar o perfil como o suspeito.

Quatro lugares absorvem a saída: o journal da unidade, o plugin que possui a conexão, a outra ponta do túnel e um binário diferente do que você acha que está em execução. Cada um tem a sua própria verificação.

Silêncio significa que você não estava olhando o canal certo

Uma chamada em primeiro plano imprime no seu terminal. Uma unidade imprime no journal, e uma unidade que falhou pode sair antes de escrever qualquer coisa se a falha estiver em como ela foi iniciada e não no que lhe foi dito. A distinção importa: nenhuma entrada no journal significa que o processo nunca rodou de verdade, enquanto uma entrada seguida de uma saída significa que ele rodou e rejeitou algo.

systemctl status openvpn-client@office
journalctl -u openvpn-client@office -b --no-pager

Adicione systemctl show -p Result -p ExecMainStatus openvpn-client@office para separar uma saída limpa de um sinal. Um status de 1 com um Result=exit-code é uma decisão do programa; Result=signal ou um timeout apontam antes para o ambiente, e nenhuma edição do perfil vai mudar isso. Anote os dois valores antes de reiniciar qualquer coisa, porque um reinício apaga o estado transitório que os produziu.

O nome da instância faz parte do caminho

A unidade de modelo empacotada não aceita um caminho de arquivo. Ela aceita um nome de instância, e esse nome é acrescentado a um diretório para encontrar o perfil: office resolve para /etc/openvpn/client/office.conf no empacotamento Debian e Ubuntu. Um arquivo chamado office-v2.conf, iniciado como @office nunca é lido, e a unidade sai em silêncio porque do ponto de vista dela não havia nada a fazer. O diretório de busca difere entre o modo cliente e o modo servidor, então o mesmo erro aponta para um lugar completamente diferente quando você troca de modelo.

Essa discrepância é a causa mais comum da falha silenciosa, e é invisível no perfil porque o perfil está bem. Liste o que existe de fato e compare os dois nomes caractere por caractere, incluindo qualquer extensão que o empacotamento espere.

ls -l /etc/openvpn/client/
systemctl list-units 'openvpn*' --all

Se a unidade está habilitada mas nenhuma instância aparece, a própria habilitação pode se referir a um nome que foi renomeado depois. Reabilitar a instância correta geralmente basta, e vale a pena apagar o arquivo de unidade antigo que ficou para trás para não confundir a próxima pessoa. Um arquivo de unidade esquecido é uma coisinha que custa uma hora a alguém mais tarde.

Quando o plugin possui o túnel, o terminal não vê nada

Uma conexão iniciada pelo applet da área de trabalho pertence ao NetworkManager, e a saída OpenVPN dela vai para o journal desse serviço em vez de qualquer shell que você tenha aberto. Executar o cliente à mão e não ver nada é o esperado nessa disposição, porque o processo executado à mão não é o que carrega a conexão.

Procure no journal o serviço que o possui, depois reproduza a análise com um nível de detalhe que você consiga ler. Os dois comandos abaixo olham para donos diferentes da mesma falha.

journalctl -b -u NetworkManager --no-pager | grep -i -A3 openvpn
openvpn --config /etc/openvpn/client/office.conf --verb 4 --log /tmp/ovpn.log

A execução isolada serve para ler mensagens, não para substituir a conexão gerenciada, e as duas diferem depois disso: integração de DNS, rotas e tempo de vida pertencem ao plugin. Corrigir um erro de análise na execução isolada não corrige automaticamente a resolução de nomes quando o applet assume, então mantenha as duas observações separadas.

Dois binários, um PATH

Uma compilação manual instalada em /usr/local ganha numa chamada de shell, porque /usr/local/sbin precede /usr/sbin no PATH padrão do Ubuntu. Uma unidade não usa o seu PATH; ela executa o caminho absoluto escrito em ExecStart. Então a versão que funciona no seu terminal e a versão que falha como serviço podem ser programas genuinamente diferentes.

Compare as duas antes de reconstruir qualquer coisa. O terceiro comando é o que decide a questão.

command -v openvpn
whereis openvpn
systemctl cat openvpn-client@office | grep ExecStart

Outra diferença de ambiente se esconde no mesmo lugar. Uma unidade empacotada depende de um diretório de execução em /run que o systemd cria para ela; uma unidade substituta escrita à mão que omita esse ajuste pode falhar antes de abrir um único arquivo, e a falha parece uma recusa genérica sem nenhuma mensagem do OpenVPN.

Falhas que o cliente não consegue relatar

Alguns resultados são decididos na outra ponta. Um gateway que responde com um status HTTP e fecha a conexão já lhe disse do próprio estado, e o próximo passo útil é o log dele ou a conta por trás da credencial, não os seus arquivos locais. Nada local está quebrado nesse cenário, e editar o perfil para compensar torna o próximo diagnóstico mais difícil. Leia esse log antes de tocar na configuração do cliente.

Outro caso silencioso é um cliente que funciona corretamente. Um túnel em modo cliente nunca escuta numa porta, então uma verificação que espera um ouvinte aberto não relata nada e parece uma falha. Confirme qual modo você iniciou antes de tirar conclusões de uma lista de portas vazia.

Trabalhe as camadas em ordem: a unidade existe e o nome da instância está correto, algo chegou ao journal ou ao arquivo --log , qual binário e qual perfil rodaram de fato, e a falha é local ou remota. Cada resposta remove uma camada. Começar pelo perfil significa reescrever um arquivo que talvez nunca tenha sido aberto.