Lignes de chiffrement obsolètes dans les anciens profils VPN : à lire avant de copier
Les directives survivent aux changements de version avec des sens différents, ou sans aucun sens. Vérifiez quel client a écrit le profil et ce que le tunnel a réellement négocié.
Ce profil a été écrit en 2016, et il s’importe toujours et il se connecte toujours. C’est exactement pour cela que personne ne le regarde. Le client qui lisait autrefois ces directives a disparu depuis longtemps, et la version actuelle peut en interpréter plusieurs différemment.
Qu’un fichier survive ne signifie pas qu’une configuration est à jour. Séparer ces deux idées, c’est l’essentiel du travail.
Déterminez quel client a écrit le profil
Commencez par l’émetteur et la version. Le sens d’une directive est défini par l’implémentation qui la lit. Une ligne qui choisissait autrefois un algorithme peut devenir une liste de secours, un avertissement ou une erreur stricte. La version qui l’interprète décide du résultat.
OpenVPN en est l’illustration la plus claire. La version 2.5 a introduit data-ciphers et changé la façon dont l’ancienne directive cipher participe à la négociation. Un profil qui ne porte que cipher AES-128-CBC fait désormais une proposition bien plus étroite que ne l’entendait son auteur.
Lisez les notes de version pour le réglage qui avertit ou échoue désormais. Un avertissement dans le journal est un fait sur la version actuelle, et il pèse plus que le souvenir de quiconque sur la raison de l’ajout de cette ligne.
Regardez ce qui a réellement été négocié
La réussite de l’importation prouve l’analyse, pas la politique. Le résultat négocié apparaît dans le journal du client une fois la connexion établie. Il peut différer des deux extrémités du fichier de configuration.
# OpenVPN: what did this session agree on?
sudo journalctl -u openvpn-client@office --since '5 min ago' | grep -i 'cipher\|Data Channel'
# which directives does the profile actually carry?
grep -n -E 'cipher|auth|tls-|dh ' office.ovpnUne importation acceptée qui écarte silencieusement une directive laisse un profil qui se lit d’une manière et se comporte d’une autre. C’est cet écart qui fait qu’un document étiqueté comme durci négocie quelque chose de plus faible que ce que son propre texte affirme. Le journal est le seul endroit où la différence apparaît. Lisez-le avant de faire confiance au fichier.
Mettez à niveau l’agencement, pas la ligne
Prenez le profil maintenu par l’opérateur au lieu d’assembler des noms d’algorithmes jusqu’à ce que l’importation cesse de se plaindre. Ajouter des lignes par essais inverse le sens de la correction. Cela adapte le client à un serveur inconnu au lieu d’établir ce que le serveur prend en charge.
Le serveur peut aussi avoir besoin de la mise à niveau coordonnée. Un client actuel ne peut pas créer de prise en charge pour une proposition que l’autre extrémité n’offre jamais. Aucune option côté client ne remplace une passerelle qui n’a pas été mise à jour.
Ce qu’il ne faut pas sacrifier, c’est la vérification. Supprimer les contrôles de certificats, désactiver la vérification du nom d’hôte ou couper les mises à jour pour maintenir un ancien profil en vie transforme un problème de compatibilité en problème de confiance. Cela se produit généralement une petite modification à la fois.
Confirmez le résultat et consignez l’exception
Après le changement, inspectez à nouveau la suite négociée et testez la ressource pour laquelle le tunnel existe. Un profil qui négocie ce que vous vouliez et n’atteint toujours pas le service a un problème de routage ou d’identité. Il n’a pas de problème cryptographique.
Conservez la configuration précédente réputée bonne dans un endroit protégé. Une comparaison n’est possible que tant que l’ancien fichier existe encore.
Documentez toute exception de compatibilité avec un responsable et une date de révision. Un aménagement temporaire que personne ne possède devient une politique permanente. La prochaine personne qui lira le fichier supposera qu’il a été choisi délibérément.