IKEv2 sous Windows et FortiGate : trois réglages que les gens fusionnent

Un accord IKEv2 entre un client Windows et une passerelle FortiGate continue d’échouer, et la recherche d’un numéro qui ne correspond pas produit une liste de numéros encore plus longue. La liste ne devient gérable que lorsqu’on la divise en trois lignes qui échouent indépendamment : l’échange de clés qui protège IKE, la protection appliquée à la CHILD SA et l’authentification qui prouve qui est chaque partie. Les numéros de groupe apparaissent dans deux de ces lignes et signifient des choses différentes.

Trois lignes qui échouent indépendamment

La première ligne est l’échange de clés à l’intérieur d’IKE lui-même, qui produit les clés protégeant la négociation. La deuxième est la proposition pour la CHILD SA, qui protège le trafic transporté par le tunnel. La troisième est l’authentification, qui décide de ce que chaque partie présente et de la manière dont l’autre le valide.

Les échecs se produisent à des endroits différents. Un échec d’échange arrête la négociation avant qu’un tunnel existe. Un échec de CHILD SA survient après la réussite de l’authentification, parfois seulement lors d’un renouvellement de clés. Un échec d’authentification peut ressembler à un échec d’échange dans les journaux si l’on ne lit que la première erreur.

Séparer les lignes n’est pas de la comptabilité. Cela change le réglage qui vaut la peine d’être modifié et empêche le geste le plus coûteux de tout ce domaine, à savoir régénérer des certificats qui fonctionnent pour corriger une divergence de proposition. Une ligne qui change ne devrait jamais forcer les deux autres à changer avec elle. Cette indépendance est tout l’intérêt de les écrire séparément.

Ce que contrôlent les deux champs de Windows

Windows tient deux champs séparés : DHGroup configure l’échange IKE lui-même, tandis que PfsGroup configure la stratégie IPsec qui protège le trafic du tunnel. Ils appartiennent à des phases différentes. Comparer un champ IKE de Windows à une valeur de phase 2 de FortiGate teste la mauvaise paire, et les numéros peuvent correspondre alors que l’échange sous-jacent échoue toujours.

Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSA

Les deuxième et troisième commandes rapportent les associations de sécurité qui existent réellement, et c’est ce qui ressemble le plus à une réponse qu’un client puisse vous donner. Une association en mode principal sans association en mode rapide est un problème de CHILD SA, et c’est la signature d’une divergence de phase 2 plutôt que d’un problème de certificat.

Notez ce qui a été proposé et ce qui a été sélectionné lors d’une tentative. Une liste proposée contenant une proposition acceptable et une proposition sélectionnée qui ne correspond pas à la stratégie de la passerelle est un désaccord de configuration, pas un mystère d’interopérabilité.

Un groupe de courbe elliptique ne choisit pas votre clé de signature

L’inférence erronée la plus tenace dans ce domaine est que choisir un groupe DH de courbe elliptique exige un certificat de courbe elliptique. Un groupe DH fournit le matériel d’échange de clés ; l’algorithme de signature est négocié par le cadre d’authentification, et ce sont deux décisions distinctes dans IKEv2.

RFC 7427 existe précisément parce que ces décisions étaient auparavant imbriquées, et définit comment les algorithmes de signature sont annoncés et sélectionnés indépendamment de l’échange de clés. Une passerelle peut prendre en charge à la fois un groupe de courbe et un choix de schémas de signature.

Ainsi, lorsqu’une négociation échoue après un changement de groupe, regardez la méthode d’authentification avant de regarder le type de clé du certificat. Changer un certificat est une opération lente et risquée qui est rarement la réponse, et la faire en premier détruit votre capacité à savoir quel changement a réellement aidé. Lisez la ligne d’authentification avant de toucher au magasin de certificats.

Gardez les deux dans des lignes séparées de la fiche d’accord et l’erreur cesse d’être tentante. Une ligne énumère les groupes, l’autre énumère les schémas de signature et les identités, et aucune n’est une preuve pour l’autre.

Placez chaque clé privée avec son propriétaire réel

Une passerelle qui présente son propre certificat a besoin de la clé privée qui lui correspond. Un pair qui valide une chaîne a besoin du certificat de l’AC et n’a précisément pas besoin de la clé de signature de l’AC. Confondre ces trois artefacts est la façon dont les gens finissent par importer une clé privée d’AC dans un appareil VPN pour faire apparaître un certificat dans une autre catégorie.

Sur FortiOS, les rôles sont distincts : un certificat local avec sa clé, un certificat distant utilisé pour identifier un pair et une entrée d’AC distante qui établit la confiance dans les certificats signés par cette AC. Une entrée d’AC distante sans clé privée n’est pas incomplète ; elle est correcte pour son usage.

Les clés de signature d’AC importées élargissent l’autorité de quiconque peut lire cet appareil. Elles ne résolvent pas non plus la validation ordinaire du pair, car la validation a besoin du certificat public et de la décision de confiance, pas de la capacité d’émettre de nouveaux certificats.

Gardez la clé de signature de l’AC avec le processus de l’émetteur lui-même, et notez quel appareil détient quelle clé. Un tableau court de propriétaires vaut plus qu’un tableau plus long d’algorithmes quand un audit demande qui pourrait usurper qui. Personne n’importe une clé qu’il sait être uniquement d’inventaire. Écrivez l’inventaire avant l’incident, pas après.