SSTP scheitert, wo HTTPS im Browser gelingt: warum

Der Browser öffnet den VPN-Hostnamen über HTTPS ohne Beanstandung, und der SSTP-Client verweigert trotzdem die Verbindung. An diesem Paar ist nichts widersprüchlich. SSTP nutzt TLS als äußeren Transport und führt dann seine eigene Anfrage und PPP-Nutzlast innerhalb dieser Verbindung aus, sodass ein erfolgreicher Seitenaufruf nur eine enge Sache beweist: Der Host antwortet auf ein GET an Port 443. Der Client stellt eine andere Frage, und der Server beantwortet sie vielleicht schlecht.

Die Seite lädt, der Tunnel nicht

Leute greifen zum Browsertest, weil er schnell ist, und halten das Ergebnis dann für den Beweis, dass der Server erreichbar und konfiguriert ist. Es ist ein Beweis für ein GET auf den Pfad, den die Adressleiste geöffnet hat, mehr nicht. Das VPN-Gespräch beginnt nach demselben TLS-Handshake, sendet aber eine Methode und einen Pfad, die eine Webseite nie verwendet. Ein 200 für den Browser sagt daher nichts darüber aus, ob der SSTP-Endpunkt existiert.

Trennen Sie die beiden Beobachtungen, und die Suche wird kürzer. Transport und Zertifikatskette funktionieren, und etwas im Protokollaustausch darüber funktioniert nicht. Das ist eine andere Untersuchung als ein defekter Port oder ein abgelaufenes Zertifikat und verlangt andere Belege.

Was der SSTP-Client tatsächlich sendet

Der Client sendet eine HTTP-Anfrage mit der Methode SSTP_DUPLEX_POST an den Pfad /sra_{GUID}/ und hält dann den Verbindungskörper als bidirektionalen Strom offen, der PPP-Frames trägt. Ein konformer Server antwortet mit HTTP/1.1 200 und hört auf, sich wie ein Webserver zu verhalten. Alles andere ist eine Signatur: 405 oder 404 bedeutet, der Endpunkt fehlt, 301 oder 302 bedeutet, etwas leitet die Anfrage um, und ein sofortiges FIN bedeutet, ein Proxy oder Server hat den Strom geschlossen.

Deshalb muss das Ziel ein SSTP-Server sein und kein Webserver mit aufgesetztem TLS-Zertifikat. Methode, Pfad und der langlebige Körper sind Protokollanforderungen, ein Reverse-Proxy kann sie also nicht allein durch Konfiguration hinzufügen. Ein Proxy, der gewöhnliches HTTPS perfekt weiterleitet, kann eine Methode, die er nicht kennt, trotzdem ablehnen.

Wo ein Proxy oder Webserver den Strom bricht

Ein Vermittler prüft die HTTP-Anfragezeile, bevor er etwas weiterleitet, und eine eigene Methode mit ungewöhnlichem Pfad kann an seinen Regeln scheitern. Manche Geräte liefern eine normale Seite aus, während sie den Tunnel ablehnen oder unterbrechen, sodass der Client eine Verbindung meldet, die beginnt und dann stirbt, statt einer sauberen Ablehnung. Andere nehmen die Anfrage an und wenden dann einen Körper- oder Leerlauf-Timeout an, den die PPP-Keepalives nicht überstehen. Beides sieht von der Clientseite gleich aus, deshalb ist die fehlgeschlagene Stufe wichtiger als der Fehlertext.

Port 443 zwischen einer Website und SSTP zu teilen ist eine Routing-Entscheidung, kein Versprechen, dass jeder Hop beide Gespräche gleich behandelt. Wenn ein Load Balancer, eine Firewall oder ein TLS-Terminator im Pfad liegt, setzen Sie ihn auf die Liste der Verdächtigen, bevor Sie die VPN-Konfiguration anfassen.

Testen Sie die Stufen getrennt

Führen Sie die Prüfungen der Reihe nach aus und stoppen Sie beim ersten Fehler, weil jede Stufe eine andere Schicht ausschließt. Die TLS-Sonde unten trennt die Zertifikatsidentität von allem, was SSTP tut. Ersetzen Sie den Hostnamen durch Ihren Endpunkt und lesen Sie den Subject und die Kette, die sie ausgibt.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com

Ordnen Sie dann die übrigen Belege den Stufen zu, statt aus dem Clientfehler zu raten. Die Tabelle unten ist die Checkliste für das Ticket, mit der Signatur, die einen Fehler vom nächsten trennt.

Notieren Sie im Ticket die letzte erfolgreiche Stufe, statt "keine Verbindung" zu schreiben. Die MS-SSTP-Spezifikation dokumentiert die Anfrage und den PPP-Austausch, die dem TLS-Handshake folgen, und ist die Referenz dafür, warum ein Browsertest keines von beiden ersetzen kann.

Zuerst Identität, dann PPP

TLS-Identität und PPP-Authentifizierung sind aufeinanderfolgend, nicht alternativ, und ihre Verwechslung schickt Leute zur falschen Servereinstellung. Der Client prüft zuerst das Serverzertifikat und seinen vorgesehenen Zweck, dann verhandelt PPP seinen eigenen Zustand und authentifiziert den Benutzer mit einem Challenge-Response-Verfahren oder EAP. Ein Zertifikatsproblem erzeugt einen anderen Fehler als ein abgelehntes Passwort, und keiner der beiden Fehler beschreibt die Stufe, die der andere abdeckt.

Den Hostnamen durch eine Adresse zu ersetzen oder die Zertifikatswarnung wegzuklicken entfernt die Prüfung, die die fehlende Stufe identifiziert hätte, statt sie zu beheben. Behalten Sie die Warnung und lesen Sie sie. Setzen Sie auch kein PPP-Passwort zurück, wenn der HTTP-Austausch nie das SSTP-Verhalten erreicht hat, denn die Anmeldedaten wurden nie abgefragt.