SSTP feiler der nettleserens HTTPS lykkes: hvorfor
SSTP kjører inne i TLS på port 443, men det er ikke en webforespørsel. Test TCP, TLS-identitet, SSTP-utvekslingen og PPP-autentisering som separate trinn.
Nettleseren åpner VPN-vertsnavnet over HTTPS uten klage, og SSTP-klienten nekter fortsatt å koble til. Det er ingenting motsetningsfylt i det paret. SSTP bruker TLS som ytre transport og kjører deretter sin egen forespørsel og PPP-nyttelast inne i den forbindelsen, så en vellykket sideinnlasting beviser bare én smal ting: verten svarer på en GET på port 443. Klienten stiller et annet spørsmål, og serveren svarer kanskje dårlig på det.
Siden lastes og tunnelen ikke
Folk griper til nettlesertesten fordi den er rask, og behandler deretter resultatet som bevis for at serveren er tilgjengelig og konfigurert. Det er bevis om en GET til stien adressefeltet åpnet, ikke mer. VPN-samtalen begynner etter samme TLS-håndtrykk, men sender en metode og en sti som en nettside aldri bruker. En 200 for nettleseren sier derfor ingenting om hvorvidt SSTP-endepunktet finnes.
Skill de to observasjonene og søket blir kortere. Transport og sertifikatkjede virker, og noe i protokollutvekslingen over dem virker ikke. Det er en annen undersøkelse enn en ødelagt port eller et utløpt sertifikat, og den krever andre bevis.
Hva SSTP-klienten faktisk sender
Klienten sender en HTTP-forespørsel med metoden SSTP_DUPLEX_POST til stien /sra_{GUID}/, og holder deretter forbindelsens kropp åpen som en toveisstrøm som bærer PPP-rammer. En forskriftsmessig server svarer HTTP/1.1 200 og slutter å oppføre seg som en webserver. Alt annet er en signatur: 405 eller 404 betyr at endepunktet ikke er der, 301 eller 302 betyr at noe omdirigerer forespørselen, og en umiddelbar FIN betyr at en proxy eller server lukket strømmen.
Derfor må målet være en SSTP-server og ikke en webserver med et TLS-sertifikat boltet på. Metoden, stien og den langvarige kroppen er protokollkrav, så en omvendt proxy kan ikke legge dem til bare med konfigurasjon. En proxy som videresender vanlig HTTPS perfekt, kan likevel avvise en metode den ikke kjenner.
Der en proxy eller webserver bryter strømmen
En mellomledd inspiserer HTTP-forespørselslinjen før den videresender noe, og en egendefinert metode med en uvanlig sti kan feile på reglene dens. Noen enheter leverer en vanlig side mens de avviser eller avbryter tunnelen, så klienten rapporterer en forbindelse som starter og deretter dør i stedet for en ren avvisning. Andre godtar forespørselen og bruker deretter en kropps- eller inaktivitetstimeout som PPP-keepalive ikke overlever. Begge ser like ut fra klientsiden, derfor er trinnet som feilet viktigere enn feilteksten.
Å dele port 443 mellom et nettsted og SSTP er et rutingsvalg, ikke et løfte om at hvert hopp håndterer begge samtalene likt. Hvis en lastbalanserer, brannmur eller TLS-terminator ligger i veien, sett den på listen over mistenkte før du rører VPN-konfigurasjonen.
Test trinnene hver for seg
Kjør kontrollene i rekkefølge og stopp ved første feil, fordi hvert trinn utelukker et annet lag. TLS-proben nedenfor skiller sertifikatidentitet fra alt SSTP gjør. Erstatt vertsnavnet med endepunktet ditt og les subject og kjeden den skriver ut.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comKartlegg deretter de resterende bevisene mot trinnene i stedet for å gjette fra klientfeilen. Tabellen nedenfor er sjekklisten for saken, med signaturen som skiller én feil fra den neste.
| 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 siste trinnet som lyktes i saken i stedet for å skrive "kan ikke koble til". MS-SSTP-spesifikasjonen dokumenterer forespørselen og PPP-utvekslingen som følger TLS-håndtrykket, og er referansen for hvorfor en nettlesertest ikke kan erstatte noen av dem.
Identitet først, deretter PPP
TLS-identitet og PPP-autentisering er sekvensielle, ikke alternative, og å forveksle dem sender folk til feil serverinnstilling. Klienten validerer først serverens sertifikat og dets tiltenkte formål, deretter forhandler PPP sin egen tilstand og autentiserer brukeren med en challenge-response-metode eller EAP. Et sertifikatproblem gir en annen feil enn et avvist passord, og ingen av feilene beskriver trinnet den andre dekker.
Å bytte vertsnavnet mot en adresse, eller klikke forbi sertifikatadvarselen, fjerner kontrollen som ville ha identifisert det feilende trinnet i stedet for å fikse det. Behold advarselen og les den. Nullstill heller ikke et PPP-passord når HTTP-utvekslingen aldri nådde SSTP-atferden, fordi påloggingsinformasjonen aldri ble spurt om.