OpenConnect-Anmeldung landet auf der falschen Seite? Prüfen Sie zuerst den Pfad

Sie fügen die Adresse aus der Onboarding-Mail ein, der Client erreicht das Gateway, und das erscheinende Anmeldeformular ist das allgemeine Portal statt des Partnerportals, das der Betreiber beschrieben hat. Nichts meldet einen Fehler, und genau das macht es verwirrend: Der Tunnel kann sogar hochkommen, nur hinter dem falschen Einstiegspunkt. Der Pfad in dieser URL leistete Arbeit, und was ihn ersetzte, ließ diese Arbeit fallen.

Trennen Sie zwei Dinge, die im Ticket als eine Zeichenkette ankommen: die Adresse, die den Dienst erreicht, und die Eingabe, die entscheidet, wo die Authentifizierung beginnt. Das erste zu reparieren und das zweite zu ignorieren, ist der Weg, wie ein korrekter Hostname trotzdem die falsche Anmeldung erzeugt.

Was der Client sendet, bevor Sie ein Formular sehen

Bei einer Adresse wie https://vpn.example.net/partners ist die erste Handlung des Clients eine HTTPS-Anfrage an diesen Pfad statt an den nackten Host. Zurück kommt meist eine Weiterleitung zum Anmelde-Endpunkt oder das Formular selbst. Ein Client, der nur vpn.example.net erhält, beginnt bei der Standard-Landeseite, die gerade gilt, und das kann ein anderes Portal, eine andere Gruppenliste oder eine Seite sein, die ein ganz anderes Protokoll erwartet. Der Unterschied ist in den Antwort-Headern sichtbar, lange bevor irgendeine Anmeldeinformation getippt wird.

Deshalb können ein funktionierender Browser-Tab und ein fehlschlagendes Clientprofil dasselbe Gateway nennen und trotzdem nicht übereinstimmen. Der Browser folgte dem Pfad; das Profil hatte ihn nie.

Zwei Eingaben, die austauschbar aussehen und es nicht sind

OpenConnect legt den anfänglichen HTTPS-Pfad als --usergroup offen, und die Handbuchseite behandelt eine vollständige URL mit diesem Pfad als dieselbe Anfrage, anders geschrieben. --authgroup ist eine separate Option: Sie wählt einen Eintrag aus der Liste, die das Gateway innerhalb des Anmeldeformulars zeigt. Manche Protokolle nennen diesen Eintrag Gruppe, andere Domäne oder Gateway, und genau dort werden die beiden Flags verwechselt.

Ein Dienst kann legitim beides brauchen. Der Pfad kann Sie auf das richtige Portal bringen, während das Formular weiterhin verlangt, dass Sie innerhalb davon eine Gruppe wählen. Den Portalnamen als Gruppennamen anzugeben, oder umgekehrt, erzeugt eine Anmeldung, die akzeptiert aussieht und dann nicht autorisiert, weil der Wert syntaktisch gültig und semantisch falsch war.

Bitten Sie den Betreiber um jeden Wert in einer eigenen Zeile: Einstiegspfad, Formularauswahl und ob beides nötig ist. Leiten Sie das eine nicht aus dem anderen ab, nur weil die Bezeichnungen ähnlich klingen.

Warum das Kürzen des Pfads das Ergebnis ändert

Clients, die nur Host und Port akzeptieren, verbinden sich oft trotzdem, sodass das Symptom selten ein harter Fehler ist. Stattdessen bekommen Sie die falsche Anmeldeseite, eine leere Gruppenliste, einen Zertifikatsnamen, der nicht mehr zu dem passt, was der Betreiber veröffentlicht hat, oder einen Tunnel, der ohne Route zu dem gewünschten Dienst hochkommt. Jedes davon sitzt in einer anderen Schicht, und keines wird repariert, indem man eine längere Zeichenkette in ein als Hostname dokumentiertes Feld einfügt. Zwei davon sind von außen auch nicht unterscheidbar, da beide als Anmeldeformular ankommen, das einfach nicht weitergeht.

Den Hostnamen durch eine IP-Adresse zu ersetzen, ist ein separater Fehler, der oft mit diesem zusammen reist. Namensbasierte Dienstauswahl und Zertifikatsprüfung hängen beide vom Namen ab, sodass eine numerische Adresse ein Pfadformat-Problem in einen TLS-Fehler verwandeln kann.

Browseradressen tragen auch mehr als Pfade. Sitzungs-IDs, Weiterleitungsziele, Sprachpräfixe und temporäre Anmeldeparameter erscheinen alle in der Adressleiste, und keines davon gehört in ein gespeichertes Clientprofil.

Bestätigen Sie den Einstiegspunkt, bevor Sie irgendetwas anderes bearbeiten

Lesen Sie die Header für den Pfad, den Sie erhalten haben. Eine Anfrage wie curl -sS -o /dev/null -D - https://vpn.example.net/partners gibt die Statuszeile und jeden Location-Header aus, ohne der Weiterleitung zu folgen. Ein 302, der auf einen benannten Anmelde-Endpunkt zeigt, bestätigt, dass der Pfad existiert, und zeigt, wohin er führt; ein 404 bedeutet, dass die Adresse des Betreibers veraltet ist.

Reproduzieren Sie dann denselben Einstiegspunkt im freigegebenen Client, zum Beispiel openconnect --usergroup=partners vpn.example.net, und beobachten Sie, welches Formular erscheint. Wenn das Formular korrekt ist und der Tunnel weiterhin fehlschlägt, war der Pfad nie das Problem, und der nächste Halt ist Richtlinie oder Routing.

Erfassen Sie Hostname, Port, Protokoll, Einstiegspfad und Formularauswahl als fünf getrennte Felder im Ticket. Diese Liste ist es, die den nächsten Ingenieur in die Lage versetzt, einen nicht erreichbaren Server von einer TLS-Ablehnung, einer verweigerten Auswahl und einem Tunnel zu unterscheiden, der ohne die benötigten Routen hochkam.