Comment OpenVPN data-ciphers choisit le chiffrement du canal de données

Le tunnel monte, le journal affiche un chiffrement et la revue du profil continue. Puis une mise à niveau arrive chez un pair et le même profil échoue avec un message sur l'absence de chiffrement partagé, ce qui envoie les gens chercher une directive à supprimer. La chose utile à comprendre est que data-ciphers décrit une négociation, pas un réglage. Un côté propose une liste, l'autre y choisit, et le résultat est un seul algorithme que les deux prennent en charge. Lire cet échange explique la plupart de ces échecs avant que vous ne changiez une ligne.

Deux canaux, deux configurations

Une OpenVPN session a un canal de contrôle et un canal de données. Le canal de contrôle exécute la poignée de main TLS qui authentifie les pairs et négocie les clés. Le canal de données chiffre les paquets qui transportent votre trafic.

data-ciphers configure le second. Le canal de contrôle a ses propres options, et les contrôles d'identité du profil sont une troisième préoccupation, distincte. Modifier l'un ne corrige pas l'autre, et c'est pourquoi un profil peut sembler correct et échouer malgré tout à une étape précise.

Gardez les trois dans des cases séparées lorsque vous lisez un fichier de configuration.

Lisez la négociation dans le journal

Le journal du client nomme les deux résultats lorsque la connexion réussit. Une ligne rend compte du canal de contrôle et de ses détails TLS, et une autre du chiffrement du canal de données qui a été sélectionné.

Lisez les deux, car ils répondent à des questions différentes. Une défaillance du canal de contrôle arrête la connexion avant qu'un chiffrement de données n'importe. Une divergence du canal de données apparaît après une poignée de main réussie, avec un message sur l'absence de chiffrement partagé.

Comparez ensuite les listes proposées des deux côtés. Un nom que la version d'un pair ou son socle cryptographique ne fournit pas ne peut pas être sélectionné, peu importe sa place dans la liste de l'autre pair.

Comment la sélection se produit réellement

Le serveur pousse sa liste data-ciphers vers le client pendant la poignée de main, et le client sélectionne la première entrée de cette liste qu'il prend aussi en charge. L'ordre appartient donc à la configuration du serveur, non à celle du client.

Ce détail explique une classe de résultats déroutants. Réordonner la liste du client ne change rien tant que la liste du serveur décide. Ajouter un chiffrement que le client ne peut pas fournir ne change rien non plus, car le client doit pouvoir utiliser l'entrée qu'il choisit.

Les versions plus récentes ont changé la liste par défaut et renommé l'option qui la contenait, si bien que deux pairs sur des versions différentes peuvent être en désaccord sans que personne n'édite un profil. Vérifiez la version de chaque côté avant de supposer une faute de frappe.

Une liste n'est pas un classement de force dans l'abstrait. C'est un ensemble de candidats, et celui qui est sélectionné est la première entrée mutuellement prise en charge dans l'ordre du serveur. C'est pourquoi deux listes qui semblent différentes peuvent négocier le même chiffrement. C'est aussi pourquoi deux listes qui semblent identiques peuvent échouer.

Les pairs plus anciens ont besoin d'un repli délibéré

Un pair qui ne peut pas négocier du tout, parce qu'il est antérieur au mécanisme ou l'a désactivé, a besoin d'un arrangement de compatibilité documenté. L'option de repli existe exactement pour ce cas et s'applique aux pairs qui ne participent pas à la négociation.

Ce n'est pas la même chose que d'activer tous les chiffrements hérités pour faire disparaître un message. Une liste large affaiblit la session pour chaque pair, y compris ceux qui auraient négocié quelque chose de fort.

Coordonnez les deux côtés au lieu de modifier des noms d'algorithmes sans rapport. Si une mise à niveau du serveur a retiré une ancienne option, la correction relève du plan de versions, pas d'une course côté client.

Gardez la vérification intacte

Une divergence du canal de données n'est pas une raison d'accepter un serveur non vérifié. La vérification du certificat, le nom de serveur attendu et les réglages de protection du canal de contrôle sont distincts du choix du chiffrement et doivent survivre à tout changement de compatibilité.

Notez ensemble le chiffrement de données négocié, la version du client et la version du serveur, afin que la prochaine comparaison parte des faits et non du fichier de profil.

Après une correction prise en charge, testez la connexion initiale et une renégociation, car une session qui s'établit une fois peut encore échouer lors du renouvellement des clés.

Si le tunnel s'établit et que les sites échouent encore, le chiffrement n'est plus le suspect. Continuez avec le routage et le DNS. Ordre du travail : lisez les deux lignes de journal, comparez les deux listes, vérifiez les versions, ajoutez un repli uniquement pour un pair qui en a besoin, puis retestez le chemin de renouvellement.