Nabibigo ang SSTP kung saan nagtatagumpay ang HTTPS ng browser: bakit
Tumutukbo ang SSTP sa loob ng TLS sa port 443, ngunit hindi ito web request. Subukan ang TCP, pagkakakilanlan ng TLS, palitan ng SSTP at pagpapatotoo ng PPP bilang magkakahiwalay na yugto.
Binubuksan ng browser ang hostname ng VPN sa HTTPS nang walang reklamo, at ang kliyenteng SSTP ay tumatanggi pa ring kumonekta. Walang magkasalungat sa pares na iyon. Ginagamit ng SSTP ang TLS bilang panlabas na transportasyon at pagkatapos ay pinapatakbo ang sarili nitong kahilingan at PPP payload sa loob ng koneksiyong iyon, kaya ang matagumpay na pag-load ng pahina ay nagpapatunay lamang ng isang makitid na bagay: sinasagot ng host ang isang GET sa port 443. Iba ang itinatanging tanong ng kliyente, at maaaring masagot ito ng server nang masama.
Naglo-load ang pahina at hindi ang tunel
Lumalapit ang mga tao sa pagsubok sa browser dahil mabilis ito, at pagkatapos ay itinuturing ang resulta bilang patunay na maaabot at naka-configure ang server. Patunay ito tungkol sa isang GET sa landas na binuksan ng address bar, wala nang iba. Nagsisimula ang usapan sa VPN pagkatapos ng parehong TLS handshake, ngunit nagpapadala ng isang paraan at landas na hindi kailanman ginagamit ng web page. Kaya ang tugon na 200 para sa browser ay walang sinasabi tungkol sa kung may end point ng SSTP.
Ihiwalay ang dalawang obserbasyon at bumabagsak ang paghahanap. Gumagana ang transportasyon at kadena ng sertipiko, at may isang bagay sa palitan ng protocol sa itaas nito na hindi gumagana. Ibang imbestigasyon ito kaysa sa sirang port o nag-expire na sertipiko, at nangangailangan ito ng ibang ebidensiya.
Ano ang aktuwal na ipinapadala ng kliyenteng SSTP
Nagpapadala ang kliyente ng HTTP request gamit ang paraang SSTP_DUPLEX_POST sa landas na /sra_{GUID}/, pagkatapos ay pinananatiling bukas ang katawan ng koneksiyon bilang dalawang-direksiyong stream na nagdadala ng mga PPP frame. Sinasagot ng sumusunod na server ang HTTP/1.1 200 at tumitigil sa pag-uugali na parang web server. Anumang iba pa ay isang lagda: 405 o 404 ay nangangahulugang wala ang end point, 301 o 302 ay nangangahulugang may nagre-redirect ng kahilingan, at agarang FIN ay nangangahulugang isinara ng proxy o server ang stream.
Kaya ang target ay dapat na isang SSTP server at hindi isang web server na may nakakabit na TLS certificate. Ang paraan, landas at pangmatagalang katawan ay mga pangangailangan ng protocol, kaya hindi maaaring idagdag ng reverse proxy ang mga ito sa pamamagitan lamang ng configuration. Ang proxy na perpektong nagpapasa ng ordinaryong HTTPS ay maaari pa ring tumanggi sa isang paraang hindi nito kinikilala.
Saan binabali ng proxy o web server ang stream
Sinusuri ng tagapamagitan ang linya ng HTTP request bago magpasa ng anuman, at ang custom na paraan na may kakaibang landas ay maaaring mabigo sa mga tuntunin nito. May mga device na naghahain ng normal na pahina habang tinatanggihan o ginagambala ang tunel, kaya nag-uulat ang kliyente ng koneksiyong nagsisimula at pagkatapos ay namamatay sa halip na malinis na pagtanggi. Ang iba ay tumatanggap ng kahilingan, pagkatapos ay naglalapat ng timeout ng katawan o idle na hindi kayang tiisin ng PPP keepalives. Pareho silang mukhang magkatulad mula sa panig ng kliyente, kaya ang yugtong nabigo ay mas mahalaga kaysa sa teksto ng error.
Ang pagbabahagi ng port 443 sa pagitan ng website at SSTP ay isang pagpili sa routing, hindi isang pangakong trinatrato ng bawat hop ang dalawang usapan nang pareho. Kung may load balancer, firewall o TLS terminator sa landas, idagdag ito sa listahan ng mga pinaghihinalaan bago hawakan ang configuration ng VPN.
Subukan ang mga yugto nang hiwalay
Patakbuhin ang mga pagsusuri sa pagkakasunod-sunod at huminto sa unang kabiguan, dahil ang bawat yugto ay nag-aalis ng ibang layer. Ang TLS probe sa ibaba ay naghihiwalay ng pagkakakilanlan ng sertipiko mula sa lahat ng ginagawa ng SSTP. Palitan ang hostname ng iyong end point at basahin ang subject at kadena na ipinapasa nito.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comPagkatapos ay itugma ang natitirang ebidensiya sa mga yugto sa halip na hulaan mula sa error ng kliyente. Ang talahanayan sa ibaba ay ang checklist na sipiin sa ticket, kasama ang lagda na naghihiwalay ng isang kabiguan sa susunod.
| 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 |
Itala sa ticket ang huling yugtong nagtagumpay sa halip na isulat ang "hindi makakonekta". Ang espesipikasyon ng MS-SSTP ay nagdodokumento ng kahilingan at palitan ng PPP na sumusunod sa TLS handshake, at ito ang sanggunian kung bakit hindi maaaring palitan ng pagsubok sa browser ang alinman sa dalawa.
Pagkakakilanlan muna, pagkatapos ay PPP
Ang pagkakakilanlan ng TLS at pagpapatotoo ng PPP ay sunud-sunod, hindi alternatibo, at ang pagkalito sa mga ito ay nagdadala ng mga tao sa maling setting ng server. Binibigyang-katwiran muna ng kliyente ang sertipiko ng server at ang nilalayong layunin nito, pagkatapos ay nakikipag-usap ang PPP sa sarili nitong estado at pinapatotohanan ang user gamit ang paraang hamon-tugon o EAP. Ang problema sa sertipiko ay nagbubunga ng ibang error kaysa sa tinanggihang password, at wala sa dalawang error ang naglalarawan ng yugtong sakop ng isa.
Ang pagpapalit ng hostname ng isang address, o pag-click lampas sa babala ng sertipiko, ay nag-aalis ng pagsusuring makikilala sana ang yugtong nabigo sa halip na ayusin ito. Panatilihin ang babala at basahin ito. Huwag ding i-reset ang PPP password kapag ang palitan ng HTTP ay hindi kailanman umabot sa pag-uugali ng SSTP, dahil hindi kailanman hiniling ang kredensiyal.