SSTP odpove tam, kjer HTTPS v brskalniku uspe: zakaj
SSTP teče znotraj TLS na vratih 443, vendar ni spletna zahteva. Preizkusite TCP, identiteto TLS, izmenjavo SSTP in preverjanje PPP kot ločene stopnje.
Brskalnik odpre ime gostitelja VPN prek HTTPS brez pritožbe, odjemalec SSTP pa se še vedno noče povezati. V tem paru ni nič protislovnega. SSTP uporablja TLS kot zunanji transport in nato v isti povezavi izvaja lastno zahtevo in tovor PPP, zato uspešno nalaganje strani dokaže le eno ozko stvar: gostitelj odgovori na GET na vratih 443. Odjemalec postavlja drugo vprašanje, strežnik pa lahko nanj odgovori slabo.
Stran se naloži, predor pa ne
Ljudje posežejo po preizkusu v brskalniku, ker je hiter, nato pa rezultat vzamejo kot dokaz, da je strežnik dosegljiv in konfiguriran. To je dokaz o GET na pot, ki jo je odprla naslovna vrstica, nič več. Pogovor VPN se začne po istem rokovanju TLS, vendar pošilja metodo in pot, ki ju spletna stran nikoli ne uporabi. Zato odgovor 200 za brskalnik ne pove ničesar o tem, ali končna točka SSTP obstaja.
Ločite obe opažanji in iskanje se skrajša. Transport in veriga potrdil delujeta, nekaj v izmenjavi protokola nad njima pa ne. To je druga preiskava kot pokvarjena vrata ali poteklo potrdilo in zahteva drugačne dokaze.
Kaj odjemalec SSTP dejansko pošlje
Odjemalec pošlje zahtevo HTTP z metodo SSTP_DUPLEX_POST na pot /sra_{GUID}/ in nato telo povezave drži odprto kot dvosmerni tok, ki nosi okvire PPP. Skladnemu strežniku odgovori HTTP/1.1 200 in se ne obnaša več kot spletni strežnik. Vse drugo je podpis: 405 ali 404 pomeni, da končne točke ni, 301 ali 302 pomeni, da nekaj preusmerja zahtevo, takojšen FIN pa pomeni, da je proxy ali strežnik zaprl tok.
Zato mora biti cilj strežnik SSTP in ne spletni strežnik s privitim potrdilom TLS. Metoda, pot in dolgotrajno telo so zahteve protokola, zato obratni proxy tega ne more dodati samo s konfiguracijo. Proxy, ki brezhibno posreduje običajen HTTPS, lahko vseeno zavrne metodo, ki je ne pozna.
Kje proxy ali spletni strežnik pretrga tok
Posrednik pregleda vrstico zahteve HTTP, preden karkoli posreduje, in metoda po meri z nenavadno potjo lahko pade na njegovih pravilih. Nekatere naprave strežejo običajno stran, medtem ko predor zavračajo ali prekinjajo, zato odjemalec poroča o povezavi, ki se začne in nato umre, namesto o čisti zavrnitvi. Druge zahtevo sprejmejo in nato uporabijo časovno omejitev telesa ali mirovanja, ki je ohranitvena sporočila PPP ne preživijo. Oboje je z odjemalčeve strani videti enako, zato je stopnja, ki je padla, pomembnejša od besedila napake.
Deljenje vrat 443 med spletnim mestom in SSTP je odločitev o usmerjanju, ne obljuba, da bo vsak skok oba pogovora obravnaval enako. Če je na poti razporejevalnik obremenitve, požarni zid ali zaključevalnik TLS, ga dodajte na seznam osumljencev, preden se dotaknete konfiguracije VPN.
Preizkusite stopnje ločeno
Izvedite preverjanja po vrsti in se ustavite pri prvi napaki, ker vsaka stopnja izključi drug sloj. Sonda TLS spodaj loči identiteto potrdila od vsega, kar počne SSTP. Zamenjajte ime gostitelja s svojo končno točko in preberite subject in verigo, ki ju izpiše.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comNato preslikajte preostale dokaze na stopnje, namesto da bi ugibali iz napake odjemalca. Tabela spodaj je kontrolni seznam za citiranje v zahtevi, s podpisom, ki loči eno napako od naslednje.
| 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 |
V zahtevo zapišite zadnjo uspešno stopnjo, namesto da bi napisali "ni mogoče povezati". Specifikacija MS-SSTP dokumentira zahtevo in izmenjavo PPP, ki sledita rokovanju TLS, in je referenca za to, zakaj preizkus v brskalniku ne more nadomestiti nobenega od njiju.
Najprej identiteta, nato PPP
Identiteta TLS in preverjanje PPP sta zaporedna, ne alternativna, in njuno mešanje vodi ljudi k napačni nastavitvi strežnika. Odjemalec najprej preveri potrdilo strežnika in njegov predvideni namen, nato PPP pogaja o svojem stanju in preveri uporabnika z metodo izziv-odgovor ali EAP. Težava s potrdilom da drugačno napako kot zavrnjeno geslo in nobena napaka ne opisuje stopnje, ki jo pokriva druga.
Zamenjava imena gostitelja z naslovom ali klik mimo opozorila o potrdilu odstrani preverjanje, ki bi prepoznalo stopnjo, ki odpoveduje, namesto da bi jo popravilo. Opozorilo obdržite in ga preberite. Prav tako ne ponastavite gesla PPP, ko izmenjava HTTP nikoli ni dosegla vedenja SSTP, ker poverilnice niso bile nikoli zahtevane.