tls-auth key-direction : 0 et 1 doivent différer, pas coïncider
Avec tls-auth, les deux extrémités ont besoin de directions opposées, 0 et 1, ou toutes deux doivent omettre le réglage. Le même numéro échoue, et tls-crypt ne l'utilise jamais.
Un côté du tunnel signe le canal de contrôle avec un emplacement de clé que l'autre côté ne vérifie jamais, et la connexion meurt sur une erreur d'authentification avant qu'un seul certificat soit échangé. Voilà à quoi ressemble un désaccord de direction sous tls-auth, et il est déterministe : les deux mêmes fichiers échouent à chaque tentative, depuis n'importe quel réseau. Rien dans le journal ne nomme l'option que vous cherchez, c'est pourquoi les gens reconstruisent des clés et réémettent des certificats qui n'ont jamais été cassés. La solution est de rendre les deux extrémités complémentaires, ou de les laisser toutes deux bidirectionnelles, plutôt que d'affaiblir la vérification.
La panne survient avant les certificats
Avec tls-auth, les deux pairs détiennent la même clé partagée et chacun utilise l'un des deux emplacements qui en dérivent : un emplacement signe les paquets de contrôle sortants, l'autre vérifie les entrants. La direction 0 et la direction 1 attribuent ces rôles dans l'ordre inverse, le couple doit donc être complémentaire pour que les contrôles HMAC concordent. Quand l'attribution est inversée d'un côté, le récepteur cherche une signature dans le mauvais emplacement et rejette le paquet. La session s'arrête là, c'est pourquoi l'erreur concerne l'authentification des paquets et non ce que produirait le magasin de certificats.
Le déterminisme compte pour le diagnostic, car un problème de temps ou de chemin laisse une empreinte différente : coupures intermittentes, un sens qui échoue ou une session qui meurt seulement sur un réseau donné. Un désaccord de direction échoue à la première poignée de main à chaque fois, et il échoue à l'identique sur une autre machine portant les deux mêmes fichiers. Lisez le journal avec --verb 4 et trouvez le premier paquet rejeté plutôt que la dernière ligne. Si ce rejet survient avant tout échange de certificats, la clé partagée et sa direction sont les deux choses qui valent une vérification.
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
Où vit le numéro
Le manuel OpenVPN 2.6 documente deux endroits pour la direction : le second argument de tls-auth quand la clé se trouve dans un fichier séparé, et une ligne key-direction autonome quand la clé est intégrée au profil. Les deux fixent la même valeur, un profil doit donc utiliser l'une ou l'autre forme, jamais les deux. L'omission est aussi un choix, et elle place les deux pairs dans un agencement bidirectionnel qui fonctionne quand aucun côté ne nomme de direction. Deux pairs portant le même numéro ne sont pas dans cet agencement : chacun s'attend à signer dans un emplacement et à vérifier dans l'autre, et tous deux le font dans le même sens.
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
La forme intégrée est une directive sur sa propre ligne, pas un attribut sur la balise d'ouverture du bloc de clé, et ajouter un argument à cette balise est une erreur, pas un changement de direction. L'emplacement compte aussi : la directive se place en dehors du bloc auquel elle appartient, une valeur écrite à l'intérieur du bloc est donc lue comme du matériel de clé. Copiez l'agencement voulu par le distributeur du profil au lieu d'inventer un couple, car un profil qui fonctionne contre un serveur est peut-être déjà mis en miroir de l'autre côté.
Ce que l'option laisse intact
Elle ne chiffre pas le trafic applicatif. tls-auth place un HMAC autour des paquets du canal de contrôle, tandis que le canal de données est protégé par des clés de session négociées pendant la poignée de main, une question de débit ou de chiffrement n'a donc rien à voir avec le numéro de direction. Le réglage n'ajoute pas non plus de seconde couche de chiffrement, et c'est cette hypothèse qui envoie les gens chercher une clé plus longue.
Elle ne s'applique pas à tls-crypt, un autre mécanisme de canal de contrôle avec ses propres options et sa gestion de clé, et elle ne dit rien de l'identité du certificat d'un pair. Une correspondance de direction qui fonctionne ne prouve donc que l'accord des deux extrémités sur la manière d'authentifier le canal de contrôle, pas que la chaîne de confiance a été validée.
Alignez le couple, puis reconnectez
Comparez les deux configurations avant d'en modifier une, car modifier le côté déjà correct double le travail. Le grep ci-dessous montre quel mécanisme chaque fichier choisit ; l'exécution détaillée montre si le canal de contrôle s'est authentifié. Conservez les deux sorties, afin que le prochain changement puisse être comparé à un état connu.
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
Redémarrez les deux pairs après tout changement, car ces options sont lues une fois au démarrage et recharger un côté laisse le couple incohérent pendant toute la durée de l'ancienne session. Si le déploiement fonctionne actuellement sans direction configurée, ajouter le réglage sur un pair reproduit la panne avec laquelle vous avez commencé ; soit vous laissez les deux tranquilles, soit vous configurez les deux. Changez une extrémité à la fois et conservez le fichier précédent, pour qu'une régression soit un retour de deux minutes plutôt qu'une reconstruction.
Notez le mécanisme, le fichier de clé et la direction de chaque extrémité dans les notes de déploiement, sinon la personne suivante lira deux fichiers semblables et supposera que les numéros doivent concorder entre eux. La direction est un détail de coordination, pas une amélioration de sécurité : elle sépare les deux directions du canal de contrôle et ne fait rien d'autre.