P_CONTROL_HARD_RESET_CLIENT_V2 no rexistro: é un erro?

A liña repítese cada poucos segundos e parece a causa de todo: un paquete chamado control hard reset, que chega dun cliente que nunca chega a ningures. Non é un erro. É a primeira mensaxe dunha sesión nova, e a repetición é o síntoma doutra cousa que falla máis adiante. Separar o que di a etiqueta do que fixo a conexión despois é todo o diagnóstico.

O opcode nomea unha posición no protocolo

OpenVPN multiplexa varios tipos de paquete sobre un só socket, e o opcode di ao receptor que tipo ten na man. Os paquetes hard-reset abren unha sesión, os paquetes de control levan material de handshake, as confirmacións confirman a recepción e os paquetes de datos levan a carga do túnel. Ler o primeiro byte indica onde encaixa o paquete nese intercambio, e as definicións de paquete do código fonte nomean cada familia explicitamente.

Iso é todo o que di. Un paquete etiquetado como reset inicial do cliente demostra que o paquete chegou ao seu punto de observación e que o par quere iniciar unha sesión. Non demostra que o cliente confiase no seu certificado, que as súas credenciais fosen aceptadas nin que unha canle de datos chegase a ser utilizábel.

O sufixo V2 é unha marca de xeración de protocolo para esa familia de paquetes, non unha versión de produto nin un axuste que vostede instale. Nada no nome se refire a reiniciar un túnel, reiniciar un servizo ou baleirar unha caché.

Que fai realmente o cliente nese momento

O cliente abre un identificador de sesión ao que ambas as partes asociarán o tráfico de control posterior. Coa protección da canle de control configurada, ese primeiro paquete xa leva o HMAC que permite ao receptor decidir se paga a pena esforzarse no resto do intercambio. Un receptor que non pode verificalo descarta o paquete en silencio, e por iso unha clave compartida equivocada parece un cliente falando ao baleiro.

Aínda non ocorreu nada visible para o usuario. Non se validou ningún certificado, non se ofreceu ningún nome de usuario e non se asignou ningún enderezo de túnel. O reset é o preámbulo do handshake, así que calquera xuízo sobre a conexión neste punto é prematuro.

Nun bucle de reconexión inactivo, o detalle interesante é o intervalo. Un cliente que reintenta nun ciclo fixo sen avanzar adoita ser rexeitado antes de poder progresar, e a razón está no rexistro do par, non no nome do paquete.

Onde se esconde o fallo real tras o reset

Lea os dous rexistros un xunto ao outro e atope o primeiro acontecemento que non sexa un reset. No cliente, un fallo de validación de certificado infórmase co motivo concreto: un certificado caducado, un nome que non coincide ou un emisor descoñecido. No servidor, un rexeitamento de credenciais infórmase como fallo de autenticación co seu propio motivo. Ambos son moito máis concretos que a visión repetida do servidor dos intentos novos.

Emparelle un intento por marca de tempo en lugar de ler cada rexistro por separado, porque o mesmo fallo aparece nos dous sitios con palabras e gravidade distintas. O par que se rende normalmente di por que.

Se ningún dos dous lados informa dun rexeitamento e o intercambio segue atascado, o límite é a accesibilidade, non a confianza. Un cortafogos que descarta a dirección de volta, un dispositivo de tradución de enderezos de rede que caduca a correspondencia ou un problema de MTU que mata os paquetes de handshake máis grandes producen todos un intercambio atascado sen ningún erro de autenticación.

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

Esa busca non é un diagnóstico por si soa, pero leva do vocabulario do protocolo a unha clase de fallo real nun só paso.

Por que desactivar a verificación é o reflexo equivocado

Cando o reset segue aparecendo, a solución que parece máis rápida é desactivar a validación de certificados ou abandonar a protección da canle de control para que algo se conecte. Iso cambia un fallo diagnosticábel por un indiagnosticábel, e deixa o despregamento aceptando pares que foi construído para rexeitar.

Cambie no seu lugar o límite que realmente fallou. Un problema de confianza pertence á autoridade de certificación e ao perfil que a referencia. Un problema de hora pertence ao reloxo. Un problema de credenciais pertence ao backend de autenticación que as rexeitou, e un par inalcanzábel pertence ao camiño entre os dous equipos.

O opcode é útil nunha conversa de soporte por unha cousa: dille que o par chegou o bastante lonxe como para intentalo. O que ocorreu despois é o que necesita saber, e está escrito no rexistro que anote o primeiro rexeitamento concreto. Comece por aí, e a liña de reset deixa de parecer unha causa e comeza a parecer unha marca de tempo.