Qual instância do OpenVPN está realmente a usar o teu perfil PiVPN?

O PiVPN escreve uma configuração de servidor e um perfil de cliente e depois sai; nunca se torna o processo que transporta o teu tráfego. Por isso, um handshake falhado, um cliente que marca o endpoint errado ou um serviço que volta mal depois de um reinício não se explicam pelos menus do instalador. Esses sintomas pertencem ao daemon OpenVPN que está a correr agora, à configuração que esse daemon carregou realmente e ao registo para onde foi apontado. Quatro comandos só de leitura costumam resolver isto, e nenhum deles altera os teus certificados ou chaves.

O auxiliar e o daemon são objetos diferentes

A confusão explica-se facilmente: um diretório contém o ficheiro que o auxiliar gerou, o ficheiro que o daemon lê e, por vezes, uma cópia obsoleta de ambos. Um auxiliar é um script de aprovisionamento. Instala pacotes, escreve ficheiros de unidade e imprime um perfil de cliente, e depois o seu trabalho termina. O que resta é uma entrada no gestor de serviços e uma linha de comandos.

Num host systemd, começa pela unidade ativa em vez da listagem do diretório. O nome depende do empacotamento: as imagens Debian e Raspberry Pi OS expõem normalmente uma instância de modelo como openvpn-server@server, enquanto instalações mais antigas usam openvpn@server. Pergunta ao gestor qual está a correr em vez de adivinhares pelo nome do ficheiro.

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

Lê ExecStart= nessa saída. Nomeia o executável e as opções que o gestor lança realmente, incluindo qualquer --config caminho; um ficheiro de configuração que está ao lado e para o qual nenhum comando remete não faz parte do túnel em execução.

Segue a cadeia de configuração que o daemon resolveu

OpenVPN não varre um diretório à procura de definições. Lê o ficheiro passado com --config, segue qualquer config diretiva dentro dele e depois aplica as opções da linha de comandos. O manual 2.6 descreve essa ordem, e isso conta quando dois ficheiros discordam sobre a porta, o dispositivo ou a cifra.

Despeja primeiro a invocação efetiva e só depois olha para as diretivas que decidem identidade e acessibilidade. Ambos os comandos são só de leitura e seguros num servidor vivo, embora o segundo imprima caminhos que talvez não queiras num ticket público.

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

Um ficheiro .ovpn num diretório pessoal é um artefacto de cliente. O daemon do servidor nunca o lê, por isso editar esse ficheiro para corrigir uma falha de handshake do lado do servidor não consegue nada.

As inclusões são a outra armadilha. Uma linha config puxa um segundo ficheiro cujas opções são processadas nesse ponto, pelo que uma diretiva posterior de um só valor pode sobrepor-se ao que o ficheiro principal parece dizer. Se o ficheiro visível parecer correto e o daemon continuar a comportar-se de outra forma, lê o ficheiro incluído antes de mudares alguma coisa.

Liga o registo ao processo, não ao erro de que te lembras

Dois destinos de registo são comuns, e só um deles é o journal. Com log-append definido, o daemon escreve nesse ficheiro e o journal guarda pouco para além das linhas de arranque. Sem isso, journalctl é a fonte de eventos.

journalctl -u openvpn-server@server -n 80 --no-pager

Correlaciona uma tentativa de ligação com uma janela temporal. Anota o endpoint do cliente e depois lê os eventos do servidor dos mesmos segundos. Um handshake TLS que nunca chega à troca de certificados aponta para acessibilidade ou desalinhamento de protocolo, enquanto uma rejeição de autenticação chega depois de os parâmetros do túnel já estarem acordados.

Uma entrada antiga do registo não prova nada sobre um perfil que descarregaste há cinco minutos. Gera novamente o ficheiro de cliente, liga-te uma vez e lê apenas as linhas que apareceram durante essa tentativa.

Anota a primeira falha concreta em vez da última genérica. Um erro de bind, uma troca externa sem resposta, uma rejeição de certificado e uma rejeição de conta levam-te cada uma a uma camada diferente, e um tempo limite no fim esconde muitas vezes o evento útil acima.

Reconstruir o túnel não é um passo de diagnóstico

O atalho tentador é levantar um segundo túnel mais simples: chave estática, sem certificados, sem autenticação adicional. Muitas vezes ligará, e só prova que dois hosts conseguem passar UDP ou TCP entre si. Não diz nada sobre porque falha a implementação autenticada por certificado, e substitui em silêncio o modelo de segurança que te pediram para manter.

O mesmo se aplica a desativar tls-auth ou tls-crypt, a relaxar verify-x509-name, ou a eliminar um segundo fator para obter um estado verde. Um túnel que liga porque a verificação foi removida é outro sistema, não um reparado.

Faz uma alteração limitada na camada que o registo nomeou, reinicia a mesma unidade e repete a única tentativa de ligação. Isso mantém a comparação honesta e deixa uma alteração que podes reverter.

O que entregar à pessoa seguinte

Anota quatro factos enquanto ainda os tens: a versão do OpenVPN a partir de openvpn --version, a unidade que está ativa, a cadeia de configuração com as suas inclusões e a janela de registo que cobre uma tentativa. Esses quatro transformam uma queixa vaga num caso reproduzível.

Redige antes de partilhar. As chaves privadas, auth-user-pass e outros ficheiros, o material de chave estática e os pacotes completos de cliente não pertencem a um ticket; os nomes das opções e a forma da cadeia costumam bastar para um segundo par de olhos.

Se a cadeia estiver intacta e o registo continuar a apontar para a rede, o passo seguinte é o caminho entre cliente e servidor em vez de outra instalação. É a única parte da história que o auxiliar nunca possuiu.