P_CONTROL_HARD_RESET_CLIENT_V2 en el registro: ¿es un error?

La línea se repite cada pocos segundos y parece la causa de todo: un paquete llamado control hard reset, que llega de un cliente que nunca llega a ninguna parte. No es un error. Es el primer mensaje de una sesión nueva, y la repetición es el síntoma de otra cosa que falla más adelante. Separar lo que dice la etiqueta de lo que hizo la conexión después es todo el diagnóstico.

El opcode nombra una posición en el protocolo

OpenVPN multiplexa varios tipos de paquete sobre un solo socket, y el opcode dice al receptor qué tipo tiene en la mano. Los paquetes hard-reset abren una sesión, los paquetes de control llevan material de handshake, las confirmaciones confirman la recepción y los paquetes de datos llevan la carga del túnel. Leer el primer byte indica dónde encaja el paquete en ese intercambio, y las definiciones de paquete del código fuente nombran cada familia explícitamente.

Eso es todo lo que dice. Un paquete etiquetado como reset inicial del cliente demuestra que el paquete llegó a su punto de observación y que el par quiere iniciar una sesión. No demuestra que el cliente se fiara de su certificado, que sus credenciales fueran aceptadas ni que un canal de datos llegara a ser utilizable.

El sufijo V2 es una marca de generación de protocolo para esa familia de paquetes, no una versión de producto ni un ajuste que usted instale. Nada en el nombre se refiere a reiniciar un túnel, reiniciar un servicio o vaciar una caché.

Qué hace realmente el cliente en ese momento

El cliente abre un identificador de sesión al que ambos extremos asociarán el tráfico de control posterior. Con la protección del canal de control configurada, ese primer paquete ya lleva el HMAC que permite al receptor decidir si vale la pena esforzarse en el resto del intercambio. Un receptor que no puede verificarlo descarta el paquete en silencio, y por eso una clave compartida equivocada parece un cliente hablando al vacío.

Todavía no ha ocurrido nada visible para el usuario. No se ha validado ningún certificado, no se ha ofrecido ningún nombre de usuario y no se ha asignado ninguna dirección de túnel. El reset es el preámbulo del handshake, así que cualquier juicio sobre la conexión en este punto es prematuro.

En un bucle de reconexión inactivo, el detalle interesante es el intervalo. Un cliente que reintenta en un ciclo fijo sin avanzar suele ser rechazado antes de poder progresar, y la razón está en el registro del par, no en el nombre del paquete.

Dónde se esconde el fallo real tras el reset

Lea los dos registros uno junto al otro y busque el primer evento que no sea un reset. En el cliente, un fallo de validación de certificado se informa con el motivo concreto: un certificado caducado, un nombre que no coincide o un emisor desconocido. En el servidor, un rechazo de credenciales se informa como fallo de autenticación con su propio motivo. Ambos son mucho más concretos que la visión repetida del servidor de los intentos nuevos.

Empareje un intento por marca de tiempo en lugar de leer cada registro por separado, porque el mismo fallo aparece en los dos sitios con palabras y gravedad distintas. El par que se rinde normalmente dice por qué.

Si ninguno de los dos lados informa de un rechazo y el intercambio sigue atascado, el límite es la accesibilidad, no la confianza. Un cortafuegos que descarta la dirección de vuelta, un dispositivo de traducción de direcciones de red que caduca la correspondencia o un problema de MTU que mata los paquetes de handshake más grandes producen todos un intercambio atascado sin ningún error de autenticación.

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

Esa búsqueda no es un diagnóstico por sí sola, pero le lleva del vocabulario del protocolo a una clase de fallo real en un solo paso.

Por qué desactivar la verificación es el reflejo equivocado

Cuando el reset sigue apareciendo, el arreglo que parece más rápido es desactivar la validación de certificados o abandonar la protección del canal de control para que algo se conecte. Eso cambia un fallo diagnosticable por uno indiagnosticable, y deja el despliegue aceptando pares que fue construido para rechazar.

Cambie en su lugar el límite que realmente falló. Un problema de confianza pertenece a la autoridad de certificación y al perfil que la referencia. Un problema de hora pertenece al reloj. Un problema de credenciales pertenece al backend de autenticación que las rechazó, y un par inalcanzable pertenece al camino entre los dos equipos.

El opcode es útil en una conversación de soporte por una cosa: le dice que el par llegó lo bastante lejos como para intentarlo. Lo que ocurrió después es lo que necesita saber, y está escrito en el registro que anote el primer rechazo concreto. Empiece por ahí, y la línea de reset deja de parecer una causa y empieza a parecer una marca de tiempo.