Chiffrements Windows et strongSwan : viser la bonne couche

Les deux extrémités annoncent AES-128 et le tunnel refuse toujours de monter. CBC et GCM sont des transformations différentes qui partagent par hasard une même longueur de clé, et un client qui en propose une ne satisfait pas une passerelle qui n'accepte que l'autre. Le mot AES décrit une famille, pas un accord.

Il existe aussi un second axe, et c'est lui qui produit les erreurs déroutantes.

Deux couches, deux listes indépendantes

IKE protège la négociation elle-même, tandis que l'association enfant protège le trafic qui vous intéresse vraiment. Windows expose la première comme méthode de chiffrement et méthode d'intégrité, et la seconde comme constantes de transformation de chiffrement et d'authentification. Ces champs ne sont pas des alias l'un de l'autre, et une valeur valide dans l'un peut être dépourvue de sens ou erronée dans l'autre. Lire le profil avec cette séparation en tête élimine l'essentiel de la confusion.

La conséquence pratique est que vous pouvez avoir une politique d'échange de clés parfaitement acceptable et une politique de canal de données que le pair n'acceptera pas. Une liste négocie ; l'autre protège les paquets. Modifier une valeur dans la première n'a aucun effet sur la seconde, quelle que soit la ressemblance des deux dans une boîte de dialogue de configuration.

Notez les deux listes avant de les comparer à la passerelle. Une comparaison faite de mémoire, c'est ainsi qu'un champ est modifié deux fois et l'autre jamais. Gardez la console de la passerelle ouverte à côté du profil.

Lisez l'erreur à côté des propositions

L'étape qui a échoué vous indique quelle liste examiner. Un refus lors de l'échange de clés initial est un problème de proposition IKE, et il survient avant qu'aucune association enfant n'existe. Un échec pendant la négociation de l'association de trafic protégé est un problème de proposition ESP, et l'échange de clés a déjà réussi. Un message générique de correspondance de politique du client ne nomme aucune des deux étapes, c'est pourquoi la vision propre à la passerelle est la plus utile.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager

Comparez la proposition reçue, la proposition configurée et celle qui a été sélectionnée pour cette tentative unique. Trois listes différentes comptent ici, et seule la dernière décrit ce qui a réellement servi. Citez-la mot pour mot dans le ticket plutôt que de la résumer.

Gardez CBC et GCM comme alternatives distinctes

Une passerelle délibérément autorisée à accepter l'une ou l'autre famille a besoin de deux propositions, pas d'une. Dans strongSwan, une virgule sépare les alternatives et un trait d'union relie les composants d'une même suite. Combiner les deux familles avec des traits d'union produit une proposition impossible au lieu de deux acceptables.

proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256

La première alternative porte un chiffrement authentifié et nomme encore une fonction pseudo-aléatoire, car la dérivation de clé en a besoin même lorsque l'intégrité vient du chiffrement. La seconde alternative est un chiffrement classique avec un algorithme d'intégrité distinct. Toutes deux restent tributaires de ce que prend en charge l'implémentation cryptographique chargée.

Une proposition ESP n'est pas une proposition IKE renommée

Le jeton de chiffrement semble identique dans les deux listes, et presque rien d'autre ne se transpose. Une proposition ESP n'a pas de fonction pseudo-aléatoire d'échange de clés, et ses exigences d'intégrité et de confidentialité persistante sont argumentées face à la politique Windows d'en face plutôt que recopiées de la ligne IKE. Traduire mécaniquement une liste dans l'autre produit quelque chose qui valide et ne négocie jamais.

Choisissez une direction et tenez-vous-y. Soit la passerelle conserve une politique GCM uniquement et le client déploie une politique compatible complète, soit la passerelle accepte les deux familles et le client conserve sa suite existante. Activer un repli que la politique de sécurité interdit n'est pas un correctif, aussi vite efface-t-il l'erreur.

Vérifiez les deux suites, puis un renouvellement de clé

Confirmez séparément la suite d'échange de clés sélectionnée et la suite de trafic sélectionnée, car elles viennent de listes différentes et peuvent réussir indépendamment. Laissez ensuite un renouvellement de clé se produire et confirmez-le aussi. Une première poignée de main qui fonctionne et un renouvellement de clé qui échoue décrivent un ensemble de propositions seulement partiellement acceptable.

Conservez cette preuve avec le changement. Une déconnexion récurrente a besoin de son propre enregistrement d'échange échoué avant que quiconque accuse une minuterie ou un défaut de plateforme.