SSTP misluk waar die blaaier se HTTPS slaag: hoekom
SSTP loop binne TLS op poort 443, maar dit is nie 'n webversoek nie. Toets TCP, TLS-identiteit, die SSTP-uitruiling en PPP-verifikasie as aparte fases.
Die blaaier open die VPN-gasheernaam oor HTTPS sonder klag, en die SSTP kliënt weier steeds om te verbind. Niks aan daardie paar is teenstrydig nie. SSTP gebruik TLS as 'n buitenste vervoer en voer dan sy eie versoek en PPP-lading binne daardie verbinding uit, so 'n suksesvolle bladsy bewys een ding: die gasheer antwoord 'n GET op poort 443. Die kliënt vra 'n ander vraag, en die bediener antwoord dit dalk sleg.
Die bladsy laai en die tonnel nie
Mense gryp na die blaaier-toets omdat dit vinnig is, en behandel dan die resultaat as bewys dat die bediener bereikbaar en gekonfigureer is. Dit is bewys oor 'n GET na watter pad die adresbalk ook oopgemaak het, niks meer nie. Die VPN-gesprek begin ná dieselfde TLS-handdruk, maar stuur 'n metode en 'n pad wat 'n webblad nooit gebruik nie. 'n 200 vir die blaaier sê dus niks oor of die SSTP-eindpunt bestaan nie.
Skei die twee waarnemings en die soektog word korter. Vervoer en sertifikaatketting werk, en iets in die protokoluitruiling bo hulle werk nie. Dit is 'n ander ondersoek as 'n stukkende poort of 'n vervalde sertifikaat, en dit vra ander bewyse.
Wat die SSTP-kliënt werklik stuur
Die kliënt stuur 'n HTTP-versoek met die metode SSTP_DUPLEX_POST na die pad /sra_{GUID}/, en hou dan die verbindingsliggaam oop as 'n tweerigtingstroom wat PPP-rame dra. 'n Voldoenende bediener antwoord HTTP/1.1 200 en hou op om soos 'n webbediener te gedra. Enigiets anders is 'n kenmerk: 405 of 404 beteken die eindpunt is nie daar nie, 301 of 302 beteken iets herlei die versoek, en 'n onmiddellike FIN beteken 'n volmag of bediener het die stroom gesluit.
Daarom moet die teiken 'n SSTP-bediener wees eerder as 'n webbediener met 'n TLS-sertifikaat aangebou. Die metode, die pad en die langdurige liggaam is protokolvereistes, so 'n omgekeerde volmag kan hulle nie bloot uit konfigurasie byvoeg nie. 'n Volmag wat gewone HTTPS perfek deurstuur, kan steeds 'n metode weier wat dit nie herken nie.
Waar 'n volmag of webbediener die stroom breek
'n Tussenparty ondersoek die HTTP-versoeklyn voordat dit iets deurstuur, en 'n pasgemaakte metode met 'n ongewone pad kan sy reëls faal. Sekere toestelle bedien 'n normale bladsy terwyl hulle die tonnel verwerp of onderbreek, so die kliënt rapporteer 'n verbinding wat begin en dan sterf eerder as 'n skoon weiering. Ander aanvaar die versoek en pas dan 'n liggaam- of ledige tydsperdatum toe wat die PPP-lewendhouers nie oorleef nie. Beide lyk dieselfde van die kliënt se kant, daarom is die fase wat gefaal het belangriker as die foutteks.
Om poort 443 tussen 'n webwerf en SSTP te deel is 'n roeteringkeuse, nie 'n belofte dat elke hop beide gesprekke dieselfde hanteer nie. As 'n lasbalanseerder, brandmuur of TLS-termineerder in die pad sit, voeg dit by die verdagtes voordat jy aan die VPN-konfigurasie raak.
Toets die fases afsonderlik
Voer die kontroles in volgorde uit en stop by die eerste fout, want elke fase sluit 'n ander laag uit. Die TLS-ondersoek hieronder skei sertifikaatidentiteit van enigiets wat SSTP doen. Vervang die gasheernaam met jou eindpunt en lees die onderwerp en ketting wat dit druk.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comBeeld dan die oorblywende bewyse op die fases af eerder as om uit die kliëntfout te raai. Die tabel hieronder is die kontrolelys vir die kaartjie, met die kenmerk wat een fout van die volgende skei.
| 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 |
Teken die laaste fase aan wat geslaag het in die kaartjie in plaas daarvan om "cannot connect" te skryf. Die MS-SSTP-spesifikasie dokumenteer die versoek en die PPP-uitruiling wat op die TLS-handdruk volg, wat die verwysing is vir waarom 'n blaaier-toets nie vir enige van die twee kan instaan nie.
Identiteit eerste, dan PPP
TLS-identiteit en PPP-verifikasie is opeenvolgend, nie alternatief nie, en om hulle te verwar stuur mense na die verkeerde bedienerinstelling. Die kliënt valideer eers die bediener-sertifikaat en sy bedoelde doel, dan onderhandel PPP sy eie toestand en verifieer die gebruiker met 'n uitdaging-responsmetode of EAP. 'n Sertifikaatprobleem lewer 'n ander fout as 'n verwerpte wagwoord, en geen van die twee foute beskryf die fase wat die ander dek nie.
Om die gasheernaam vir 'n adres te ruil, of om verby die sertifikaatwaarskuwing te klik, verwyder die kontrole wat die falende fase sou identifiseer eerder as om dit reg te maak. Hou die waarskuwing en lees dit. Moet ook nie 'n PPP-wagwoord herstel wanneer die HTTP-uitruiling nooit die SSTP-gedrag bereik het nie, want die geloofsbriewe is nooit gevra nie.