IKEv1 mit XAuth und OTP: Was jede Eingabeaufforderung verlangt
Ein Gruppen-PSK, ein XAuth-Benutzeraustausch und eine OTP-Abfrage sind drei verschiedene Eingaben. Ordnen Sie jede Aufforderung ihrem Eigentümer zu, bevor Sie einen weiteren Client installieren.
IKEv1 mit PSK, XAuth und OTP verlangt kein einziges kompliziertes Passwort. Es schichtet einen gemeinsamen Schlüssel zwischen den Peers, einen Benutzeraustausch und einen zweiten Faktor übereinander, dessen Abfrage das Backend bestimmt. Jede Schicht hat ihren eigenen Eigentümer und ihre eigene Fehlermeldung. Wer sie verwechselt, lässt Menschen einen Einmalcode in ein Feld tippen, das ein Gruppengeheimnis speichert.
Ordnen Sie jede Eingabeaufforderung der Schicht zu, die sie verlangt, bevor Sie einen weiteren Client installieren oder eine Anmeldeinformation zurücksetzen.
Drei Geheimnisse, drei Eigentümer
Der vorab geteilte Schlüssel gehört zur Peer-Beziehung und wird einmal von demjenigen konfiguriert, der beide Enden besitzt. Die Benutzeranmeldeinformation gehört zum Authentifizierungs-Backend und wird bei jeder Anmeldung geprüft. Der zweite Faktor gehört zu einem Tokensystem, dessen Antwort sich bei jedem Versuch ändert. Keiner ersetzt einen anderen, und ein Deployment, das sie als ein Passwort behandelt, scheitert auf der Schicht, die niemand dokumentiert hat.
Schreiben Sie drei Spalten auf: Eigentümer, Lebensdauer und die Fehlermeldung, die jede erzeugt. Diese Tabelle ist das Diagnosewerkzeug, die Feldnamen des Clients sind es nicht.
| Layer | Owner | Lifetime |
|---|---|---|
| Pre-shared key | Peer configuration | Until operators change it |
| XAuth credential | Authentication backend | Per session, per policy |
| One-time code | Token system | Single use |
PSK: der Peer, nicht die Person
Der vorab geteilte Schlüssel authentifiziert in dieser Altkonfiguration das Gateway-Paar, daher ersetzt ihn die Benutzeranmeldung nie. Er ist außerdem der Wert, der am häufigsten so falsch ist, dass statt einer Abfrage ein allgemeiner Aushandlungsfehler entsteht. Wenn der Tunnel fehlschlägt, bevor eine Benutzerabfrage erscheint, sind der Schlüssel oder die Vorschläge die Verdächtigen.
Eine Benutzeranmeldeinformation kann keinen Fehler der ersten Phase reparieren. Sie zu rotieren verschwendet die einzige Anmeldeinformation, die Sie sicher rotieren können, und bestärkt die falsche Theorie.
XAuth: der alte Benutzeraustausch
XAuth fügt einen Benutzerauthentifizierungsaustausch über die Peer-Authentifizierung von IKEv1, und das Gateway entscheidet, welches Backend ihn prüft. Je nach diesem Backend kann der Austausch ein Verzeichnispasswort, eine RADIUS-Anmeldeinformation oder eine Token-Antwort annehmen. Das Wort XAuth benennt den Transport des Austauschs, nicht den Typ der Anmeldeinformation.
Prüfen Sie, auf welches Backend das Gateway-Profil zeigt. Das sagt Ihnen, wonach der Benutzer gefragt wird und was ein Passwort-Reset tatsächlich ändert, und beides ist in einem Client-Profil nicht sichtbar.
OTP: was auch immer das Backend verlangt
Manche Deployments verlangen nach dem Passwort einen separaten Einmalcode, andere definieren ein kombiniertes Eingabeformat mit dokumentiertem Trennzeichen. Beides existiert, und das Profil vor Ihnen entscheidet, welches gilt. Eine Verkettung zu erfinden, weil sie an einem anderen Standort funktioniert hat, ist der häufigste Weg, ein Registrierungs-Token zu verbrennen. Die Dokumentation des Gateways selbst ist die einzige Quelle, die das klärt.
Verwenden Sie das dokumentierte Format mit einem Client, der den vom Gateway angebotenen Austausch abschließen kann.
Wo die Client-Grenze beißt
Fortinet dokumentiert, dass FortiClient 7.4.4 und später IKEv1 für IPsec-VPNs nicht mehr unterstützen, was eine Produkt- und Versionsgrenze und keine allgemeine Abschaffung ist, wie FortiClient-Kompatibilitätshinweis festhält. Auch andere Clients sind nicht austauschbar: OpenConnect und openfortivpn sprechen bestimmte Gateway-Protokolle, keine beliebigen IKEv1-Profile. Prüfen Sie IKE-Version, PSK-Modus, XAuth-Unterstützung und Interaktionsmodell des installierten Clients einzeln. Ein Client, der sich mit einer anderen Methode verbindet, hat die ursprüngliche Anforderung nicht bewiesen.
IKEv1 ist veraltet, daher ist ein neuer Rollout auf einem nicht unterstützten alten Client eine kurzlebige Lösung. Bitten Sie den Gateway-Eigentümer um einen unterstützten Migrationspfad, einschließlich der Frage, wie der zweite Faktor dort behandelt wird.
Diagnose ohne Abschalten des Faktors
Trennen Sie die Stufen im Protokoll: Peer-Aushandlung, Benutzeraustausch, Ergebnis des zweiten Faktors, dann Adress- und Routenzuweisung. Notieren Sie Komponente und Stufe, statt den Code in jedem Feld zu probieren. Den Faktor abzuschalten, damit ein Test besteht, erzeugt einen Tunnel, der nichts über das Deployment beweist.
Bewahren Sie Registrierungsgeheimnisse und den gemeinsamen Schlüssel in geschütztem Speicher gemäß dem Prozess der Organisation auf. Ein Einmalcode in einer dauerhaften Datei ist ein Faktor, der aufgehört hat, einer zu sein.