Juniper- oder Pulse-Gateway: Welches OpenConnect-Protokoll verwenden

Ein Protokoll für OpenConnect auszuwählen ist eine Zuordnungsübung, keine Markensuche. Ein Gateway, das auf der Login-Seite Juniper nennt, kann Network Connect, Pulse oder beides anbieten, und die Standardeinstellung des Clients ist keines davon. Raten kostet einen fehlgeschlagenen Login und, schlimmer, einen Support-Thread, der die Zugangsdaten für eine Protokoll-Unstimmigkeit verantwortlich macht. Bestätigen Sie den Dienst, bevor Sie einen Hostnamen in ein Profil eintragen.

OpenConnect nennt das ältere Protokoll nc und das neuere pulse, und beide leben in derselben Binärdatei. Das gewählte Flag ändert den Login-Austausch, nicht das Routing nach einer erfolgreichen Verbindung.

Die beiden Protokollnamen teilen eine Produkthistorie

Juniper Network Connect und der spätere Pulse-Secure-Client sind unterschiedliche Protokolle, die eine Gerätefamilie im Laufe der Zeit angeboten hat. OpenConnect bekam einen nc-Handler für das erste und einen pulse-Handler für das zweite. Es sind getrennte Codepfade mit getrennten Anforderungsformaten, daher sagt Unterstützung beim einen nichts über das andere aus.

Der Unterschied zeigt sich sofort im Login-Gespräch: Endpunkte, Formularfelder und die Art, wie der Client einen abgelehnten zweiten Faktor meldet, unterscheiden sich zwischen den beiden Handlern.

Die Wahl auf der Kommandozeile ist eine Änderung um ein Wort: openconnect --protocol=nc vpn.example.com für Network Connect oder openconnect --protocol=pulse vpn.example.com für Pulse. Beide Versuche sind echte Verbindungsversuche, die Routen und DNS umkonfigurieren können, führen Sie sie also bewusst aus. Setzen Sie niemals ein Passwort auf die Kommandozeile und deaktivieren Sie keine Zertifikatsprüfungen, um einen Protokollfehler zu umgehen, denn das verbirgt die Unstimmigkeit, statt sie zu beheben. Wenn Sie sehen müssen, was der Client sendet, gibt --dump-http-traffic den Austausch aus, was normalerweise den Handler identifiziert, den das Gateway erwartet.

Ordnen Sie das Protokoll dem zu, was das Gateway anbietet

Das Gerät antwortet nur auf das Protokoll, für das es konfiguriert ist. Ein reiner Pulse-Dienst weist einen nc-Login selbst mit gültigen Zugangsdaten ab, und ein alter Network-Connect-Dienst hat keinen pulse-Endpunkt, der antworten könnte. Fragen Sie den Administrator, welches aktiviert ist, und welchen Client sie unterstützen. Ein umbenanntes Gerät, eine veraltete Wiki-Seite und ein vertrautes Webportal sind alles schwache Belege.

Wenn Sie das Protokoll kennen, bestätigen Sie die umliegenden Anforderungen: Zertifikats- oder Token-Authentifizierung, eine Auth-Gruppen-Auswahl und jede Endpunkt-Konformitätsprüfung. Diese entscheiden, ob ein Kommandozeilen-Client den Login überhaupt abschließen kann.

Die Authentifizierung kann die Frage vor dem Protokoll klären

Eine Bereitstellung kann ein Client-Zertifikat, eine SAML-Runde durch einen Browser oder einen Host-Checker verlangen, der die Maschine vor der Zugangsgewährung prüft. Der pulse-Handler von OpenConnect dokumentiert Kompatibilitätsgrenzen für einige dieser Abläufe, und der nc-Handler hat seine eigenen Lücken. Ein Passwort, das im Browser funktioniert, beweist, dass das Konto gültig ist; es beweist nicht, dass ein beliebiges CLI oder Desktop-Plugin dieselbe Sequenz abschließen kann. Wenn ein Host-Checker im Spiel ist, braucht der Client ein Wrapper-Skript vom Administrator. Ohne das bleibt der Login nach der ersten Antwort stehen und sieht wie ein Protokollfehler aus, obwohl in Wahrheit ein Konformitätsschritt fehlt.

Die Auth-Gruppen-Auswahl ist der andere häufige Stolperstein, denn ein Gateway mit mehreren Gruppen erwartet, dass der Client eine nennt.

Auf der Kommandozeile liefert --authgroup="Employees" diese Wahl, und ihr Weglassen kann die Sitzung in einer Standardgruppe landen lassen, die das Konto ablehnt. Mit Zertifikaten zeigt --certificate auf das Client-Zertifikat und den Schlüssel, und das Gateway kann danach trotzdem ein Token verlangen. Testen Sie die ganze Sequenz einmal mit ausführlicher Ausgabe, bevor Sie irgendetwas darum herum automatisieren.

Wenn die Desktop-Oberfläche die Wahl nicht ausdrücken kann

Grafische Oberflächen bringen ihre eigenen Funktionsumfänge mit, und ein älteres Plugin kann älter sein als das Protokoll, das Sie brauchen. Die OpenConnect-Integration von NetworkManager speichert die Wahl in ihren Verbindungsdaten, sodass nmcli connection modify "Office VPN" vpn.data "protocol=pulse" setzen kann, was der Editor nicht zeigt. Prüfen Sie, ob die installierte Plugin-Version den Schlüssel unterstützt, bevor Sie annehmen, dass die Änderung wirksam wurde.

Wenn ein Menü nur PPTP oder L2TP anbietet, macht die Wahl eines davon keinen Pulse-Dienst zu diesem Protokoll. Installieren Sie die genehmigte Integration, statt zu dem zu wechseln, was das Menü zufällig auflistet.

Was zu protokollieren ist, wenn der Login weiter scheitert

Notieren Sie vier Dinge: das gewählte Protokoll, die Client- und Plugin-Versionen, den erwarteten Authentifizierungsablauf und den ersten Fehler, der mit einem Statuscode statt mit einem Timeout zurückkam. Dieser Satz trennt einen falschen Handler von einem fehlenden Zertifikat, einer abgelehnten Auth-Gruppe oder einer blockierten Konformitätsprüfung. Ausführliche Ausgabe lohnt sich aus demselben Grund zum Aufbewahren, weil sie die fehlgeschlagene Anforderung zeigt und nicht nur das Symptom.

Halten Sie den funktionierenden Befehl oder das Profil neben dem Gateway-Namen, sobald es klappt. Sonst wiederholt die nächste Person, die sich verbindet, dieselbe Marken-gegen-Protokoll-Vermutung.