Profil IKEv2 Mac : définir les deux dictionnaires SA, puis tester

Une connexion réussie prouve seulement que les deux extrémités ont trouvé un ensemble de valeurs qu’elles acceptent. Un profil IKEv2 Mac géré porte deux dictionnaires d’association de sécurité, la passerelle a sa propre liste de propositions, et la connexion réussit sur toute intersection que les deux côtés autorisent. Effectuez les vérifications ci-dessous dans l’ordre, et arrêtez-vous là où les deux extrémités sont en désaccord plutôt que d’ajouter un autre chiffrement pour voir s’il aide. Chaque étape écarte une couche différente du profil.

Vérifiez les deux dictionnaires avant de modifier une valeur

Dans les réglages IKEv2 de la charge VPN, IKESecurityAssociationParameters décrit l’association IKE et ChildSecurityAssociationParameters décrit la Child SA. Le schéma d’Apple indique que les paramètres IKE s’appliquent aussi à la Child SA lorsque le second dictionnaire est absent. Cet héritage est pratique, et c’est aussi ainsi qu’un profil finit avec des valeurs que personne n’a choisies consciemment.

<key>IKESecurityAssociationParameters</key>
<dict>
  <key>EncryptionAlgorithm</key><string>AES-256</string>
  <key>IntegrityAlgorithm</key><string>SHA-256</string>
  <key>DiffieHellmanGroup</key><integer>14</integer>
  <key>LifeTimeInMinutes</key><integer>1440</integer>
</dict>

Écrivez les deux lignes dans le registre de déploiement même lorsque les valeurs correspondent. Un relecteur peut alors voir que la Child SA a été examinée plutôt qu’héritée par accident, et une modification ultérieure d’une ligne ne change pas silencieusement l’autre.

Vérifiez ce que signifie chaque clé avant de copier une chaîne

Les quatre clés ne sont pas interchangeables avec une chaîne de proposition d’un autre produit. Les noms d’algorithmes dépendent de l’implémentation, traduisez donc l’ensemble choisi via la syntaxe documentée de chaque côté au lieu de coller une proposition strongSwan dans un champ Apple.

« Utilisez le plus grand numéro de groupe » n’est pas une méthode de sélection. Les identifiants de groupe désignent des constructions différentes, et un numéro plus élevé ne signifie pas simplement une version plus forte de la même chose. Faites approuver la combinaison complète par le propriétaire de la passerelle, car un ensemble est valide ou invalide dans son ensemble. Un chiffrement approuvé avec un groupe non approuvé est une proposition non approuvée, et elle échouera ou reviendra silencieusement à quelque chose qu’aucun des deux côtés n’a documenté.

Vérifiez les limites de version qui retirent les anciens algorithmes

Le schéma de charge d’Apple limite DES, 3DES, SHA1-96, SHA1-160 et les groupes Diffie-Hellman 1, 2 et 5 aux versions de macOS antérieures à 26. Un profil repris d’un déploiement plus ancien peut encore contenir l’une de ces valeurs et se connecter encore à une ancienne passerelle, et c’est précisément le cas où une configuration fonctionnelle cache une date de retrait.

Obtenez les versions de Mac prises en charge et la politique de propositions maintenue par la passerelle avant de construire le profil. Choisissez ensuite l’intersection et consignez pourquoi les options restantes ont été exclues. Une note indiquant « la passerelle propose encore le groupe 2 pour les clients anciens » vaut plus qu’une liste de chiffrements sans historique. Sans cette note, le relecteur suivant ne peut pas distinguer une exception délibérée d’un oubli.

Vérifiez l’authentification sur sa propre ligne

Un accord sur une proposition ne répare pas une identité de serveur erronée. L’identité de la passerelle, la confiance dans le certificat et les identifiants de l’utilisateur ou de l’appareil sont des décisions distinctes, et chacune peut échouer alors que les algorithmes sont parfaitement alignés. Changer l’algorithme de signature d’un certificat n’est pas le même acte que choisir l’algorithme de chiffrement IKE, même si les deux apparaissent dans la même revue.

Gardez l’identité de serveur attendue à côté de la proposition dans le registre. Lorsqu’une connexion échoue après un changement de certificat, ce couplage indique à la personne suivante si la négociation ou la décision de confiance a bougé en premier.

Déployez une révision et inspectez ce qui a été négocié

Utilisez le flux de distribution pris en charge par l’organisation et consignez l’identifiant du profil, la révision, les versions de Mac cibles et la politique de passerelle correspondante. Donnez aux appareils qui ne peuvent pas se connecter un chemin de récupération documenté, et évitez de créer un second profil du même nom dont personne ne peut établir la propriété.

Lors de l’acceptation, inspectez la configuration installée et les associations IKE et Child négociées via des diagnostics approuvés. Forcez ensuite un renouvellement contrôlé, car la première connexion prouve seulement que la négociation initiale a fonctionné ; une incohérence de durée de vie apparaît généralement au premier changement de clé, longtemps après l’approbation du déploiement.

Conservez l’ensemble accepté avec le registre de révision. La prochaine mise à jour de macOS ou le prochain changement de passerelle dispose alors d’une base de comparaison au lieu d’un profil qui se connecte simplement par hasard aujourd’hui.