SSTP fejler, hvor browserens HTTPS lykkes: hvorfor
SSTP kører inde i TLS på port 443, men det er ikke en webanmodning. Test TCP, TLS-identitet, SSTP-udvekslingen og PPP-godkendelsen som separate trin.
Browseren åbner VPN-værtsnavnet over HTTPS uden klager, og SSTP-klienten nægter stadig at forbinde. Der er intet modstridende i det par. SSTP bruger TLS som ydre transport og kører derefter sin egen anmodning og PPP-nyttelast inde i den forbindelse, så en vellykket sideindlæsning beviser kun én snæver ting: værten svarer på en GET på port 443. Klienten stiller et andet spørgsmål, og serveren svarer måske dårligt på det.
Siden indlæses, og tunnelen gør ikke
Folk griber efter browsertesten, fordi den er hurtig, og behandler derefter resultatet som bevis for, at serveren er tilgængelig og konfigureret. Det er bevis for en GET til den sti, adresselinjen åbnede, ikke mere. VPN-samtalen begynder efter samme TLS-håndtryk, men sender en metode og en sti, som en webside aldrig bruger. Et 200 til browseren siger derfor intet om, hvorvidt SSTP-endepunktet findes.
Adskil de to observationer, og søgningen bliver kortere. Transport og certifikatkæde virker, og noget i protokoludvekslingen ovenover gør ikke. Det er en anden undersøgelse end en brudt port eller et udløbet certifikat, og den kræver andre beviser.
Hvad SSTP-klienten faktisk sender
Klienten sender en HTTP-anmodning med metoden SSTP_DUPLEX_POST til stien /sra_{GUID}/ og holder derefter forbindelsens krop åben som en tovejsstrøm, der bærer PPP-rammer. En compliant server svarer HTTP/1.1 200 og holder op med at opføre sig som en webserver. Alt andet er en signatur: 405 eller 404 betyder, at endepunktet ikke er der, 301 eller 302 betyder, at noget omdirigerer anmodningen, og et øjeblikkeligt FIN betyder, at en proxy eller server lukkede strømmen.
Derfor skal målet være en SSTP-server og ikke en webserver med et TLS-certifikat boltet på. Metoden, stien og den langvarige krop er protokolkrav, så en omvendt proxy kan ikke tilføje dem alene via konfiguration. En proxy, der videresender almindelig HTTPS perfekt, kan stadig afvise en metode, den ikke genkender.
Hvor en proxy eller webserver bryder strømmen
En mellemled inspicerer HTTP-anmodningslinjen, før den videresender noget, og en brugerdefineret metode med en usædvanlig sti kan fejle dens regler. Nogle enheder leverer en normal side, mens de afviser eller afbryder tunnelen, så klienten rapporterer en forbindelse, der starter og derefter dør, i stedet for en ren afvisning. Andre accepterer anmodningen og anvender derefter en krops- eller inaktivitetstimeout, som PPP-keepalives ikke kan overleve. Begge ser ens ud fra klientsiden, og derfor er det trin, der fejlede, vigtigere end fejlteksten.
At dele port 443 mellem et websted og SSTP er et routingvalg, ikke et løfte om, at hvert hop håndterer begge samtaler ens. Hvis en loadbalancer, firewall eller TLS-terminator ligger i vejen, så føj den til listen over mistænkte, før du rører VPN-konfigurationen.
Test trinnene hver for sig
Kør kontrollerne i rækkefølge, og stop ved den første fejl, fordi hvert trin udelukker et andet lag. TLS-proben nedenfor adskiller certifikatidentitet fra alt, hvad SSTP gør. Erstat værtsnavnet med dit endepunkt, og læs det subject og den kæde, den udskriver.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comAfbild derefter de resterende beviser på trinnene i stedet for at gætte ud fra klientfejlen. Tabellen nedenfor er tjeklisten til at citere i sagen, med den signatur, der adskiller en fejl fra den næste.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
Noter det sidste trin, der lykkedes, i sagen i stedet for at skrive "kan ikke forbinde". MS-SSTP-specifikationen dokumenterer anmodningen og PPP-udvekslingen, der følger efter TLS-håndtrykket, og er referencen for, hvorfor en browsertest ikke kan erstatte nogen af dem.
Identitet først, derefter PPP
TLS-identitet og PPP-godkendelse er sekventielle, ikke alternative, og at forveksle dem sender folk til den forkerte serverindstilling. Klienten validerer først servercertifikatet og dets tilsigtede formål, derefter forhandler PPP sin egen tilstand og godkender brugeren med en challenge-response-metode eller EAP. Et certifikatproblem giver en anden fejl end en afvist adgangskode, og ingen af fejlene beskriver det trin, den anden dækker.
At bytte værtsnavnet ud med en adresse eller klikke forbi certifikatadvarslen fjerner den kontrol, der ville have identificeret det fejlende trin, i stedet for at rette det. Behold advarslen, og læs den. Nulstil heller ikke en PPP-adgangskode, når HTTP-udvekslingen aldrig nåede SSTP-adfærden, fordi legitimationsoplysningerne aldrig blev spurgt om.