SSTP malsukcesas tie, kie HTTPS en la retumilo sukcesas: kial
SSTP funkcias ene de TLS sur pordo 443, sed ĝi ne estas reta peto. Testu TCP, TLS-identecon, la SSTP-interŝanĝon kaj PPP-aŭtentikigon kiel apartajn etapojn.
La retumilo malfermas la VPN-gastigantan nomon per HTTPS sen plendo, kaj la SSTP-kliento ankoraŭ rifuzas konektiĝi. Nenio en tiu paro estas kontraŭdira. SSTP uzas TLS kiel eksteran transporton kaj poste plenumas sian propran peton kaj PPP-ŝarĝon ene de tiu konekto, do sukcesa paĝa ŝarĝo pruvas nur unu mallarĝan aferon: la gastiganto respondas al GET sur pordo 443. La kliento demandas alian demandon, kaj la servilo eble respondos ĝin malbone.
La paĝo ŝarĝiĝas kaj la tunelo ne
Homoj turnas sin al la retumila testo ĉar ĝi estas rapida, kaj poste traktas la rezulton kiel pruvon, ke la servilo estas atingebla kaj agordita. Ĝi estas pruvo pri GET al tiu vojo, kiun malfermis la adresbreto, nenio pli. La VPN-babilado komenciĝas post la sama TLS-manpremo, sed sendas metodon kaj vojon, kiujn retpaĝo neniam uzas. Do respondo 200 por la retumilo diras nenion pri tio, ĉu la SSTP-finpunkto ekzistas.
Apartigu la du observojn kaj la serĉado mallongiĝas. Transporto kaj atestila ĉeno funkcias, kaj io en la protokola interŝanĝo super ili ne funkcias. Tio estas alia esploro ol rompita pordo aŭ eksvalidiĝinta atestilo, kaj ĝi postulas aliajn pruvojn.
Kion la SSTP-kliento efektive sendas
La kliento sendas HTTP-peton kun la metodo SSTP_DUPLEX_POST al la vojo /sra_{GUID}/, poste tenas la korpon de la konekto malferma kiel dudirekta fluo portanta PPP-kadrojn. Konforma servilo respondas HTTP/1.1 200 kaj ĉesas konduti kiel retservilo. Io ajn alia estas subskribo: 405 aŭ 404 signifas, ke la finpunkto ne ekzistas, 301 aŭ 302 signifas, ke io alidirektas la peton, kaj tuja FIN signifas, ke prokurilo aŭ servilo fermis la fluon.
Tial la celo devas esti SSTP-servilo, ne retservilo kun alŝraŭbita TLS-atestilo. La metodo, la vojo kaj la longdaŭra korpo estas protokolaj postuloj, do inversa prokurilo ne povas aldoni ilin nur per agordo. Prokurilo, kiu perfekte plusendas ordinaran HTTPS, tamen povas rifuzi metodon, kiun ĝi ne rekonas.
Kie prokurilo aŭ retservilo rompas la fluon
Interulo inspektas la HTTP-petan linion antaŭ ol plusendi ion, kaj propra metodo kun nekutima vojo povas malsukcesi ĉe ĝiaj reguloj. Iuj aparatoj servas normalan paĝon dum ili rifuzas aŭ interrompas la tunelon, do la kliento raportas konekton, kiu komenciĝas kaj poste mortas, anstataŭ puran rifuzon. Aliaj akceptas la peton, poste aplikas limtempon de korpo aŭ senaktiveco, kiun la PPP-keepalive ne postvivas. Ambaŭ aspektas same de la klienta flanko, tial la etapo, kiu malsukcesis, pli gravas ol la erarteksto.
Dividi pordon 443 inter retejo kaj SSTP estas enkursiga decido, ne promeso, ke ĉiu salteto traktas ambaŭ babiladojn same. Se en la vojo sidas ŝarĝbalancilo, fajroŝirmilo aŭ TLS-finilo, aldonu ĝin al la listo de suspektatoj antaŭ ol tuŝi la VPN-agordon.
Testu la etapojn aparte
Plenumu la kontrolojn laŭorde kaj haltu ĉe la unua malsukceso, ĉar ĉiu etapo ekskludas alian tavolon. La TLS-sondilo sube apartigas atestilan identecon de ĉio, kion SSTP faras. Anstataŭigu la gastigantan nomon per via finpunkto kaj legu la subjekton kaj la ĉenon, kiujn ĝi presas.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comPoste mapu la ceterajn pruvojn al la etapoj anstataŭ diveni el la klienta eraro. La tabelo sube estas la kontrol-listo por citi en la bileto, kun la subskribo, kiu apartigas unu malsukceson de la sekva.
| 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 |
Notu en la bileto la lastan etapon, kiu sukcesis, anstataŭ skribi "ne eblas konekti". La MS-SSTP-specifikaĵo dokumentas la peton kaj la PPP-interŝanĝon, kiuj sekvas la TLS-manpremon, kaj estas la referenco por kial retumila testo ne povas anstataŭi iun el ili.
Unue identeco, poste PPP
TLS-identeco kaj PPP-aŭtentikigo estas sinsekvaj, ne alternativaj, kaj konfuzi ilin sendas homojn al malĝusta servila agordo. La kliento unue validigas la servilan atestilon kaj ĝian celitan uzon, poste PPP intertraktas sian propran staton kaj aŭtentikigas la uzanton per defio-responda metodo aŭ EAP. Atestila problemo produktas alian eraron ol rifuzita pasvorto, kaj nek unu eraro priskribas la etapon, kiun la alia kovras.
Anstataŭigi la gastigantan nomon per adreso aŭ klaki preter la atestila averto forigas la kontrolon, kiu identigus la malsukcesan etapon, anstataŭ ripari ĝin. Konservu la averton kaj legu ĝin. Ne restarigu PPP-pasvorton, kiam la HTTP-interŝanĝo neniam atingis la SSTP-konduton, ĉar la akreditaĵoj neniam estis petitaj.