SSTP – tai PPP per HTTPS, o ne tinklalapis 443 prievade

SSTP perduoda PPP HTTPS ryšio viduje, todėl bet kam viduryje jis atrodo kaip žiniatinklio srautas. TLS ir HTTP sukuria išorinį kanalą, tada SSTP valdymo pranešimai paruošia tunelį, o PPP suteikia sesijos elgseną. Naršyklė, kuri įkelia puslapį tuo pačiu adresu baigė tik dalį pirmojo etapo. Laikyti tai VPN testu – tai būdas, kuriuo veikiantis tarpinis serveris apkaltinamas protokolo neatitikimu.

Pereikite keturis etapus iš eilės, ir matoma klaida atsidurs viename jų.

1 etapas: TCP ir TLS

Klientas atidaro TCP ryšį į 443 prievadą ir atlieka TLS rankos paspaudimą. Sertifikatų grandinė turi atitikti pagrindinio kompiuterio vardą, su kuriuo klientas buvo sukonfigūruotas. Vardo neatitikimas čia sukelia klaidą prieš apsikeičiant bet kokiu SSTP pranešimu, o SSTP specifikacija numato, kad šis išorinis HTTPS kanalas jau egzistuoja. Niekas vėlesniuose etapuose negali kompensuoti pasitikėjimo klaidos čia.

Paprastas žiniatinklio serveris gali puikiai baigti šį etapą ir vis tiek nepavykti kitame. TLS sėkmė yra įrodymas apie sertifikatą, o ne apie protokolą už jo.

2 etapas: HTTPS užklausa

SSTP siunčia savo užklausą specialiu metodu SSTP_DUPLEX_POST ir palieka apsikeitimą atvirą, o ne grąžina dokumentą. Serveris ar tarpinis serveris, sukonfigūruotas įprastoms puslapio užklausoms, gali priimti ryšį ir paskui atmesti metodą. Tas atmetimas yra suderinamumo problema, kurią žmonės paprastai apibūdina kaip užblokuotą 443 prievadą.

Perskaitykite atsakymo kodą ir metodą serverio žurnale. Atmetimas šiame etape yra kitokia problema nei TCP laukimo laikas, ir abi veda prie skirtingų pataisų.

3 etapas: valdymo pranešimai

Kai užklausa priimta, SSTP apsikeičia valdymo pranešimais, kurie derasi ir paruošia tunelį. Tai protokolo pranešimai HTTPS turinio viduje, o ne HTTP užklausos, todėl tarpinis serveris, kuris tikrina ir perrašo turinį, gali juos sugadinti, palikdamas puslapio užklausas nepaliestas.

Būtent čia giluminės inspekcijos tarpinė dėžė pelno savo reputaciją. Jei puslapiai kraunasi, o VPN nepavyksta, patikrinkite, ar turinys keičiamas, o ne ar prievadas atidarytas.

4 etapas: PPP perima

Tada PPP suteikia sesijos elgseną: jungties derėjimąsi, autentifikavimą ir tolesnę tinklo sluoksnio konfigūraciją. PPP autentifikavimas atskirtas nuo TLS patikros, kurią klientas jau praėjo. Serverio sertifikatas, kurį klientas priima, nieko nesako apie tai, ar vartotojo prisijungimo duomenys galioja, ar paskyra yra įgaliota.

Priimtas sertifikatas ir atmestas prisijungimas neprieštarauja vienas kitam. Tai nuoseklūs etapai su nepriklausomais rezultatais.

Autentifikavimas turi keletą vaidmenų

Klientas patvirtina TLS serverio tapatybę pagal savo pasitikėjimo saugyklą ir sukonfigūruotą vardą. Tada PPP autentifikuoja vartotoją arba mašiną, priklausomai nuo diegimo. Serveris gali pridėti savo politiką, kas gali jungtis ir ko gali pasiekti. Laikykite pagrindinio kompiuterio vardą suderintą su sertifikato tapatybe, nes pakeitus jį neapdorotu adresu, veikianti sąranka tampa vardo patikros klaida.

Užsirašykite, kuris etapas pranešė apie klaidą. Sertifikatas, metodas, valdymo pranešimas, PPP autentifikavimas, tada maršrutai: penkios vietos, penkios pataisos.

Ką naršyklės testas gali ir ko negali parodyti

Puslapio įkėlimas adresu įrodo DNS sprendimą, TCP pasiekiamumą ir kad kažkas klausosi ir kalba HTTP. Tai neįrodo, kad metodas priimtas, valdymo apsikeitimas išgyvena ar PPP autentifikavimas sukonfigūruotas. Naudokite klientą, kuris įgyvendina SSTP, o ne konvertuokite kitą profilį keisdami prievadą.

Kai sesija sukurta, maršrutai, DNS ir perdavimas serverio pusėje vis tiek lemia, ką vartotojas gali pasiekti. Tunelis yra kelias, o ne leidimas.