SSTP hinter einem TLS-inspektionierenden Proxy: Wo die Sitzung bricht

Ihr Browser lädt das Firmenintranet, das Proxy-Zertifikat ist vertrauenswürdig, und trotzdem bricht der SSTP-Client kurz vor dem Ende der Verbindung ab. Dieses Muster deutet auf den Unterschied zwischen einer Webanfrage und einer getunnelten Sitzung hin, nicht auf ein falsches Passwort. Gehen Sie die Verbindung von TCP aufwärts durch und notieren Sie die erste Stufe, die fehlschlägt. Die Stufe, nicht der Fehlercode, sagt Ihnen, ob der Proxy die Ursache ist.

Beginnen Sie dort, wo der Client stoppt

Der Client durchläuft eine feste Reihenfolge: TCP-Verbindung zu Port 443, TLS-Handshake, Zertifikatsprüfung, der SSTP-HTTP-Austausch, PPP-Aushandlung und -Authentifizierung, dann die IP-Konfiguration. Ein Fehler auf jeder Stufe hinterlässt eine andere Signatur, und wer sie verwechselt, landet auf der falschen Konfigurationsseite.

Ein TCP-Fehler ist eine Zeitüberschreitung oder ein Reset, bevor ein einziges TLS-Byte erscheint. Ein TLS-Fehler ist eine Warnung oder eine Handshake-Zeitüberschreitung. Ein Zertifikatsfehler erzeugt eine Warnung über die Kette oder den Namen. Ein HTTP-Fehler kommt nach einem erfolgreichen Handshake, oft als Statuscode oder sofortiges Schließen. Ein PPP-Fehler kommt, nachdem der Tunnel technisch aufgebaut ist, weshalb er wie ein Authentifizierungsproblem aussieht.

Lesen Sie im Client-Protokoll die letzte erfolgreiche Stufe statt der ersten Fehlerzeile. Die Fehlerzeile ist meist der Client, der die Folge meldet, während die Stufengrenze die Komponente benennt, die abgelehnt hat.

Was SSTP vom Netz verlangt zu tragen

SSTP läuft über TLS auf TCP 443 und sendet dann eine HTTP-Anfrage namens SSTP_DUPLEX_POST, definiert in der SSTP-Spezifikation, an einen Pfad der Form /sra_{GUID}/. Die Anfrage deklariert eine praktisch unbegrenzte Inhaltslänge und hält den Strom in beide Richtungen für die gesamte Sitzungsdauer offen. Die PPP-Rahmen wandern innerhalb dieses Stroms.

Deshalb kann ein Proxy, der gewöhnliches Surfen verarbeitet, trotzdem scheitern. Ein GET oder POST mit endlichem Body lässt sich puffern, prüfen und weiterleiten; ein Duplexstrom mit einem Body, der nie endet, nicht. Ein Proxy, der auf den Abschluss des Bodys wartet, wartet ewig, und der Client läuft schließlich in eine Zeitüberschreitung.

Methodenfilterung und Authentifizierung bringen eigene Fehlermodi mit. Fordert der Proxy Anmeldedaten für die Anfrage an, antwortet der VPN-Client möglicherweise nicht, obwohl der Browser es täte. Entfernt oder schreibt er die Methode um, weist das Gateway die Anfrage ab, bevor PPP beginnt.

Warum die Inspektion die Identität ändert

Ein TLS-inspektionierender Proxy beendet die TLS-Verbindung des Clients und öffnet eine separate Verbindung zum Gateway. Der Client validiert daher das Zertifikat des Proxys, nicht das des Gateways, und das Gateway sieht den Proxy als seinen Gegenüber. Wenn die Organisation ihre eigene Root verteilt, können Browser und VPN-Client diese Kette beide akzeptieren, sodass der Handshake gelingt und das Problem auf die nächste Stufe wandert.

Eine erfolgreiche Validierung heißt nicht, dass der Proxy die Sitzung tragen kann. Er muss weiterhin einen unbegrenzten bidirektionalen POST ohne Pufferung weiterleiten und beide Verbindungen stundenlang am Leben halten. Viele Inspektionsprodukte sind für Anfrage-Antwort-Verkehr gebaut und bewältigen diesen Fall schlecht oder gar nicht.

Deshalb ist das Hinzufügen einer unbekannten Root oder das Abschalten der Prüfung die falsche Reparatur. Es ändert, welches Zertifikat der Client akzeptiert; an der Stream-Verarbeitung, die die Sitzung tatsächlich gebrochen hat, ändert es nichts.

Bestimmen Sie den Aussteller, bevor Sie Einstellungen ändern

Fragen Sie den Endpunkt, welches Zertifikat er vorzeigt und wer es signiert hat. Die folgenden Befehle zeigen Kette und Aussteller, ohne eine VPN-Sitzung zu starten:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

Ist der Aussteller eine öffentliche CA, wird die Verbindung für diesen Host wahrscheinlich nicht abgefangen, und der Fehler liegt woanders. Ist der Aussteller die eigene CA der Organisation, ist die Inspektion aktiv und das Gateway wird über einen Proxy erreicht. Vergleichen Sie den Fingerabdruck mit dem, den das Netzwerkteam erwartet, bevor Sie allein aus dem Namen einen Schluss ziehen.

Ein Browsertest zum selben Host beweist nur, dass der Proxy ein GET akzeptiert. Er sagt nichts über die SSTP-Methode, die Anfrage-URI oder die Lebensdauer des Bodys aus, also behandeln Sie eine funktionierende Intranetseite nicht als Beleg dafür, dass der Tunnelpfad unterstützt wird.

Wählen Sie den unterstützten Pfad

Stellen Sie dem Netzwerkverantwortlichen eine konkrete Frage: Erlaubt der Proxy einen ungepufferten Duplex-POST zu diesem Gateway auf Port 443? Ein Ja führt zu einer Ausnahme im Proxy oder zu einer dokumentierten Umgehung für den VPN-Host. Ein Nein bedeutet, dass der inspizierte Pfad SSTP nicht tragen kann, und die unterstützte Lösung ist ein anderer Pfad oder ein anderes Protokoll statt einer Client-Anpassung.

Zu den Optionen gehören meist ein nicht inspizierter Ausgang für das VPN-Gateway, ein Split-Tunnel-Design, das nur Unternehmensverkehr durch den Proxy schickt, oder ein alternatives Protokoll, das die Organisation auf einem anderen Port unterstützt. Jede gehört zum Netzwerkdesign, und jede sollte mit demselben Gerät und Profil getestet werden, damit der Vergleich den Pfad isoliert.

Dokumentieren Sie das Ergebnis: Aussteller, fehlgeschlagene Stufe, Proxy-Regel und gewählter Pfad. Die nächste Person, die denselben Stillstand bei 98 Prozent sieht, kann dann eine Tatsache prüfen, statt den ganzen Durchlauf zu wiederholen.