Servergebundenes Profil scheitert hinter einem TLS-Proxy: welche Generation?

Ein Benutzer kann sich verbinden und ein anderer nicht, über dasselbe Portal, am selben Tag. Beide haben servergebundene Profile, beide laufen auf derselben Access Server-Version, und der einzige Unterschied ist, wann ihr Profil erzeugt wurde. Das ist das Muster, das man erkennen sollte, denn "servergebunden" benennt eine Richtlinie und keine Verbindungsabfolge. Access Server hat zwei Generationen dieses Artefakts ausgeliefert, und ein TLS-Reverse-Proxy steht nur vor einem ihrer Pfade. Drei Bedingungen entscheiden, auf welchem Zweig Sie sich befinden.

Zwei Generationen, zwei Verbindungsabfolgen

Im älteren Entwurf, gültig bis 2.8, ist die importierte Datei ein Pseudo-Profil. OpenVPN Connect verwendet sie, um sich über HTTPS gegenüber der Web-API des Access Servers zu authentifizieren, erhält ein temporäres benutzergebundenes Profil und ein Sitzungstoken und baut erst danach das VPN auf. Zwei Transporte laufen nacheinander, und der erste ist eine gewöhnliche Webanfrage.

Das mit 2.9 eingeführte Format führt diesen Bootstrap pro Verbindung nicht aus. Es ist ein natives Profil, das kompatible OpenVPN Clients nutzen können, nicht nur OpenVPN Connect. Das Herunterladen oder Importieren per URL kann weiterhin HTTPS umfassen — das ist ein Veröffentlichungsschritt, kein Abruf eines temporären Profils pro Verbindung.

Ein Upgrade schreibt bereits ausgestellte Profile nicht zwangsläufig um, daher kann eine aktuelle Serverversion noch das alte Artefakt ausgeben. Die Serverversion sagt Ihnen, was möglich ist, nicht was dieser Benutzer importiert hat.

Drei Bedingungen, die Ihren Zweig bestimmen

Die erste Bedingung ist die Generation des Artefakts. Fordern Sie die Datei an, sehen Sie nach, wie sie erzeugt wurde, und notieren Sie die Clientversion, die sie importiert hat. Wenn Sie die Generation nicht aus der Datei ableiten können, sagt Ihnen ein frisches Profil für ein Testkonto, was der Server heute erzeugt, und das ist eine andere Information als die, die der fehlschlagende Benutzer hat.

Die zweite ist, was Ihr Frontend tatsächlich terminiert. Ein HTTP-Reverse-Proxy auf Schicht sieben, der TLS auslagert, ist nicht dasselbe Objekt wie ein TCP-Weiterleiter auf Schicht vier, und ein UDP-Weiterleiter ebenso wenig. Die übliche Anordnung des Access Servers auf Port 443 lässt den OpenVPN-TCP-Daemon Browserverkehr erkennen und an die Webdienste übergeben, sodass ein fremder HTTPS-Terminator davor die Protokollbehandlung dieses Daemons nicht erhält. Die gemeinsame Nummer 443 macht zwei Entwürfe nicht gleichwertig.

Die dritte ist, wo der Fehler landet. Ein Fehler vor dem VPN und ein Fehler im Steuerkanal sehen in einem Client, der nur "verbindet" meldet, ähnlich aus, hinterlassen aber an verschiedenen Stellen Spuren. Ist das alte Format im Spiel, ist der Bootstrap ein Kandidat. Ist das neue Format im Spiel, ist ein leeres Webzugriffsprotokoll zu erwarten und beweist nichts in die eine oder andere Richtung.

Wenn das Artefakt alt ist: Der Bootstrap scheitert zuerst

Lesen Sie den tatsächlichen Fehler des Clients statt seinen Endzustand. Die interessanten Felder sind der HTTPS-Fehler, die vom Client erwartete Serveridentität, das Ziel der Anfrage und ob die Zertifikatsprüfung abgeschlossen wurde. Gleichen Sie diese dann mit den Protokollen von Webdienst und Proxy auf der Serverseite ab.

Dass ein Browser die Anmeldeseite erreicht, ist kein Beweis dafür, dass die API-Authentifizierung dieses Clients gelungen ist. Es sind verschiedene Anfragen, mit unterschiedlichen Zertifikatserwartungen und oft unterschiedlichen Hostnamen. Wird das Portal korrekt ausgeliefert und scheitert der Client weiterhin, liegt die Abweichung im Bootstrap-Pfad, nicht im Passwort des Benutzers.

Machen Sie den Vergleich nicht dadurch erfolgreich, dass Sie die TLS-Prüfung abschalten oder die Authentifizierungsrichtlinie lockern. Das verwandelt eine diagnostizierbare Konfigurationsabweichung in einen funktionierenden, aber ungeprüften Pfad, und genau diese Änderung macht aus einem temporären Test ein dauerhaftes Loch. Die Access Server-Dokumentation zu Verbindungsprofilen beschreibt beide Generationen und den Ablauf mit dem temporären Profil, und sie ist die Referenz, die Sie prüfen sollten, bevor Sie annehmen, ein Proxy sei schuld.

Wenn das Artefakt neu ist: Lesen Sie stattdessen den Steuerkanal

Mit einem Profil im 2.9-Stil geht der Client direkt zum nativen VPN-Endpunkt. Untersuchen Sie die Endpunkte im Profil, den verwendeten Transport und den Fehler im Steuerkanal. Wenn der Client nie eine HTTP-Anfrage stellt, entspricht das dem Entwurf und ist kein Symptom.

Hier ändert sich auch die Form der Proxy-Frage. Eine HTTPS-Auslagerung kann einen reinen TCP-Strom nicht brechen, den sie nie sieht, aber sie kann weiterhin den Download brechen, der das Profil veröffentlicht, und ein reiner TCP-Weiterleiter überträgt UDP überhaupt nicht. Prüfen Sie, welchen Transport das Profil verlangt, bevor Sie schließen, das Frontend sei irrelevant.

TLS-Passthrough für einen einzelnen Strom ist eine enge Anordnung. Es bietet keine UDP-Weiterleitung und bildet nicht das eigene Dienstweiterleitungsverhalten des Daemons auf 443 nach. Wenn Ihr Frontend eines davon tut, sagen Sie welches, denn die Abhilfe unterscheidet sich.

Abbilfen, die eng bleiben

Die am wenigsten störende Prüfung besteht darin, ein frisches unterstütztes Profil für ein Testkonto zu erzeugen und sich über den vorgesehenen nativen Endpunkt mit denselben Authentifizierungsanforderungen zu verbinden. Funktioniert das und das behaltene alte Profil nicht, haben Sie das Artefakt in einem Schritt vom Server und vom Proxy getrennt.

Die Verteilung eines benutzergebundenen Profils entfernt die Altlast der Bootstrap-Abhängigkeit vollständig, weil es keinen Austausch eines temporären Profils gibt, der scheitern könnte. Es muss für den vorgesehenen Benutzer ausgestellt, nie von einem Administrator kopiert werden, und es ändert, wozu der Client berechtigt ist, behandeln Sie es daher als Richtlinienentscheidung und nicht als Behelf.

Korrigieren Sie dann das Veröffentlichungslayout, sodass jeder erforderliche Pfad existiert: der Webpfad für Downloads und Portalnutzung und der native VPN-Pfad auf dem Transport, den die Profile erwarten. Halten Sie die Aufgabe des Proxys auf einer Schicht. Ein funktionierender benutzergebundener Tunnel beweist, dass dieser Pfad funktioniert; er beweist nicht, dass jede Proxy-Anordnung jede Generation unterstützt, und ein alter Bootstrap-Fehler verurteilt nicht das neuere Format.

• Bestimmen Sie die Generation des Artefakts, bevor Sie den Proxy anfassen.
• Stellen Sie fest, ob der Fehler vor dem Tunnel oder in ihm auftritt.
• Bestätigen Sie, was das Frontend terminiert: HTTP, TCP-Strom oder UDP.
• Testen Sie ein neu ausgestelltes Profil gegen den nativen Endpunkt bei unveränderter Richtlinie.