Échec de l’authentification HMAC du paquet OpenVPN : quelle couche ?

Deux échecs sont rapportés avec le même vocabulaire et n’ont presque rien en commun. L’un est un paquet dont l’étiquette d’authentification n’a pas été vérifiée ; l’autre est une personne dont les identifiants ont été refusés. Traiter le premier comme le second vous envoie chercher un mot de passe qui n’a jamais été le problème.

Le message nomme une couche, et le travail utile consiste à décider laquelle avant de remplacer le moindre matériel. Comparer les candidats côte à côte est le moyen le plus rapide de voir la différence.

Deux échecs qui partagent un mot

Une erreur d’authentification de paquet survient pendant le traitement du trafic : une étiquette ou un condensé sur un paquet reçu ne correspondait pas à ce que le destinataire avait calculé. Un refus de compte intervient après l’analyse d’un échange de connexion, et il nomme un utilisateur plutôt qu’un paquet. Un troisième message, sur l’impossibilité de localiser un HMAC dans un paquet entrant, est encore différent, car là le paquet est arrivé sans l’élément d’authentification attendu. Le préfixe complet du journal vous dit lequel des trois vous avez, et le préfixe est généralement la première chose supprimée quand une erreur est collée dans un ticket.

La distinction change la réparation. L’une exige des réglages de canal concordants, l’autre l’état du compte, et la troisième un profil qui ne correspond pas à l’écouteur atteint.

Comparez ce que le processus en cours a réellement chargé

Un fichier correct sur le disque ne prouve rien pour un processus démarré avant sa modification. Vérifiez le profil sélectionné, le point de terminaison contacté et si le service a été rechargé depuis le changement. Confirmez aussi que le point de terminaison appartient au profil, car une autre instance ou un autre service peut écouter là où l’ancien fichier attend autre chose.

Réexporter un profil pris en charge depuis la même source est une comparaison peu coûteuse, car elle supprime l’écart entre ce que vous croyez configuré et ce que le client envoie réellement. Générer du nouveau matériel de clé est une étape bien plus lourde, et elle n’aide que si les deux extrémités l’adoptent ensemble. Remplacer un côté localement recrée l’incohérence que vous cherchiez à supprimer.

Comparez le canal de contrôle avec le canal de données

Deux mécanismes authentifient des parties différentes d’une connexion et se configurent séparément, comme le référentiel d’options 2.6 le décrit. tls-auth ajoute un HMAC aux paquets du canal de contrôle et prend un argument de direction qui doit être opposé sur les deux pairs, tandis que tls-crypt protège le canal de contrôle avec une clé partagée à la place. Ni l’un ni l’autre n’est le contrôle d’intégrité propre au canal de données. Avec un chiffrement de données AEAD, ce contrôle est intégré au chiffrement, donc le auth condensé séparé n’est pas utilisé comme avec un chiffrement qui n’est pas AEAD.

Autrement dit, auth copié d’un déploiement non AEAD qui fonctionne, peut être sans objet dans un déploiement AEAD, et un déploiement AEAD peut encore échouer sur le canal de contrôle si la tls-auth clé ou sa direction est incorrecte. Comparez chaque réglage au pair plutôt qu’à une configuration mémorisée.

Comparez la correction avec la propriété que vous cédez

Désactiver l’authentification de paquets fait taire l’avertissement et supprime le contrôle qui a trouvé l’incohérence, ce qui n’est pas la même chose que réparer le profil. Demandez quelle propriété vous cédez et si la conception tient encore sans elle.

Lisez le premier événement pertinent aux deux extrémités avant de changer quoi que ce soit, puis ne changez que l’incohérence qu’il nomme.

Si la tentative suivante progresse jusqu’à une erreur de certificat ou de connexion, c’est un progrès et non une régression : la couche paquet est désormais d’accord et la connexion a avancé. Notez les réglages qui ont produit le changement, afin que la personne suivante hérite d’une explication plutôt que d’une énigme.