Windows et strongSwan : aligner les quatre transformations d’une proposition IKE

Les deux pairs prennent en charge AES, tous deux acceptent SHA-256, et le tunnel ne monte toujours pas. La proposition a échoué sur un composant que personne n’avait comparé, généralement le groupe d’échange de clés. Ce guide lit l’échange réel avant de changer quoi que ce soit, applique une seule politique ciblée et laisse un retour arrière qui restaure les paramètres précédents.

Lisez l’échec avant de changer de groupe

Une « erreur de correspondance de stratégie » est un résumé, pas un diagnostic. Elle signifie qu’aucune proposition mutuellement acceptable n’a été trouvée et ne dit rien sur le composant qui a été rejeté. Traitez-la comme le début de l’enquête et non comme une preuve sur un groupe précis.

La réponse se trouve généralement côté serveur. Un journal strongSwan au niveau approprié liste la proposition reçue du client et celle qu’il est configuré à accepter, et la différence entre les deux listes nomme le composant qui a échoué.

Ne supposez pas que le client offre ce qu’affirme un ancien message de forum. Le profil actif et sa stratégie installée décident de la liste proposée, et une version de Windows mise à jour peut offrir un ensemble différent de celui de la capture d’écran que vous copiez.

Écrivez les deux listes. Quatre positions de transformation et un groupe, c’est une liste courte, et la comparer ligne par ligne prend moins de temps que n’importe quelle expérience. Quatre positions se retiennent facilement. Un fichier journal, non.

Comparez chaque transformation, pas un seul nom familier

Une proposition IKE est un ensemble de choix qui doivent tous correspondre. Le chiffrement protège la négociation, l’intégrité ou un PRF l’authentifie, et un groupe Diffie-Hellman établit du matériel de clé neuf. Une proposition qui correspond sur les deux premiers et diffère sur le troisième reste inacceptable pour les deux pairs.

Les deux champs Windows que l’on confond ici appartiennent à des phases différentes. DHGroup s’applique à l’échange de clés IKE, tandis que PfsGroup s’applique à l’association enfant qui protège le trafic. Changer le second ne peut pas réparer un échec du premier.

Les noms de groupes diffèrent selon les implémentations, et c’est une source de confusion distincte. strongSwan écrit modp2048 et ecp256, tandis que Windows utilise des noms d’énumération comme Group14 et ECP256, donc une comparaison doit traduire avant de comparer. Tenez une note à deux colonnes avec les deux noms. La prochaine divergence se classe alors en quelques secondes.

Appliquez une politique complète et ciblée

L’instrument pris en charge pour un profil IKEv2 natif est une politique IPsec par connexion, définie comme un seul objet plutôt que champ par champ. Prévisualisez-la d’abord, appliquez-la ensuite et conservez les paramètres précédents dans le journal des changements.

Set-VpnConnectionIPsecConfiguration -ConnectionName "Northwind IKEv2" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup ECP256 -PfsGroup ECP256 -WhatIf

Le commutateur -WhatIf prévisualise la modification locale et n’applique rien. C’est utile et c’est aussi un piège courant, car un aperçu ne prouve que la validité syntaxique des paramètres pour l’applet de commande locale. Il ne dit rien de l’acceptation de la proposition résultante par la passerelle.

Alignez aussi la portée tant que vous y êtes. Une connexion dans le magasin de tous les utilisateurs a besoin du paramètre correspondant pour tous les utilisateurs, et modifier le profil par utilisateur portant le même nom affiché change un autre objet que le tunnel n’utilise pas.

Réglez ensuite le côté strongSwan sur le même ensemble avant de tester. Un changement coordonné aux deux extrémités est la seule version qui converge ; changer un seul côté et réessayer sans cesse produit un journal rempli du même refus.

Vérifiez l’échange et le renouvellement de clés séparément

Une connexion réussie est une observation, et le renouvellement de clés en est une autre. La négociation IKE initiale utilise un jeu de paramètres, et l’association enfant qui porte le trafic peut être renégociée plus tard avec sa propre politique. Une installation qui se connecte puis tombe au bout d’un moment est généralement le second cas.

ipsec statusall | grep -A6 "Northwind"
Get-VpnConnection -Name "Northwind IKEv2" | Format-List *

La première commande montre la vue du serveur sur les associations établies, y compris l’association enfant et sa durée de vie restante. La seconde montre ce que le profil client contient désormais, et c’est le seul moyen de confirmer que la politique définie est bien celle en vigueur.

Observez un renouvellement de clés complet avant de déclarer le succès. Cela suppose de laisser la connexion active assez longtemps pour que l’association enfant soit remplacée, puis de confirmer que le trafic continue. La plupart des écarts de politique se cachent à cette étape, car la négociation initiale peut réussir avec un ensemble que le renouvellement n’accepte pas.

Le retour arrière, c’est le jeu de paramètres précédent, pas un repli permissif. Si le client n’offrait qu’un groupe ancien et faible, la réponse est d’améliorer la politique commune du client et du serveur, non d’ajouter ce groupe à la passerelle où tout pair futur pourra négocier à la baisse jusqu’à lui.

Notez les quatre paramètres, le groupe, la portée de la connexion et le résultat du renouvellement. C’est une note courte, et c’est la différence entre un guide et une histoire sur la fois où le tunnel est monté.