Comparer deux profils OpenVPN sans divulguer les clés

Deux profils, l'un se connecte et l'autre non, et le moyen rapide de voir pourquoi est un diff. Le problème, c'est que le même diff imprime la clé privée en ligne, la clé statique et tout bloc d'identifiants que le fichier contient, et les gens collent la sortie dans un chat avant de s'en apercevoir. Décider de ce que vous comparez vient avant d'exécuter la commande. Comparez la structure et les rôles sur des copies protégées, et construisez un fichier expurgé séparé quand quelqu'un d'autre doit le voir.

Ce qu'un fichier .ovpn contient réellement

Un fichier .ovpn est une configuration avec des blocs en ligne facultatifs. Il peut contenir un certificat CA, un certificat client, une clé privée, une clé tls-auth ou tls-crypt, et des directives qui pointent vers des fichiers externes ou demandent des identifiants. Deux fichiers peuvent sembler presque identiques et ne différer qu'à l'intérieur d'un bloc, ou par une directive qui change entièrement le transport. Le nombre de lignes ne vous dit rien de ce qui s'est produit.

Une différence à l'intérieur d'un bloc de clé n'est pas une preuve publique de quoi que ce soit. Un certificat réémis et un certificat avec une nouvelle clé peuvent produire la même forme de changement, donc l'écart de bloc vous dit que le matériel est différent, pas quelle décision l'a produit. Traitez-le comme un signal pour comparer des champs, pas comme une conclusion.

Comparez par rôle, pas par ligne

Suivez l'ordre propre de la connexion : d'abord le point de terminaison et le transport, puis la confiance et l'identité attendue, puis l'authentification utilisateur, puis les routes, le DNS et les crochets de script. Cette séquence correspond à ce que fait le client, donc la première différence que vous rencontrez est la première chose qui a pu casser la connexion. Comparer par ordre alphabétique, au contraire, disperse les réglages liés dans toute la sortie.

Une passe consciente des champs examine ces éléments, dans cet ordre. Tout ce que le client demande de façon interactive relève de la ligne d'authentification, pas des lignes de confiance.

• remote, proto et le port, y compris chaque bloc de connexion.
• ca et cert : émetteur, sujet et date d'expiration.
• Si une clé privée est présente, jamais ce qu'elle contient.
• tls-auth ou tls-crypt présence et sens de la clé.
• Directives d'authentification, y compris toute référence à un fichier d'identifiants.
• Routes, options DNS et crochets de script exécutés à la connexion.

Quand un fichier contient plusieurs blocs de connexion, gardez chaque option avec son point de terminaison. Comparer seulement la première ligne remote peut manquer l'alternative que le client choisit réellement sur ce réseau.

Pourquoi un simple diff est le mauvais outil

Un simple diff est fait pour le texte, pas pour les secrets. Il imprimera volontiers une clé privée dans l'historique de l'écran, et il ne vous dira pas que la directive que vous fixez n'a rien à voir avec la panne. Les extractions de champs sont à la fois plus sûres et plus lisibles, car le matériel de certificat peut être comparé comme des métadonnées plutôt que des octets.

openssl x509 -in ca.crt -noout -subject -issuer -enddate
openssl x509 -in client.crt -noout -subject -issuer -enddate
grep -E '^(remote|proto|port|tls-auth|tls-crypt|route|dhcp-option)' profile.ovpn

Les deux premières commandes impriment l'identité et la validité sans toucher à la clé, leur sortie peut donc être collée sans risque. Le grep imprime les noms et les valeurs des directives mais jamais les corps des blocs, ce qui en fait la bonne première passe quand vous soupçonnez une différence de transport ou de routage. S'il faut comparer un bloc lui-même, comparez son hash plutôt que son contenu.

Construisez une copie expurgée pour le ticket

Retirez les vrais secrets et les identifiants inutiles tout en gardant les noms de champs et assez de structure pour expliquer la différence. Un marqueur de même forme révèle encore où se trouve le matériel et sa longueur, alors décidez si même cela est acceptable. Vérifiez la pièce jointe finale elle-même plutôt que de faire confiance à la commande dont vous vous souvenez. Ne modifiez pas l'original de travail juste pour produire un exemple, car un profil expurgé n'est pas forcément exécutable et ne doit jamais être réimporté.

Gardez les originaux identifiables par nom de fichier et hash au lieu de les copier dans trois répertoires aux noms similaires. Une chaîne de hash suffit à prouver quel fichier a été examiné et ne coûte rien si elle fuit. Élaguez les copies une fois le changement clos, pour que la personne suivante hérite d'un seul fichier faisant autorité.

Gardez la comparaison liée à une panne

Une comparaison vaut son coût quand elle répond à une question sur un import ou une panne de connexion. Nommez d'abord l'étape qui échoue, puis comparez seulement les champs dont cette étape dépend ; rassembler tous les identifiants du client dans un seul répertoire rend la prochaine fuite plus probable et le prochain diagnostic plus lent. Plus la question est étroite, plus la liste des champs capables d'y répondre est courte.

Si un nouveau fichier vient de l'opérateur, confirmez son canal de distribution avant de remplacer le matériel de confiance. Après le changement, inspectez la copie importée que le client a réellement choisie et le résultat négocié, car une directive peut être ignorée ou lue différemment par une autre version du client. Le fichier sur disque n'est pas la preuve de la connexion qui a tourné. La sémantique des directives se trouve dans le manuel OpenVPN 2.6.