Un profil qui fonctionnait depuis des années refuse soudain de démarrer, et le message nomme une directive que personne ne se souvient avoir ajoutée : key-method. Le résultat de recherche suivant suggère d’ajouter key-method 2 pour la compatibilité, un conseil d’une autre époque. L’analyseur qui a rejeté la ligne est actuel, et il ne connaît pas du tout cette option. Retirer la ligne corrige le démarrage, et cela ne change rien à la façon dont les deux pairs protègent la session.

Cet écart entre ce que contient un profil et ce que le protocole fait réellement est tout le sujet ici, et il explique plusieurs autres modifications que les gens font en même temps. Il explique aussi pourquoi ces modifications arrivent généralement en bloc.

Le symptôme est une erreur d’analyse, pas un échec de poignée de main

Les options sont lues avant l’envoi du moindre paquet. Un profil contenant une directive inconnue échoue à cette étape, si bien que le processus n’atteint jamais le réseau et ne produit jamais d’erreur de poignée de main. La formulation identifie généralement l’option et le fichier, ce qui en fait l’une des pannes les plus faciles à attribuer. Aucun paquet, aucune route et aucun pare-feu n’y sont impliqués.

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

Si le message nomme la directive, le diagnostic est terminé : le fichier contient quelque chose que cette version n’accepte pas. Si le message nomme plutôt un chemin de fichier, le problème est une inclusion ou une clé manquante, ce qui est une autre section de la même étape de démarrage.

Ce qu’il ne faut pas en conclure, c’est que le client ou le serveur a besoin d’un mode de protocole plus ancien. Un échec d’analyse est un problème de vocabulaire entre votre fichier et le binaire, et le binaire, dans ce cas, a simplement abandonné un mot de son vocabulaire.

Directive et format de transmission sont deux choses différentes

L’ancienne option key-method choisissait comment l’échange de clés TLS était encadré, et l’échange moderne est la méthode multi-paquets que cette option demandait autrefois. L’option a disparu parce qu’elle ne choisissait plus rien ; le format qu’elle nommait est devenu le seul. Retirer la ligne laisse donc la session avec le même encadrement qu’avant. Une modification de texte ne peut pas changer cela dans un sens ou dans l’autre.

C’est pourquoi réintroduire un ancien binaire pour « restaurer » la méthode 2 est la mauvaise réparation. Elle ne restaure rien d’autre qu’un analyseur plus ancien avec des valeurs par défaut plus anciennes, et elle vous coûte les correctifs venus après. Le même raisonnement s’applique à l’affaiblissement d’un contrôle de certificat ou d’une liste de chiffrement dans l’espoir que la connexion revienne.

Une vérification utile est la version et la configuration analysée, pas la présence du mot dans le fichier :

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

Quoi supprimer, et dans quel fichier

Modifiez le fichier que le processus en cours lit réellement, et ce fichier uniquement. Sur les systèmes empaquetés, il s’agit généralement du profil situé dans le répertoire client ou serveur nommé par l’unité, et non d’une copie dans votre répertoire personnel que vous gardez pour référence. Un profil généré peut aussi être reconstruit à partir d’un modèle, donc une modification faite seulement sur la copie déployée reviendra après la prochaine exécution de provisionnement.

Supprimez la ligne obsolète et laissez tranquilles le point de terminaison, les certificats, la politique de chiffrement et les réglages du canal de contrôle. Ce sont des options prises en charge dont le processus a besoin, et elles ne sont pas impliquées dans l’erreur d’analyse. Si le même profil contient d’autres directives que vous ne reconnaissez pas, vérifiez chacune par rapport à la version que vous exécutez plutôt que d’en supprimer un groupe jusqu’à ce que le processus démarre.

Démarrez ensuite l’instance voulue et lisez sa sortie de démarrage. Un démarrage propre avec l’écouteur présent est la confirmation que cette étape est terminée ; un test client ensuite répond à une autre question.

Un profil rejeté et un client rejeté se ressemblent

Deux pannes produisent des fils de support similaires et exigent des preuves différentes. Un serveur qui rejette sa propre configuration ne démarre jamais, donc aucun client ne peut s’y connecter. Un serveur qui démarre bien et refuse un client tourne, et son journal contient la raison : un problème de certificat, une option poussée que le client n’accepte pas, une incompatibilité de chiffrement.

L’option supprimée n’est pas un diagnostic pour le second cas, et s’y raccrocher fait perdre la même heure deux fois. Si le journal du client montre le rejet du serveur, lisez ce rejet ; s’il montre une erreur locale, le profil du client est le fichier à inspecter. S’accrocher à une directive qui n’existe plus retarde les deux enquêtes du même montant.

Des questions de compatibilité auxquelles la ligne n’a jamais répondu

Les profils qui circulent avec cette directive portent généralement une histoire sur une plateforme précise, et l’histoire survit à la raison technique. Un client mobile ou de bureau a toujours besoin de un profil complet pris en charge : une chaîne de certificats de confiance, un chiffrement de données que les deux extrémités acceptent, un mode de canal de contrôle que les deux extrémités implémentent, et aucune directive que la version du client rejette. Rien de tout cela n’est décidé par la présence ou l’absence de l’ancienne ligne key-method.

La compression est une question de politique distincte de même forme. Supprimer une ligne key-method ne dit rien sur le fait qu’une directive de compression soit prise en charge ou acceptable dans votre déploiement, et les deux décisions doivent être prises indépendamment. Supprimer plusieurs réglages liés à la sécurité d’un coup jusqu’à ce que quelque chose se connecte, c’est ainsi qu’un profil qui fonctionne devient un profil inexpliqué.

Tenez un court relevé de ce que vous avez supprimé et pourquoi : l’option, la version qui l’a rejetée et la commande qui a montré l’erreur. La prochaine personne qui héritera du profil aura besoin d’exactement ces trois faits, et il est moins coûteux de les écrire maintenant que de les reconstituer plus tard.

Articles similaires