SSTP faalt waar HTTPS in de browser slaagt: waarom

De browser opent de VPN-hostnaam via HTTPS zonder klagen, en de SSTP-client weigert nog steeds te verbinden. Niets aan dat paar is tegenstrijdig. SSTP gebruikt TLS als buitenste transport en voert daarna zijn eigen aanvraag en PPP-payload binnen die verbinding uit, dus een geslaagde paginalading bewijst maar één smal ding: de host antwoordt op een GET op poort 443. De client stelt een andere vraag, en de server beantwoordt die misschien slecht.

De pagina laadt en de tunnel niet

Mensen grijpen naar de browsertest omdat hij snel is, en behandelen het resultaat dan als bewijs dat de server bereikbaar en geconfigureerd is. Het is bewijs over een GET naar het pad dat de adresbalk opende, niets meer. Het VPN-gesprek begint na dezelfde TLS-handshake, maar stuurt een methode en een pad die een webpagina nooit gebruikt. Een 200 voor de browser zegt dus niets over of het SSTP-eindpunt bestaat.

Scheid de twee waarnemingen en de zoektocht wordt korter. Transport en certificaatketen werken, en iets in de protocoluitwisseling daarboven niet. Dat is een ander onderzoek dan een kapotte poort of een verlopen certificaat, en het vraagt ander bewijs.

Wat de SSTP-client werkelijk verstuurt

De client stuurt een HTTP-aanvraag met de methode SSTP_DUPLEX_POST naar het pad /sra_{GUID}/ en houdt daarna de verbindingsbody open als een tweerichtingsstroom die PPP-frames draagt. Een conforme server antwoordt HTTP/1.1 200 en gedraagt zich niet langer als webserver. Al het andere is een signatuur: 405 of 404 betekent dat het eindpunt er niet is, 301 of 302 betekent dat iets de aanvraag omleidt, en een onmiddellijke FIN betekent dat een proxy of server de stroom sloot.

Daarom moet het doel een SSTP-server zijn en geen webserver met een TLS-certificaat erop geschroefd. De methode, het pad en de langdurige body zijn protocolvereisten, dus een reverse proxy kan ze niet louter via configuratie toevoegen. Een proxy die gewone HTTPS perfect doorstuurt, kan een methode die hij niet kent alsnog weigeren.

Waar een proxy of webserver de stroom breekt

Een tussenpartij inspecteert de HTTP-aanvraagregel voordat hij iets doorstuurt, en een aangepaste methode met een ongebruikelijk pad kan op zijn regels stuklopen. Sommige apparaten serveren een normale pagina terwijl ze de tunnel weigeren of onderbreken, dus de client meldt een verbinding die begint en dan sterft in plaats van een schone weigering. Andere accepteren de aanvraag en passen dan een body- of idle-timeout toe die de PPP-keepalives niet overleven. Beide zien er vanaf de clientkant hetzelfde uit, daarom is de fase die faalde belangrijker dan de fouttekst.

Poort 443 delen tussen een website en SSTP is een routingkeuze, geen belofte dat elke hop beide gesprekken hetzelfde behandelt. Als er een loadbalancer, firewall of TLS-terminator in het pad zit, zet die dan op de lijst met verdachten voordat je de VPN-configuratie aanraakt.

Test de fasen apart

Voer de controles in volgorde uit en stop bij de eerste fout, want elke fase sluit een andere laag uit. De TLS-probe hieronder scheidt de certificaatidentiteit van alles wat SSTP doet. Vervang de hostnaam door je eindpunt en lees het subject en de keten die hij afdrukt.

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

Beeld daarna het resterende bewijs af op de fasen in plaats van te gissen uit de clientfout. De tabel hieronder is de checklist voor het ticket, met de signatuur die de ene fout van de volgende scheidt.

Noteer de laatste fase die slaagde in het ticket in plaats van "kan niet verbinden" te schrijven. De MS-SSTP-specificatie documenteert de aanvraag en de PPP-uitwisseling die op de TLS-handshake volgen, en is de referentie voor waarom een browsertest geen van beide kan vervangen.

Eerst identiteit, dan PPP

TLS-identiteit en PPP-authenticatie zijn opeenvolgend, niet alternatief, en ze verwarren stuurt mensen naar de verkeerde serverinstelling. De client valideert eerst het servercertificaat en het beoogde doel ervan, daarna onderhandelt PPP zijn eigen toestand en authenticeert de gebruiker met een challenge-responsemethode of EAP. Een certificaatprobleem geeft een andere fout dan een geweigerd wachtwoord, en geen van beide fouten beschrijft de fase die de andere dekt.

De hostnaam door een adres vervangen, of voorbij de certificaatwaarschuwing klikken, verwijdert de controle die de falende fase zou hebben geïdentificeerd in plaats van hem te verhelpen. Houd de waarschuwing en lees hem. Stel ook geen PPP-wachtwoord opnieuw in wanneer de HTTP-uitwisseling nooit het SSTP-gedrag bereikte, want de inloggegevens zijn nooit gevraagd.