IKEv2 unter Windows und FortiGate: drei Einstellungen, die Leute zusammenlegen

Eine IKEv2-Vereinbarung zwischen einem Windows-Client und einem FortiGate-Gateway schlägt weiterhin fehl, und die Suche nach einer nicht passenden Nummer erzeugt eine längere Liste von Nummern. Die Liste wird erst handhabbar, wenn man sie in drei Zeilen aufteilt, die unabhängig voneinander fehlschlagen: der Schlüsselaustausch, der IKE schützt, der Schutz, der auf die CHILD SA angewendet wird, und die Authentifizierung, die beweist, wer jede Seite ist. Gruppennummern erscheinen in zwei dieser Zeilen und bedeuten unterschiedliche Dinge.

Drei Zeilen, die unabhängig fehlschlagen

Die erste Zeile ist der Schlüsselaustausch innerhalb von IKE selbst, der die Schlüssel erzeugt, die die Aushandlung schützen. Die zweite ist der Vorschlag für die CHILD SA, der den Verkehr schützt, den der Tunnel trägt. Die dritte ist die Authentifizierung, die entscheidet, was jede Seite vorzeigt und wie die andere es validiert.

Fehler landen an verschiedenen Stellen. Ein Austauschfehler stoppt die Aushandlung, bevor überhaupt ein Tunnel existiert. Ein CHILD-SA-Fehler tritt auf, nachdem die Authentifizierung erfolgreich war, manchmal erst bei einer Schlüsselerneuerung. Ein Authentifizierungsfehler kann in den Protokollen wie ein Austauschfehler aussehen, wenn man nur den ersten Fehler liest.

Die Zeilen zu trennen ist keine Buchhaltung. Es ändert, welche Einstellung es wert ist, geändert zu werden, und es verhindert den teuersten Schritt in diesem ganzen Bereich, nämlich funktionierende Zertifikate neu zu erzeugen, um eine Vorschlagsabweichung zu beheben. Eine Zeile, die sich ändert, sollte niemals die anderen beiden zwingen, sich mitzuändern. Diese Unabhängigkeit ist der ganze Sinn, sie getrennt aufzuschreiben.

Was die beiden Windows-Felder steuern

Windows hält zwei Felder getrennt: DHGroup konfiguriert den IKE-Austausch selbst, während PfsGroup die IPsec-Richtlinie konfiguriert, die den Verkehr im Tunnel schützt. Sie gehören zu verschiedenen Phasen. Ein Windows-IKE-Feld mit einem FortiGate-Phase-2-Wert zu vergleichen, prüft das falsche Paar, und die Nummern können übereinstimmen, während der zugrunde liegende Austausch weiterhin fehlschlägt.

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

Der zweite und der dritte Befehl melden die Sicherheitsassoziationen, die tatsächlich existieren, und das ist das Nächste an einer Antwort, das ein Client Ihnen geben kann. Eine Main-Mode-Assoziation ohne eine Quick-Mode-Assoziation ist ein CHILD-SA-Problem, und es ist die Signatur einer Phase-2-Abweichung und nicht eines Zertifikatsproblems.

Halten Sie fest, was angeboten und was in einem Versuch ausgewählt wurde. Eine angebotene Liste, die einen akzeptablen Vorschlag enthält, und ein ausgewählter Vorschlag, der nicht zur Richtlinie des Gateways passt, sind eine Konfigurationsuneinigkeit, kein Interoperabilitätsrätsel.

Eine Elliptische-Kurven-Gruppe wählt Ihren Signaturschlüssel nicht

Die hartnäckigste falsche Schlussfolgerung in diesem Bereich ist, dass die Wahl einer DH-Gruppe auf elliptischer Kurve ein Zertifikat auf elliptischer Kurve erfordert. Eine DH-Gruppe liefert Material für den Schlüsselaustausch; der Signaturalgorithmus wird vom Authentifizierungsrahmen ausgehandelt, und das sind zwei getrennte Entscheidungen in IKEv2.

RFC 7427 existiert gerade deshalb, weil diese Entscheidungen früher verflochten waren, und legt fest, wie Signaturalgorithmen unabhängig vom Schlüsselaustausch angekündigt und ausgewählt werden. Ein Gateway kann gleichzeitig eine Kurvengruppe und eine Auswahl von Signaturverfahren unterstützen.

Wenn eine Aushandlung nach einer Gruppenänderung fehlschlägt, schauen Sie deshalb zuerst auf die Authentifizierungsmethode und erst danach auf den Schlüsseltyp des Zertifikats. Ein Zertifikat zu wechseln ist ein langsamer, riskanter Vorgang, der selten die Antwort ist, und ihn zuerst zu tun zerstört Ihre Fähigkeit zu erkennen, welche Änderung tatsächlich geholfen hat. Lesen Sie die Authentifizierungszeile, bevor Sie den Zertifikatsspeicher anfassen.

Halten Sie beides in getrennten Zeilen des Vereinbarungsblatts, und der Fehler hört auf, verlockend zu sein. Eine Zeile listet Gruppen, die andere listet Signaturverfahren und Identitäten, und keine ist ein Beleg für die andere.

Legen Sie jeden privaten Schlüssel zu seinem tatsächlichen Eigentümer

Ein Gateway, das sein eigenes Zertifikat vorzeigt, braucht den passenden privaten Schlüssel. Ein Peer, der eine Kette validiert, braucht das CA-Zertifikat und ausdrücklich nicht den Signaturschlüssel der CA. Diese drei Artefakte zu verwechseln ist der Weg, auf dem Leute einen privaten CA-Schlüssel in ein VPN-Gerät importieren, damit ein Zertifikat in einer anderen Kategorie erscheint.

Unter FortiOS sind die Rollen verschieden: ein lokales Zertifikat mit seinem Schlüssel, ein entferntes Zertifikat zur Identifizierung eines Peers und ein Eintrag für eine entfernte CA, der Vertrauen in Zertifikate herstellt, die diese CA signiert hat. Ein Eintrag für eine entfernte CA ohne privaten Schlüssel ist nicht unvollständig; er ist für seinen Zweck korrekt.

Importierte CA-Signaturschlüssel erweitern die Befugnisse jedes Einzelnen, der dieses Gerät lesen kann. Sie lösen auch die gewöhnliche Peer-Validierung nicht, weil die Validierung das öffentliche Zertifikat und die Vertrauensentscheidung braucht, nicht die Fähigkeit, neue Zertifikate auszustellen.

Halten Sie den CA-Signaturschlüssel beim Prozess des Ausstellers selbst und halten Sie fest, welches Gerät welchen Schlüssel hält. Eine kurze Tabelle der Eigentümer ist mehr wert als eine längere Tabelle der Algorithmen, wenn ein Audit fragt, wer wen vortäuschen könnte. Niemand importiert einen Schlüssel, von dem er weiß, dass er nur für das Inventar ist. Schreiben Sie das Inventar vor dem Vorfall, nicht danach.