IKEv2-Austausch klappt, dann scheitert die Authentifizierung: wo

Ein Client, der eine IKEv2-Antwort erhält, hat bewiesen, dass das Gateway erreichbar ist, dass beide Seiten einen Vorschlag aushandeln können und dass der erste Schlüsselaustausch abgeschlossen wurde. Er hat nicht bewiesen, dass jemand authentifiziert ist. Der nächste Austausch trägt Identitäten, Zertifikate oder EAP, und dort bleibt die Verbindung meist stehen. Zu lesen, welche dieser Prüfungen fehlgeschlagen ist, ist die ganze Diagnose, und die Fehlermeldung allein sagt das selten.

Prüfung 1: die Phase lesen, nicht die Meldung

Eine Ablehnung kann von drei Stellen kommen: Der Client weist die Identität des Servers zurück, das Gateway weist den Nachweis des Clients zurück, und ein externer Authentifizierungsdienst weist das Konto zurück.

Jede erzeugt eine andere Logzeile auf einer anderen Maschine, und jede hat eine andere Lösung. Eine clientseitige Ablehnung des Serverzertifikats ist ein Vertrauens- oder Namensproblem beim Client; eine Ablehnung des Clientzertifikats durch das Gateway ist ein Vertrauensproblem beim Gateway; ein EAP-Fehler ist ein Konto- oder Backend-Problem. Die Meldung, die Sie sehen, ist meist die Zusammenfassung des Clients von einem davon, deshalb ist das Gateway-Log genauso wichtig wie das des Clients.

Prüfung 2: welche Identität geprüft wurde

Ein Client kann das Serverzertifikat oder die erwartete Identität zurückweisen, bevor irgendein Benutzernachweis angeboten wird, und eine funktionierende Serveradresse ersetzt diese Prüfung nicht. Die Kennung, die der Client erwartet, muss zu dem passen, was das Gateway präsentiert, was eine Konfigurations- und keine Netzfrage ist.

In strongSwan-Begriffen ist das rightid auf dem Client und die eigene Identität des Gateways auf der anderen Seite, und eine Abweichung scheitert, bevor EAP überhaupt besprochen wird.

Das Gateway kann separat das Clientzertifikat, dessen Schlüsselnachweis oder dessen Kontoauthentifizierung zurückweisen, und diese drei sind nicht austauschbar. Das Zurücksetzen eines Benutzerpassworts erneuert kein Gerätezertifikat, und die Neuinstallation eines Gerätezertifikats behebt keine falsche Serveridentität. Bei Zertifikatsfehlern prüfen Sie zuerst die Uhr, dann die Vertrauenskette, dann die erwartete Kennung; ein Client, dessen Uhr Minuten daneben liegt, scheitert an einer Gültigkeitsprüfung, die wie ein Vertrauensfehler aussieht. swanctl --list-certs an beiden Enden zeigt, was jede Seite tatsächlich hat.

Prüfung 3: wenn EAP im Spiel ist

Client und Server müssen sich auf eine unterstützte Methode einigen, und das Backend muss die gelieferte Identität akzeptieren.

Ein Benutzername kann ein Domänensuffix oder ein bestimmtes Kontoformat erfordern, das die Bereitstellung verlangt, und das Format ist dokumentiert statt erratbar. Die dokumentierten Felder des Betreibers zu liefern ist schneller als Varianten zu probieren, und es vermeidet ein zweites Problem: wiederholte Versuche können eine Kontosperre auslösen, die dann die ursprüngliche Phase hinter einem neuen Fehler versteckt. Ist die Methode EAP-MSCHAPv2 gegen ein Verzeichnis, kann der Fehler zum Verzeichnis gehören und gar nicht zum VPN.

Testen Sie Identitätsprobleme nicht, indem Sie Identitätsprüfungen abschalten. Das macht einen diagnostizierbaren Fehler zu einem nicht diagnostizierbaren und lässt die Verbindung schwächer als vorher.

Prüfung 4: was nach einer erfolgreichen Anmeldung passiert

Sobald IKE_AUTH abgeschlossen ist, entscheidet die CHILD_SA-Aushandlung, welche Traffic-Selektoren installiert werden, und dort kann eine Verbindung erfolgreich sein und trotzdem nichts durchlassen.

Eine neu funktionierende Anmeldung deckt oft ein Selektor- oder Routenproblem auf, das zuvor hinter dem Authentifizierungsfehler verborgen war. Kommt der Tunnel hoch und eine Anwendung erreicht ihr Ziel trotzdem nicht, schauen Sie auf die ausgehandelten Selektoren und die Routen statt erneut auf die Identität. Identitätseinstellungen an dieser Stelle zu ändern trifft die falsche Phase und bricht meist eine funktionierende Anmeldung. Bestätigen Sie es mit swanctl --list-sas, der die Children und ihre Selektoren getrennt von der IKE SA zeigt.

Prüfung 5: was Sie dem Support geben

Eine bereinigte Zeitachse und die genaue Ablehnung sind mehr wert als ein vollständiger Diagnoseexport, und der Export kann private Schlüssel oder Zugangsdaten enthalten, die Sie nicht teilen sollten.

Notieren Sie die Zeit mit Zeitzone, die Versionen von Client und Gateway, die Methode, die angebotene Identitätszeichenfolge statt des Passworts und die genaue Phase, die sie abgelehnt hat. strongSwan-Dokumentation zur IKEv2-Konfiguration beschreibt die Identitäts- und EAP-Einstellungen, die diese Ergebnisse entscheiden, und sie ist die Referenz, die man vor dem Ändern eines Feldes liest. Ändern Sie dann eine Sache und testen Sie eine neue Verbindung, denn eine zwischengespeicherte Sitzung erzählt Ihnen von der alten Konfiguration.