AES-256-GCM introuvable : capacité du client ou négociation ?

Un profil OpenVPN qui fonctionne ailleurs signale que AES-256-GCM est introuvable, ou que les pairs ne partagent aucun chiffrement, et le premier réflexe est de modifier le profil. Ces deux messages décrivent des défaillances différentes. L’un dit que le programme local n’a pas cet algorithme ; l’autre que les deux extrémités ont des algorithmes mais aucun choix commun. Modifier le profil ne règle ni l’un ni l’autre tant que vous ne savez pas lequel vous avez.

Lisez le texte exact de l’erreur et le binaire qui l’a produite.

Déterminez quelle erreur vous avez

Le message sur un chiffrement introuvable vient de l’analyse des options sur la machine locale, avant qu’aucun paquet ne soit envoyé. Il signifie que l’exécutable devant vous, ou la bibliothèque à laquelle il est lié, n’offre pas cet algorithme. Le message sur l’absence de chiffrement commun arrive plus tard, pendant la négociation, et implique que les deux côtés prennent en charge des chiffrements mais ne s’accordent sur aucun.

La distinction compte parce que l’un est un problème de version logicielle et l’autre un problème de configuration. Le premier se règle par un numéro de version. Le second se règle en comparant deux listes.

Un manque local de capacité

Les anciennes compilations communautaires précèdent les valeurs par défaut modernes, et une application de bureau peut embarquer son propre moteur, différent du paquet en ligne de commande installé à côté. Faites les vérifications sur l’exécutable qui a réellement lancé la connexion, puis choisissez une compilation prise en charge plutôt que d’apprendre un nouvel algorithme à un vieux binaire.

openvpn --version
openvpn --show-ciphers | grep -i gcm
openvpn --show-tls | head -5

Si AES-256-GCM n’apparaît pas dans cette liste, aucune ligne du profil ne l’ajoutera. La solution est un client plus récent ou une autre compilation, et les contraintes du pair plus ancien deviennent une question de conception à part.

Pour les clients basés sur OpenVPN 3, le moteur et les directives acceptées diffèrent de la ligne communautaire 2.x, si bien que le même texte de profil peut échouer pour des raisons sans rapport avec la liste des chiffrements.

Un manque de négociation

Quand les deux pairs listent l’algorithme, la question restante est quelle liste chaque côté propose. L’OpenVPN communautaire a renommé la directive de négociation : ncp-ciphers en 2.4 est devenu data-ciphers en 2.5, et en 2.6 l’ancienne ligne cipher sert surtout à la compatibilité et au repli, non à définir l’ensemble négocié.

C’est pourquoi modifier seulement une ancienne ligne cipher peut laisser la liste de négociation intacte. L’ancienne ligne compte encore pour le repli, ce qui est un travail distinct. Confondre les deux produit des modifications qui ne changent rien de visible.

openvpn --version | head -2
grep -n -E '^(data-ciphers|ncp-ciphers|cipher|tls-cipher)' server.conf client.ovpn

Comparez les listes des deux extrémités et le message de rejet du serveur. Si l’intersection est vide, alignez les listes délibérément au lieu de copier une valeur d’un article écrit pour une autre version. Une liste trop généreuse affaiblit silencieusement chaque connexion. Une liste trop étroite exclut le pair que vous vouliez garder.

Gardez la compatibilité explicite

Un repli pour un pair ancien est une décision qui a un coût : tout le déploiement accepte une option plus faible pour qu’un appareil puisse se connecter. Écrivez-le comme tel et limitez-le au pair qui en a besoin.

Deux conditions décident du résultat. Si l’erreur est locale, remplacez la compilation. Si l’erreur est négociée, alignez les listes des deux côtés et notez quelles versions vous prenez en charge.

Rapportez ensuite l’erreur exacte avec la sortie de version et de capacités jointe. Ce couple sépare un algorithme absent d’un désaccord et arrête la prochaine série de modifications spéculatives avant qu’elle ne commence.