SSTP feilar der HTTPS i nettlesaren lukkast: kvifor
SSTP køyrer inne i TLS på port 443, men det er ikkje ein webførespurnad. Test TCP, TLS-identitet, SSTP-utvekslinga og PPP-autentisering som separate trinn.
Nettlesaren opnar VPN-vertsnamnet over HTTPS utan klage, og SSTP-klienten nektar framleis å kopla til. Det er ingenting motseiingsfullt i det paret. SSTP brukar TLS som ytre transport og køyrer deretter sin eigen førespurnad og PPP-nyttelast inne i den sambandet, så ei vellukka sideinnlasting beviser berre éin smal ting: verten svarar på ein GET på port 443. Klienten stiller eit anna spørsmål, og serveren svarar kanskje dårleg på det.
Sida lastar og tunnelen ikkje
Folk grip til nettlesartesten fordi han er rask, og handsamar deretter resultatet som prov på at serveren er tilgjengeleg og konfigurert. Det er prov om ein GET til stien adressefeltet opna, ikkje meir. VPN-samtalen byrjar etter same TLS-handtrykk, men sender ein metode og ein sti som ei nettside aldri brukar. Ein 200 for nettlesaren seier derfor ingenting om SSTP-endepunktet finst.
Skil dei to observasjonane og søket blir kortare. Transport og sertifikatkjede verkar, og noko i protokollutvekslinga over dei verkar ikkje. Det er ei anna undersøking enn ein øydelagd port eller eit utløpt sertifikat, og ho krev andre prov.
Kva SSTP-klienten faktisk sender
Klienten sender ein HTTP-førespurnad med metoden SSTP_DUPLEX_POST til stien /sra_{GUID}/, og held deretter kroppen til sambandet open som ein tovegsstraum som ber PPP-rammer. Ein forskriftsmessig server svarar HTTP/1.1 200 og sluttar å oppføre seg som ein webserver. Alt anna er ein signatur: 405 eller 404 tyder at endepunktet ikkje er der, 301 eller 302 tyder at noko omdirigerer førespurnaden, og ein umiddelbar FIN tyder at ein proxy eller server lukka straumen.
Derfor må målet vere ein SSTP-server og ikkje ein webserver med eit TLS-sertifikat bolta på. Metoden, stien og den langvarige kroppen er protokollkrav, så ein omvend proxy kan ikkje leggje dei til berre med konfigurasjon. Ein proxy som videresender vanleg HTTPS perfekt, kan likevel avvise ein metode han ikkje kjenner.
Der ein proxy eller webserver bryt straumen
Ein mellommann inspiserer HTTP-førespurnadslinja før han videresender noko, og ein eigen metode med ein uvanleg sti kan feile på reglane hans. Nokre einingar leverer ei vanleg side medan dei avviser eller avbryt tunnelen, så klienten rapporterer eit samband som startar og deretter døyr i staden for ei rein avvising. Andre godtek førespurnaden og brukar deretter ein kropps- eller inaktivitetstimeout som PPP-keepalive ikkje overlever. Begge ser like ut frå klientsida, derfor er trinnet som feila viktigare enn feilteksten.
Å dele port 443 mellom eit nettstad og SSTP er eit rutingsval, ikkje eit løfte om at kvar hopp handsamar begge samtalane likt. Viss ein lastbalansar, brannmur eller TLS-terminator ligg i vegen, set han på lista over mistenkte før du rører VPN-konfigurasjonen.
Test trinna kvar for seg
Køyr kontrollane i rekkjefølgje og stopp ved første feil, fordi kvart trinn utelukkar eit anna lag. TLS-proben nedanfor skil sertifikatidentiteten frå alt SSTP gjer. Byt ut vertsnamnet med endepunktet ditt og les subject og kjeda han skriv ut.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comKartlegg deretter dei resterande prova mot trinna i staden for å gjette frå klientfeilen. Tabellen nedanfor er sjekklista for saka, med signaturen som skil éin feil frå 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 lukkast i saka i staden for å skrive "kan ikkje kopla til". MS-SSTP-spesifikasjonen dokumenterer førespurnaden og PPP-utvekslinga som følgjer TLS-handtrykket, og er referansen for kvifor ein nettlesartest ikkje kan erstatte nokon av dei.
Identitet først, deretter PPP
TLS-identitet og PPP-autentisering er sekvensielle, ikkje alternative, og å blande dei sender folk til feil serverinnstilling. Klienten validerer først sertifikatet til serveren og det tiltenkte føremålet, deretter forhandlar PPP sin eigen tilstand og autentiserer brukaren med ein challenge-response-metode eller EAP. Eit sertifikatproblem gir ein annan feil enn eit avvist passord, og ingen av feila skildrar trinnet den andre dekkjer.
Å byte ut vertsnamnet med ei adresse, eller klikke forbi sertifikatåtvaringa, fjernar kontrollen som ville ha identifisert det feilande trinnet i staden for å fikse det. Hald på åtvaringa og les ho. Nullstill heller ikkje eit PPP-passord når HTTP-utvekslinga aldri nådde SSTP-åtferda, fordi påloggingsinformasjonen aldri vart spurd om.