P_CONTROL_HARD_RESET_CLIENT_V2 dans le journal : une erreur ?

La ligne se répète toutes les quelques secondes et semble la cause de tout : un paquet nommé control hard reset, venant d'un client qui n'aboutit nulle part. Ce n'est pas une erreur. C'est le premier message d'une nouvelle session, et la répétition est le symptôme d'autre chose qui échoue plus loin. Séparer ce que dit l'étiquette de ce que la connexion a fait ensuite, c'est tout le diagnostic.

L'opcode désigne une position dans le protocole

OpenVPN multiplexe plusieurs types de paquets sur une seule socket, et l'opcode indique au destinataire lequel il tient. Les paquets hard-reset ouvrent une session, les paquets de contrôle portent la matière du handshake, les accusés de réception confirment la réception et les paquets de données portent la charge utile du tunnel. Lire le premier octet indique où se situe le paquet dans cet échange, et les définitions de paquet du code source nomment explicitement chaque famille.

C'est tout ce qu'il dit. Un paquet étiqueté comme reset initial du client prouve que le paquet a atteint votre point d'observation et que le pair veut ouvrir une session. Il ne prouve pas que le client a fait confiance à votre certificat, que ses identifiants ont été acceptés, ni qu'un canal de données est un jour devenu utilisable.

Le suffixe V2 est un marqueur de génération de protocole pour cette famille de paquets, pas une version de produit et pas un réglage que vous installez. Rien dans le nom ne renvoie à la réinitialisation d'un tunnel, au redémarrage d'un service ou au vidage d'un cache.

Ce que le client fait réellement à cet instant

Le client ouvre un identifiant de session auquel les deux extrémités rattacheront le trafic de contrôle suivant. Lorsque la protection du canal de contrôle est configurée, ce premier paquet porte déjà le HMAC qui permet au destinataire de décider s'il vaut la peine de consacrer des efforts au reste de l'échange. Un destinataire qui ne peut pas le vérifier écarte le paquet en silence, et c'est pourquoi une clé partagée erronée ressemble à un client qui parle dans le vide.

Rien de visible pour l'utilisateur ne s'est encore produit. Aucun certificat n'a été validé, aucun nom d'utilisateur n'a été proposé et aucune adresse de tunnel n'a été attribuée. Le reset est le préambule du handshake, donc tout jugement sur la connexion à ce stade est prématuré.

Pour une boucle de reconnexion inactive, le détail intéressant est l'intervalle. Un client qui réessaie à cycle fixe sans progresser est généralement rejeté avant de pouvoir avancer, et la raison figure dans le journal du pair, non dans le nom du paquet.

Où se cache la vraie défaillance après le reset

Lisez les deux journaux côte à côte et trouvez le premier événement qui n'est pas un reset. Côté client, un échec de validation de certificat est signalé avec le motif précis : un certificat expiré, une inadéquation de nom ou un émetteur inconnu. Côté serveur, un rejet d'identifiants est signalé comme échec d'authentification avec son propre motif. Les deux sont bien plus précis que la vision répétée qu'a le serveur des nouvelles tentatives.

Appariez une tentative par horodatage au lieu de lire chaque journal isolément, car la même défaillance apparaît aux deux endroits avec une formulation et une gravité différentes. Le pair qui abandonne indique généralement pourquoi.

Si aucun des deux côtés ne signale de rejet et que l'échange reste bloqué, la limite est l'accessibilité et non la confiance. Un pare-feu qui écarte la direction de retour, un dispositif de traduction d'adresses réseau dont la correspondance expire, ou un problème de MTU qui tue les paquets de handshake les plus gros produisent tous un échange bloqué sans la moindre erreur d'authentification.

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

Cette recherche n'est pas un diagnostic à elle seule, mais elle vous fait passer du vocabulaire du protocole à une classe réelle de défaillance en une étape.

Pourquoi désactiver la vérification est le mauvais réflexe

Quand le reset continue d'apparaître, le correctif qui semble le plus rapide est de désactiver la validation des certificats ou d'abandonner la protection du canal de contrôle pour que quelque chose se connecte. Cela échange une défaillance diagnosticable contre une autre qui ne l'est pas, et laisse le déploiement accepter des pairs qu'il a été construit pour refuser.

Changez plutôt la limite qui a réellement échoué. Un problème de confiance relève de l'autorité de certification et du profil qui la référence. Un problème d'heure relève de l'horloge. Un problème d'identifiants relève du backend d'authentification qui les a rejetés, et un pair injoignable relève du chemin entre les deux hôtes.

L'opcode est utile dans une conversation de support pour une chose : il vous dit que le pair est allé assez loin pour essayer. Ce qui s'est passé ensuite est ce qu'il vous faut savoir, et c'est consigné dans le journal qui enregistre le premier rejet précis. Partez de là, et la ligne de reset cesse de ressembler à une cause et commence à ressembler à un horodatage.