SSTP PPP da HTTPS gainean, ez 443 portuko web orria

SSTP PPP eramaten du HTTPS konexio baten barruan, horregatik web trafiko itxura du erdian dagoen edozertarako. TLS eta HTTP kanpoko kanala ezartzen dute, gero SSTP kontrol mezuak tunela prestatzen dute eta PPPk saioaren jokaera ematen du. Helbide berean orrialde bat kargatzen duen nabigatzaileak lehenengo etaparen zati bat baino ez du osatu. Hori VPN proba gisa hartzea da proxy lan egiten ari den bat protokolo desadostasun baten errudun egiteko modua.

Ibili lau etapak ordenan, eta ikusten duzun hutsegitea horietako batean geratuko da.

1. etapa: TCP eta TLS

Bezeroak TCP konexio bat irekitzen du 443 portura eta TLS esku-ematea egiten du. Ziurtagirien kateak bezeroa konfiguratu zen ostalari-izenarekin bat etorri behar du. Izen-desadostasun batek hemen hutsegitea eragiten du SSTP mezu bat bera ere trukatu aurretik, eta SSTP zehaztapenak kanpoko HTTPS kanal hori jada badagoela suposatzen du. Geroagoko etapetan ezerk ezin du hemen konfiantza-hutsegitea konpentsatu.

Web zerbitzari arrunt batek etapa hau primeran osa dezake eta hurrengoan huts egin. TLS arrakasta ziurtagiriari buruzko ebidentzia da, ez haren atzeko protokoloari buruzkoa.

2. etapa: HTTPS eskaera

SSTPk metodo zehatz batekin egiten du eskaera, SSTP_DUPLEX_POST, eta trukea irekita edukitzen du dokumentu bat itzuli beharrean. Orrialde eskaera arruntetarako konfiguratutako zerbitzari edo proxy batek konexioa onar dezake eta gero metodoa ukatu. Ukapen hori da jendeak normalean 443 portua blokeatuta dagoela esaten duenean deskribatzen duen bateragarritasun arazoa.

Irakurri erantzun-kodea eta metodoa zerbitzariaren erregistroan. Etapa honetako ukipena TCP denbora-muga batetik desberdina den arazoa da, eta biek konponketa desberdinetara eramaten dute.

3. etapa: kontrol mezuak

Eskaera onartu ondoren, SSTPk tunela negoziatzen eta prestatzen duten kontrol mezuak trukatzen ditu. Hauek HTTPS gorputzaren barruko protokolo mezuak dira, ez HTTP eskaerak, beraz gorputzak ikuskatu eta berridazten dituen proxy batek hauts ditzake, orrialde eskaerei ukitu gabe utzita.

Hemen irabazten du ospe ona ikuskapen sakoneko gailu batek. Orrialdeak kargatzen badira eta VPNak huts egiten badu, egiaztatu gorputza aldatzen ari den ala portua irekita dagoen.

4. etapa: PPPk hartzen du

Gero PPPk saioaren jokaera ematen du: estekak negoziatzea, autentikazioa eta ondorengo sare-geruzaren konfigurazioa. PPP autentikazioa bezeroak jada gainditu duen TLS egiaztapenetik bereizia da. Bezeroak onartzen duen zerbitzari ziurtagiri batek ez du ezer esaten erabiltzailearen kredentzialak baliozkoak diren edo kontua baimenduta dagoen.

Onartutako ziurtagiri bat eta ukaturiko saio-hasiera ez dira kontraesankorrak. Ondoz ondoko etapak dira, emaitza independenteekin.

Autentikazioak hainbat rol ditu

Bezeroak TLS zerbitzariaren identitatea baliozkotzen du bere konfiantza-biltegien eta konfiguratutako izenarekiko. Gero PPPk erabiltzailea edo makina autentikatzen du, hedapenaren arabera. Zerbitzariak bere politika gehi dezake nor konekta daitekeen eta zertara irits daitekeen buruz. Eutsi ostalari-izena ziurtagiriaren identitatearekin bat, helbide gordin bat jartzeak funtzionatzen duen konfigurazioa izen-egiaztapeneko hutsegite bihurtzen baitu.

Idatzi zein etapatik jakinarazi zuen hutsegitea. Ziurtagiria, metodoa, kontrol mezua, PPP autentikazioa, gero ibilbideak: bost leku, bost konponketa.

Zer erakuts dezakeen nabigatzaileko proba batek eta zer ez

Helbidean orrialde bat kargatzeak DNS ebazpena, TCP irismena eta HTTP hitz egiten duen zerbait entzuten ari dela frogatzen du. Ez du frogatzen metodoa onartzen denik, kontrol trukea bizirik ateratzen denik edo PPP autentikazioa konfiguratuta dagoenik. Erabili SSTP inplementatzen duen bezero bat, beste profil bat portua aldatuz bihurtu beharrean.

Saioa martxan dagoenean, ibilbideek, DNSek eta zerbitzari aldeko birbidaltzeak erabakitzen dute oraindik erabiltzaileak zertara irits daitekeen. Tunela bidea da, ez baimena.