Une directive OpenVPN par ligne, et pourquoi le retour à la ligne trompe
Un écran à retour à la ligne souple n’est pas un saut de ligne dans le fichier. Vérifiez les vrais sauts de ligne avant de remplacer une section mal formée par le modèle d’un inconnu.
Un profil qui démarrait auparavant échoue maintenant avec une erreur d’options, et la ligne citée par l’analyseur semble parfaitement raisonnable à l’écran. C’est le piège : un fichier de configuration est une liste de lignes physiques, chacune portant un mot-clé d’option et ses arguments, et une longue ligne enveloppée par un éditeur est identique à deux lignes jusqu’à ce qu’on regarde les octets. Rien du réseau, du certificat ou du tunnel n’entre en jeu dans cette classe de panne. Deux lignes identiques à l’écran peuvent différer d’un seul octet.
Passez les vérifications ci-dessous dans l’ordre et arrêtez-vous à la première qui échoue. Chacune coûte moins cher que la suivante, et chacune élimine une explication différente.
Une ligne, une directive
L’analyseur lit une ligne, prend le premier mot comme option et traite le reste comme les arguments de cette option. Une ligne comme cert server.crt port 1194 n’est donc pas deux instructions à la suite. C’est une option cert avec trois arguments, et le troisième n’est pas un nom de fichier que l’option accepte. Lire l’erreur comme un saut de ligne manquant est juste ; la lire comme une directive manquante ne l’est pas.
# malformed: one option, three arguments
cert server.crt port 1194
# intended: two options, one argument each
cert server.crt
port 1194
Ces deux lignes corrigées sont un fragment, pas une configuration. Elles servent à montrer où se situe la frontière. Toute directive ordinaire d’un profil suit la même règle, et une ligne qui en réunit deux produit soit une erreur d’argument, soit une valeur que l’option n’attendait pas.
Prouvez que le saut de ligne est réel
Les éditeurs enveloppent pour l’affichage. Certains insèrent aussi des sauts forcés lors du collage, d’autres non, si bien que le même résultat visuel peut venir de deux fichiers très différents. Affichez les fins de ligne et comptez les lignes avant de changer quoi que ce soit. Mesurer coûte une commande ; deviner coûte une soirée.
cat -A /etc/openvpn/server/lab.conf | sed -n '10,20p'
awk 'NR>=10 && NR<=20 {printf "%d:%s\n", NR, $0}' /etc/openvpn/server/lab.conf
Dans la première sortie, chaque véritable saut de ligne apparaît comme un marqueur $, si bien qu’une ligne enveloppée mais non coupée n’affiche aucun marqueur là où votre écran renvoie à la ligne. La seconde commande imprime des lignes numérotées, le moyen le plus rapide de comparer ce que l’analyseur signale avec ce que contient le fichier.
Des espaces supplémentaires ne créent pas non plus de directive. L’indentation est cosmétique, et une ligne qui commence par un espace reste la même option unique. Si le message d’erreur indique un numéro de ligne, lisez cette ligne exacte plutôt que le paragraphe auquel elle appartient.
Citez un chemin, pas une liste de directives
Les guillemets servent aux arguments qui contiennent des espaces, pas à regrouper des options. Un chemin de certificat comportant un espace a besoin de ses propres guillemets ; deux directives partageant une paire de guillemets restent une seule ligne mal formée.
cert "/etc/openvpn/pki/lab certs/server.crt"
key "/etc/openvpn/pki/lab certs/server.key"
Vérifiez les noms d’options en même temps que la disposition, car une ligne jointe peut produire un jeton d’apparence plausible qui n’a jamais existé. La directive de port est port ; un profil qui utilise autre chose pour la même idée échouera même après la correction des limites de ligne. Quand un nom semble inconnu, comparez-le à la liste des options de la version que vous exécutez plutôt qu’à un exemple de forum.
Gardez les blocs intégrés comme des blocs
Les profils peuvent intégrer des certificats et des clés, et ces blocs sont des données, non de la configuration. Les lignes PEM d’un bloc ne sont pas des options à aplatir, à réindenter ou à joindre, et les marqueurs de bloc doivent rester sur leurs propres lignes.
Traitez un bloc intégré comme une zone opaque : corrigez les lignes d’options autour, laissez son contenu intact octet par octet et ne le collez jamais dans un fil d’assistance public. Si un outil de mise en forme a réécrit le bloc, restaurez-le depuis votre PKI plutôt que de le réparer à la main.
Réparez la plus petite section, pas le modèle
La réparation tentante consiste à remplacer tout le fichier par une configuration tirée d’un tutoriel qui « fonctionne ». Cela échange une ligne mal formée contre un ensemble de changements de politique que personne n’a relus : paramètres DH différents, réglages de compression, choix de chiffrement, écouteurs en double. Le problème d’origine est petit et local, et le remplacement ne l’est ni l’un ni l’autre.
Copiez le profil vers un fichier de travail protégé, corrigez les limites de ligne dans cette copie et laissez le propriétaire habituel du service la charger. Démarrez ensuite l’instance et lisez la première erreur, s’il y en a une, depuis le début.
openvpn --config /etc/openvpn/server/lab.conf --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log
Quand l’étape d’analyse passe, la panne suivante concernera un fichier, un certificat ou un chiffrement plutôt que le vocabulaire, et c’est un vrai progrès. Conservez la copie de travail et une note d’une ligne sur ce qui a été joint ; le même collage se reproduira pour quelqu’un d’autre de la même équipe.