P_CONTROL_HARD_RESET_CLIENT_V2 al registre: és un error?

La línia es repeteix cada pocs segons i sembla la causa de tot: un paquet anomenat control hard reset, provinent d'un client que no arriba enlloc. No és un error. És el primer missatge d'una sessió nova, i la repetició és el símptoma d'una altra cosa que falla més endavant. Separar què diu l'etiqueta del que va fer la connexió després és tot el diagnòstic.

L'opcode anomena una posició del protocol

OpenVPN multiplexa diversos tipus de paquet sobre un sol socket, i l'opcode diu al receptor quin tipus té a les mans. Els paquets hard-reset obren una sessió, els paquets de control porten material d'encaixada de mans, les confirmacions confirmen la recepció i els paquets de dades porten la càrrega del túnel. Llegir el primer byte indica on cau el paquet dins d'aquest intercanvi, i les definicions de paquet del codi font nomenen cada família explícitament.

Això és tot el que diu. Un paquet etiquetat com a reset inicial del client demostra que el paquet va arribar al vostre punt d'observació i que l'altre extrem vol iniciar una sessió. No demostra que el client s'hagi refiat del vostre certificat, que les seves credencials s'hagin acceptat ni que un canal de dades hagi estat mai utilitzable.

El sufix V2 és una marca de generació de protocol per a aquesta família de paquets, no una versió de producte ni un paràmetre que instal·leu. Res del nom fa referència a reiniciar un túnel, reiniciar un servei o buidar una memòria cau.

Què fa realment el client en aquell moment

El client obre un identificador de sessió al qual tots dos extrems adjuntaran el trànsit de control posterior. Amb la protecció del canal de control configurada, aquell primer paquet ja porta l'HMAC que permet al receptor decidir si val la pena esforçar-se en la resta de l'intercanvi. Un receptor que no el pot verificar descarta el paquet en silenci, i per això una clau compartida equivocada sembla un client que parla al buit.

Encara no ha passat res visible per a l'usuari. No s'ha validat cap certificat, no s'ha ofert cap nom d'usuari i no s'ha assignat cap adreça de túnel. El reset és el preàmbul de l'encaixada de mans, així que qualsevol judici sobre la connexió en aquest punt és prematur.

En un bucle de reconnexió inactiu, el detall interessant és l'interval. Un client que reintenta en un cicle fix sense avançar normalment és rebutjat abans de poder progressar, i la raó és al registre de l'altre extrem, no al nom del paquet.

On s'amaga la fallada real després del reset

Llegiu els dos registres costat per costat i trobeu el primer esdeveniment que no sigui un reset. Al client, una fallada de validació de certificat s'informa amb el motiu concret: un certificat caducat, un nom que no coincideix o un emissor desconegut. Al servidor, un rebuig de credencials s'informa com a fallada d'autenticació amb el seu propi motiu. Tots dos són molt més concrets que la visió repetida del servidor dels intents nous.

Aparelleu un intent per marca de temps en lloc de llegir cada registre aïlladament, perquè la mateixa fallada apareix als dos llocs amb paraules i gravetat diferents. L'extrem que es rendeix normalment diu per què.

Si cap dels dos costats informa d'un rebuig i l'intercanvi encara s'encalla, el límit és l'abastabilitat, no la confiança. Un tallafoc que descarta la direcció de tornada, un dispositiu de traducció d'adreces de xarxa que fa caducar la correspondència o un problema d'MTU que mata els paquets d'encaixada més grans produeixen tots un intercanvi encallat sense cap error d'autenticació.

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

Aquesta cerca no és un diagnòstic per si sola, però us porta del vocabulari del protocol a una classe de fallada real en un sol pas.

Per què desactivar la verificació és el reflex equivocat

Quan el reset no para d'aparèixer, la solució que sembla més ràpida és desactivar la verificació de certificats o abandonar la protecció del canal de control perquè alguna cosa es connecti. Això canvia una fallada diagnosticable per una d'indiagnosticable, i deixa el desplegament acceptant extrems que estava fet per rebutjar.

Canvieu més aviat el límit que realment ha fallat. Un problema de confiança pertany a l'autoritat de certificació i al perfil que la referencia. Un problema de temps pertany al rellotge. Un problema de credencials pertany al backend d'autenticació que les va rebutjar, i un extrem inabastable pertany al camí entre els dos amfitrions.

L'opcode és útil en una conversa de suport per a una cosa: us diu que l'extrem va arribar prou lluny per intentar-ho. El que va passar després és el que cal saber, i està escrit al registre que anoti el primer rebuig concret. Comenceu per aquí, i la línia de reset deixa de semblar una causa i comença a semblar una marca de temps.