SSTP-Timeout oder Zertifikatfehler: So unterscheiden Sie beide

Eine SSTP-Verbindung scheitert auf zwei Arten, die vom Stuhl des Nutzers gleich aussehen, und die Reparatur für jede liegt auf einer anderen Ebene. Ein Timeout bedeutet, dass ein erforderlicher Austausch nie abgeschlossen wurde; ein Zertifikatfehler bedeutet, dass Identitätsmaterial ankam und abgelehnt wurde. Behandeln Sie das zweite wie das erste, landen Sie bei Firewalls und Passwörtern, die nie das Problem waren. Der unterscheidende Beweis steht im eigenen Protokoll des Clients, wenn Sie es lesen, bevor Sie etwas ändern.

Zwei Fehler, zwei verschiedene Austausche

SSTP trägt einen Tunnel in einer Sitzung mit HTTPS-Form, deshalb überlebt er Netzwerke, die nichts außer 443 erlauben. Der Client schließt einen TLS-Handshake ab, sendet eine HTTP-Anfrage mit einer protokollspezifischen Methode, und dann läuft der Tunnel in diesem Strom. Ein Fehler bei einem dieser Schritte beendet die Verbindung, und nur die späteren betreffen Anmeldedaten.

Diese Reihenfolge ist die Diagnose. Wenn der TLS-Handshake nie abgeschlossen wird, wurden keine Anmeldedaten gesendet, also kann ein Passwort-Reset nicht helfen. Wenn der Handshake abgeschlossen wird und dann hängt, wurde die Identität akzeptiert, und etwas im Anfragepfad hat sie abgelehnt. Wenn der Handshake mit einer Validierungsmeldung scheitert, hat der Server geantwortet, und dem Client gefiel nicht, was er hörte. Drei Ergebnisse, drei Ebenen.

Die Protokollzeile nennt normalerweise, in welchem der drei Fälle Sie sich befinden, deshalb lohnt es sich, sie vor der ersten Änderung festzuhalten.

Ein Timeout bedeutet, dass eine Phase nie abgeschlossen wurde

Beginnen Sie mit Namensauflösung und TCP-Erreichbarkeit, weil ein Timeout dort genauso aussieht wie ein Timeout später. Ein Portprüfer, der 443 als offen meldet, beweist, dass ein Listener eine Verbindung angenommen hat, und nichts darüber hinaus.

Der nächste Verdächtige ist der Pfad und nicht der Host. Proxys und anwendungsbewusste Firewalls lehnen manchmal die Anfragemethode ab, die SSTP verwendet, oder verwerfen einen Strom, der stundenlang offen bleibt, und beides sieht aus Client-Sicht wie ein Timeout aus. Eine gewöhnliche HTTPS-Seite, die derselbe Host ausliefert, lädt einwandfrei, während die Tunnelmethode abgelehnt wird, deshalb beweist das Surfen zum Endpunkt so wenig. Testen Sie aus einem Netzwerk ohne den Proxy, um diese beiden Fälle zu trennen.

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

Ein Timeout vor jeder Antwort des Gegenübers sagt nichts über das Konto aus, und das Passwort zu diesem Zeitpunkt zu ändern, fügt nur eine Variable hinzu.

Ein Zertifikatfehler bedeutet, dass die Identität abgelehnt wurde

Hier hat der Server tatsächlich geantwortet, also funktioniert das Netzwerk, und die Frage wandert zur Identität. Vergleichen Sie den Namen, den der Client wählt, mit den Namen, die das Zertifikat tatsächlich behauptet, und prüfen Sie dann Gültigkeitsdaten und die ausstellende Kette.

Eine private CA, der der Client nicht vertraut, erzeugt dieselbe Fehlerklasse wie ein abgelaufenes Zertifikat, ebenso eine Uhr, die Stunden falsch geht. Die rohe Adresse zu wählen erzeugt eine neue Abweichung, weil ein Zertifikat Namen behauptet und keine Adressen. Holen Sie in einem verwalteten Deployment die vorgesehene Vertrauenskonfiguration von ihrem Administrator, statt eine Ersatz-Wurzel zu akzeptieren, die eine Fehlerseite anbietet. Die Validierung bleibt an, während Sie die Ursache beheben.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

Halten Sie die erfolgreiche TLS-Phase unangetastet, sobald sie besteht, denn sie später zurückzunehmen verbirgt, welche Änderung den Tunnel tatsächlich repariert hat.

Wo die beiden verwechselt werden

Beide Fehler erscheinen als eine Verbindung, die nicht hochkommt, und beide treten auf, nachdem der Nutzer etwas Unbeteiligtes geändert hat. Diese Koinzidenz lässt die falsche Reparatur eine Weile plausibel aussehen.

Zwei Gewohnheiten halten sie auseinander. Halten Sie das Client-Protokoll fest, bevor Sie die Konfiguration anfassen, damit der erste Zustand erhalten bleibt. Ändern Sie pro Versuch eine Ebene, damit das nächste Ergebnis zu einer bekannten Variablen gehört. Ein Portprüfer und ein Browser sind Teilbeobachtungen statt der vollständigen Abfolge, und keiner ersetzt den eigenen Bericht des Clients. Keine der Gewohnheiten kostet etwas, und beide verkürzen die Untersuchung.

Die Zertifikatsfrage und die Erreichbarkeitsfrage sind aus gutem Grund getrennt dokumentiert.

Testen Sie mit dem echten Client erneut und gehen Sie dann nach innen

Sobald die konkrete Korrektur sitzt, versuchen Sie es mit dem tatsächlichen SSTP-Client und dem echten Profil erneut, nicht mit einem Browser-Tab.

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

Wenn die Sitzung verbindet und Ressourcen weiterhin scheitern, ist der Tunnel nicht mehr verdächtig: gehen Sie zu Routing, DNS und Dienstzugriff über. Das ist eine andere Untersuchung mit anderen Beweisen. Das Festhalten an den funktionierenden TLS- und Authentifizierungsphasen verhindert, dass daraus eine Wiederholung der ersten wird. Schreiben Sie die Phase, die gescheitert ist, ins Ticket, sonst beginnt die nächste Person wieder oben.