P_CONTROL_HARD_RESET_CLIENT_V2 no log: é um erro?

A linha repete-se a cada poucos segundos e parece a causa de tudo: um pacote chamado control hard reset, que vem de um cliente que nunca chega a nenhum lugar. Não é um erro. É a primeira mensagem de uma nova sessão, e a repetição é o sintoma de outra coisa que falha mais adiante. Separar o que o rótulo diz do que a ligação fez depois é todo o diagnóstico.

O opcode nomeia uma posição no protocolo

OpenVPN multiplexa vários tipos de pacote sobre um único socket, e o opcode diz ao recetor que tipo tem em mãos. Os pacotes hard-reset abrem uma sessão, os pacotes de controlo transportam material de handshake, as confirmações confirmam a receção e os pacotes de dados transportam a carga do túnel. Ler o primeiro byte indica onde o pacote encaixa nessa troca, e as definições de pacote do código-fonte nomeiam cada família explicitamente.

É tudo o que diz. Um pacote marcado como reset inicial do cliente prova que o pacote chegou ao seu ponto de observação e que o par quer iniciar uma sessão. Não prova que o cliente confiou no seu certificado, que as suas credenciais foram aceites ou que um canal de dados alguma vez ficou utilizável.

O sufixo V2 é uma marca de geração de protocolo para essa família de pacotes, não uma versão de produto e não uma definição que instala. Nada no nome se refere a reiniciar um túnel, reiniciar um serviço ou limpar uma cache.

O que o cliente realmente faz naquele momento

O cliente abre um identificador de sessão ao qual ambas as pontas associarão o tráfego de controlo seguinte. Com a proteção do canal de controlo configurada, esse primeiro pacote já transporta o HMAC que permite ao recetor decidir se vale a pena despender esforço no resto da troca. Um recetor que não consegue verificá-lo descarta o pacote em silêncio, e é por isso que uma chave partilhada errada parece um cliente a falar para o vazio.

Ainda não aconteceu nada visível para o utilizador. Nenhum certificado foi validado, nenhum nome de utilizador foi oferecido e nenhum endereço de túnel foi atribuído. O reset é o preâmbulo do handshake, portanto qualquer julgamento sobre a ligação neste ponto é prematuro.

Num ciclo de reconexão inativo, o detalhe interessante é o intervalo. Um cliente que tenta de novo num ciclo fixo sem progredir é normalmente rejeitado antes de poder avançar, e a razão está no log do par, não no nome do pacote.

Onde se esconde a falha real depois do reset

Leia os dois logs lado a lado e encontre o primeiro evento que não seja um reset. No cliente, uma falha de validação de certificado é comunicada com o motivo concreto: um certificado expirado, um nome que não corresponde ou um emissor desconhecido. No servidor, uma rejeição de credenciais é comunicada como falha de autenticação com o seu próprio motivo. Ambas são muito mais específicas do que a visão repetida do servidor das novas tentativas.

Combine uma tentativa pela marca temporal em vez de ler cada log isoladamente, porque a mesma falha aparece nos dois sítios com palavras e gravidade diferentes. O par que desiste normalmente diz porquê.

Se nenhum dos lados comunica uma rejeição e a troca continua bloqueada, o limite é a alcançabilidade e não a confiança. Uma firewall que descarta a direção de retorno, um dispositivo de tradução de endereços de rede cuja correspondência expira, ou um problema de MTU que mata os pacotes de handshake maiores produzem todos uma troca bloqueada sem qualquer erro de autenticação.

grep -nE 'VERIFY|AUTH_FAILED|TLS Error|SIGUSR1' /var/log/openvpn*.log

Essa pesquisa não é um diagnóstico por si só, mas leva-o do vocabulário do protocolo a uma classe de falha real num único passo.

Por que desativar a verificação é o reflexo errado

Quando o reset continua a aparecer, a correção que parece mais rápida é desativar a validação de certificados ou abandonar a proteção do canal de controlo para que algo se ligue. Isso troca uma falha diagnosticável por uma que não o é, e deixa a implementação a aceitar pares que foi construída para recusar.

Mude, em vez disso, o limite que falhou de facto. Um problema de confiança pertence à autoridade de certificação e ao perfil que a referencia. Um problema de hora pertence ao relógio. Um problema de credenciais pertence ao backend de autenticação que as recusou, e um par inalcançável pertence ao caminho entre os dois anfitriões.

O opcode é útil numa conversa de suporte por uma coisa: diz-lhe que o par chegou suficientemente longe para tentar. O que aconteceu depois é o que precisa de saber, e está escrito no log que registou a primeira rejeição concreta. Comece por aí, e a linha de reset deixa de parecer uma causa e começa a parecer uma marca temporal.