SSTP-time-out of certificaatfout: hoe je ze uit elkaar houdt

Een SSTP-verbinding mislukt op twee manieren die vanaf de stoel van de gebruiker hetzelfde lijken, en de reparatie van elk ligt op een andere laag. Een time-out betekent dat een vereiste uitwisseling nooit is afgerond; een certificaatfout betekent dat identiteitsmateriaal aankwam en werd geweigerd. Als je de tweede als de eerste behandelt, ga je naar firewalls en wachtwoorden die nooit het probleem waren. Het onderscheidende bewijs staat in de log van de client zelf, als je die leest voordat je iets verandert.

Twee storingen, twee verschillende uitwisselingen

SSTP draagt een tunnel in een sessie met HTTPS-vorm, daarom overleeft hij netwerken die niets anders dan 443 toestaan. De client rondt een TLS-handshake af, stuurt een HTTP-verzoek met een protocolspecifieke methode, en daarna loopt de tunnel in die stream. Een storing bij een van die stappen stopt de verbinding, en alleen de latere stappen raken inloggegevens.

Die volgorde is de diagnose. Als de TLS-handshake nooit wordt afgerond, zijn er geen inloggegevens verstuurd, dus een wachtwoordreset kan niet helpen. Als de handshake wordt afgerond en daarna blijft hangen, is de identiteit geaccepteerd en heeft iets in het pad van het verzoek die geweigerd. Als de handshake mislukt met een validatiemelding, heeft de server geantwoord en vond de client niet leuk wat hij hoorde. Drie uitkomsten, drie lagen.

De logregel noemt meestal in welke van de drie je zit, daarom is het de moeite waard die vast te leggen vóór de eerste wijziging.

Een time-out betekent dat een fase nooit is afgerond

Begin met naamresolutie en TCP-bereikbaarheid, want een time-out daar ziet er identiek uit aan een time-out later. Een poortcontrole die 443 open meldt, bewijst dat een luisteraar een verbinding heeft geaccepteerd, en niets daarbuiten.

De volgende verdachte is het pad en niet de host. Proxies en applicatiebewuste firewalls weigeren soms de verzoekmethode die SSTP gebruikt, of laten een stream vallen die uren open blijft, en beide gedragingen lijken vanuit de client op een time-out. Een gewone HTTPS-pagina van dezelfde host laadt perfect terwijl de tunnelmethode wordt geweigerd, daarom bewijst browsen naar het eindpunt zo weinig. Test vanuit een netwerk zonder de proxy om die twee gevallen te scheiden.

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

Een time-out vóór enig antwoord van de tegenpartij zegt niets over het account, en het wachtwoord op dat moment wijzigen voegt alleen een variabele toe.

Een certificaatfout betekent dat de identiteit is geweigerd

Hier heeft de server wel geantwoord, dus het netwerk werkt en de vraag verschuift naar identiteit. Vergelijk de naam waarmee de client belt met de namen die het certificaat werkelijk beweert, en controleer dan de geldigheidsdatums en de uitgevende keten.

Een particuliere CA die de client niet vertrouwt, levert dezelfde klasse fout op als een verlopen certificaat, en een klok die uren verkeerd staat ook. Het onbewerkte adres bellen creëert een nieuwe mismatch, want een certificaat beweert namen en geen adressen. Haal bij een beheerde uitrol de bedoelde vertrouwensconfiguratie bij de beheerder op in plaats van een vervangende root te accepteren die een foutpagina aanbiedt. Validatie blijft aan terwijl je de oorzaak oplost.

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

Laat de geslaagde TLS-fase intact zodra die slaagt, want hem later terugdraaien verbergt welke wijziging de tunnel werkelijk heeft gerepareerd.

Waar de twee door elkaar lopen

Beide storingen zien eruit als een verbinding die niet opkomt, en beide komen nadat de gebruiker iets ongerelateerds heeft gewijzigd. Juist die samenloop maakt de verkeerde reparatie een tijdje geloofwaardig.

Twee gewoonten houden ze uit elkaar. Leg de log van de client vast voordat je de configuratie aanraakt, zodat de eerste toestand bewaard blijft. Wijzig één laag per poging, zodat het volgende resultaat bij een bekende variabele hoort. Een poortcontrole en een browser zijn deelwaarnemingen en niet de volledige reeks, en geen van beide vervangt het eigen rapport van de client. Geen van de gewoonten kost iets, en beide verkorten het onderzoek.

De certificaatvraag en de bereikbaarheidsvraag zijn om een reden apart gedocumenteerd.

Test opnieuw met de echte client en ga dan naar binnen

Zodra de concrete correctie zit, probeer het opnieuw met de echte SSTP-client en het echte profiel, niet met een browsertab.

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

Als de sessie verbindt en bronnen nog steeds falen, is de tunnel niet langer de verdachte: ga naar routing, DNS en toegang tot diensten. Dat is een ander onderzoek met ander bewijs. Het vasthouden van de werkende TLS- en authenticatiefasen voorkomt dat het een herhaling van de eerste wordt. Schrijf de fase die faalde in het ticket, anders begint de volgende persoon weer bovenaan.