SSTP is PPP over HTTPS, geen webpagina op poort 443

SSTP draagt PPP binnen een HTTPS-verbinding, daarom lijkt het voor alles ertussen op webverkeer. TLS en HTTP zetten het buitenste kanaal op, daarna bereiden SSTP-controleboodschappen de tunnel voor, en PPP levert het gedrag van de sessie. Een browser die een pagina op hetzelfde adres laadt heeft slechts een deel van de eerste fase voltooid. Dat als VPN-test behandelen is de manier waarop een werkende proxy de schuld krijgt van een protocolverschil.

Loop de vier fasen op volgorde door, en de fout die u ziet valt in een ervan.

Fase 1: TCP en TLS

De client opent een TCP-verbinding naar poort 443 en voert een TLS-handshake uit. De certificaatketen moet overeenkomen met de hostnaam waarmee de client is geconfigureerd. Een naamverschil levert hier een fout op voordat er enig SSTP-bericht wordt uitgewisseld, en de SSTP-specificatie gaat ervan uit dat dit buitenste HTTPS-kanaal al bestaat. Niets in de latere fasen kan een vertrouwensfout hier compenseren.

Een gewone webserver kan deze fase perfect afronden en toch in de volgende falen. TLS-succes is bewijs over het certificaat, niet over het protocol erachter.

Fase 2: het HTTPS-verzoek

SSTP doet zijn verzoek met een specifieke methode, SSTP_DUPLEX_POST, en houdt de uitwisseling open in plaats van een document terug te sturen. Een server of proxy die voor gewone paginaverzoeken is geconfigureerd, kan de verbinding accepteren en dan de methode weigeren. Die weigering is het compatibiliteitsprobleem dat mensen meestal beschrijven als een geblokkeerde poort 443.

Lees de responscode en de methode in het serverlog. Een weigering in deze fase is een ander probleem dan een TCP-time-out, en beide leiden tot verschillende oplossingen.

Fase 3: controleboodschappen

Zodra het verzoek is geaccepteerd, wisselt SSTP controleboodschappen uit die de tunnel onderhandelen en voorbereiden. Dat zijn protocolboodschappen in de HTTPS-body, geen HTTP-verzoeken, dus een proxy die bodies inspecteert en herschrijft kan ze breken terwijl paginaverzoeken onaangetast blijven.

Hier verdient een deep-inspection-middlebox zijn reputatie. Als pagina's laden en de VPN faalt, controleer dan of de body wordt gewijzigd in plaats van of de poort open is.

Fase 4: PPP neemt over

PPP levert dan het gedrag van de sessie: linkonderhandeling, authenticatie en de configuratie van de netwerklaag die volgt. PPP-authenticatie staat los van de TLS-controle die de client al heeft doorstaan. Een servercertificaat dat de client accepteert zegt niets over of de inloggegevens van de gebruiker geldig zijn of het account is geautoriseerd.

Een geaccepteerd certificaat en een geweigerde aanmelding zijn niet tegenstrijdig. Het zijn opeenvolgende fasen met onafhankelijke uitkomsten.

Authenticatie heeft meerdere rollen

De client valideert de identiteit van de TLS-server tegen zijn vertrouwensopslag en de geconfigureerde naam. Daarna authenticeert PPP de gebruiker of de machine, afhankelijk van de uitrol. De server kan zijn eigen beleid toevoegen over wie mag verbinden en wat hij mag bereiken. Houd de hostnaam consistent met de identiteit van het certificaat, want een ruw adres vervangen maakt van een werkende opzet een naamcontrolefout.

Noteer welke fase de fout meldde. Certificaat, methode, controleboodschap, PPP-authenticatie, dan routes: vijf plekken, vijf reparaties.

Wat een browsertest wel en niet kan laten zien

Een pagina op het adres laden bewijst DNS-resolutie, TCP-bereikbaarheid en dat er iets luistert dat HTTP spreekt. Het bewijst niet dat de methode wordt geaccepteerd, dat de controle-uitwisseling overleeft of dat PPP-authenticatie is geconfigureerd. Gebruik een client die SSTP implementeert in plaats van een ander profiel om te zetten door de poort te wijzigen.

Zodra de sessie staat, bepalen routes, DNS en doorsturing aan de serverkant nog steeds wat de gebruiker kan bereiken. De tunnel is een pad, geen autorisatie.