Warum die openfortivpn-Anmeldung scheitert, wenn Sie die Portal-URL einfügen

Der Fehler sieht nach einem Problem mit den Anmeldedaten aus: openfortivpn fragt nach dem Passwort, sendet es, und das Gateway antwortet mit einer Ablehnung oder einer Weiterleitung zurück zur Anmeldeseite. Danach tippen die Nutzer das Passwort erneut ein, probieren den domänenqualifizierten Kontonamen und fügen schließlich die Portal-URL des Browsers in das Host-Feld ein. Genau dieser letzte Schritt macht aus einem kleinen Konfigurationsfehler einen verwirrenden.

Eine Fortinet-Portaladresse wie https://vpn.example.com/ext trägt mehrere Informationen auf einmal, und nur einige davon gehören zum VPN-Client.

Der Endpunkt und der Realm sind getrennte Eingaben

openfortivpn erwartet einen Endpunkt in der Form host oder host:port, dazu ein Konto und, wo das Deployment eines verwendet, einen Realm-Wert. Der Realm sagt dem Gateway, welche Authentifizierungsrichtlinie anzuwenden ist, bevor es das Konto bewertet. Er ist ein eigenes Feld und kein Suffix, das der Client aus einer URL herausliest.

Bei einem Deployment, dessen Betreiber bestätigt, dass der Realm ext ist, sieht ein nicht geheimes Aufrufen so aus: openfortivpn vpn.example.com:443 --username=alice --realm=ext. Dieselben Werte gehören in die Konfigurationsdatei als Einträge für host, port, username und realm. Lassen Sie das Passwort aus beiden Formen heraus und lassen Sie den Client danach fragen, damit es nicht in der Shell-Historie oder in einer weltweit lesbaren Datei landet. Ein zweiter Versuch, während der erste Client den Tunnel noch hält, scheitert aus einem Grund, der nichts mit dem Realm zu tun hat.

Das openfortivpn-Handbuch listet beide Optionen auf, sodass die genaue Schreibweise vor einem Anruf beim Support leicht zu prüfen ist. Es kann Ihnen jedoch nicht sagen, welcher Realm auf Ihrem Gateway konfiguriert ist.

Ein Pfadsegment ist nicht automatisch ein Realm

Portal-URLs sammeln allerlei Dinge nach dem Hostnamen: eine Anmeldeanwendung, eine Sprachauswahl, ein Weiterleitungsziel, eine Sitzungskennung. Das letzte Pfadsegment abzuschneiden und es einen Realm zu nennen, funktioniert oft genug, um gefährlich zu sein. Fragen Sie den Betreiber nach dem konfigurierten Wert oder lesen Sie ihn aus dem Profil, das Ihre Organisation verteilt.

Ein Realm ist auch nicht dasselbe wie ein Domänensuffix am Benutzernamen oder die Region, in der das Gateway steht. Manche Deployments wollen alice, andere wollen alice@corp, und der Realm entscheidet, welche davon das Gateway akzeptiert. Das Kontenformat zu ändern, um einen falschen Realm auszugleichen, erzeugt meist eine zweite, weniger aussagekräftige Ablehnung.

Beheben Sie einen Realm-Fehler nicht durch Ändern des Hosts

Den Hostnamen gegen eine IP-Adresse zu tauschen fühlt sich an, als würde man eine Schicht entfernen, und es bricht mehr, als es repariert. Die TLS-Namensprüfung vergleicht das Zertifikat mit dem Namen, den der Client verwendet hat, und eine IP-Adresse erscheint selten in den alternativen Subjektnamen eines Zertifikats. Die Server Name Indication ändert sich mit der Adresse, sodass ein Gateway, das mehrere Portale auf einer Adresse hostet, mit dem falschen antworten kann. Behalten Sie den Hostnamen und die Vertrauenskonfiguration intakt, während Sie den Authentifizierungsparameter korrigieren.

Wenn das Zertifikat in Ihrer Umgebung nicht vertrauenswürdig ist, reparieren Sie den Vertrauensspeicher oder pinnen Sie das erwartete Zertifikat bewusst. Die Verifikation abzuschalten, um an einem Realm-Fehler vorbeizukommen, tauscht ein Anmeldeproblem gegen ein Risiko stiller Abfangung.

Trennen Sie eine abgelehnte Anmeldung von einem fehlgeschlagenen Tunnel

Authentifizierungsfehler und Tunnel-Fehler treten zu unterschiedlichen Zeitpunkten auf, und die Meldungen unterscheiden sich. Ein Namensauflösungsfehler passiert vor jedem TLS-Handshake. Eine TLS-Ablehnung passiert, bevor Anmeldedaten gesendet werden. Eine Ablehnung von Realm oder Konto kommt als Antwort auf HTTP-Ebene vom Portal zurück. Erst nach diesen Phasen beginnt die PPP-Aushandlung, und erst dann tauchen Routing- und DNS-Probleme auf.

Ein korrekter Realm erzeugt keine fehlende Route und macht keine nicht unterstützte Anmeldemethode funktionsfähig. Wenn das Portal auf einen browserbasierten Ablauf besteht, nutzen Sie den vom Client unterstützten Weg für diesen Ablauf, statt einen Passwortaustausch zu wiederholen und zu hoffen, dass die Sitzung passt.

Bewahren Sie die Werte dort auf, wo der nächste Start sie findet

Sobald eine Verbindung gelingt, schreiben Sie Gateway, Port, Konto und Realm in das verwaltete Profil statt in einen Shell-Alias. Profile, die in einem Repository oder einem Konfigurationsmanagementsystem liegen, verhindern, dass der nächste Start stillschweigend den Realm eines anderen Profils übernimmt.

Testen Sie eine Verbindung erneut von Anfang bis Ende und bestätigen Sie sowohl die angewandte Richtlinie als auch den Zugriff auf eine Ressource, die Sie tatsächlich brauchen. Dass die Authentifizierung gelingt, ist der Anfang dieser Prüfung, nicht ihr Ende.