SSTP estas PPP super HTTPS, ne retpaĝo sur pordo 443

SSTP portas PPP ene de HTTPS-konekto, tial ĝi aspektas kiel reta trafiko por ĉio en la mezo. TLS kaj HTTP starigas la eksteran kanalon, poste SSTP-regaj mesaĝoj preparas la tunelon, kaj PPP liveras la seancon konduton. Retumilo, kiu ŝargas paĝon ĉe la sama adreso finis nur parton de la unua etapo. Trakti tion kiel VPN-teston estas la maniero kulpigi funkciantan prokurilon pri protokola malkongruo.

Trairu la kvar etapojn laŭorde, kaj la fiasko, kiun vi vidas, falos en unu el ili.

Etapo 1: TCP kaj TLS

La kliento malfermas TCP-konekton al pordo 443 kaj faras TLS-manpremon. La atestila ĉeno devas kongrui kun la gastigantnomo, per kiu la kliento estis agordita. Nommalkongruo ĉi tie kaŭzas fiaskon antaŭ ol iu ajn SSTP-mesaĝo estas interŝanĝita, kaj la SSTP-specifiko supozas, ke ĉi tiu ekstera HTTPS-kanalo jam ekzistas. Nenio en la pli postaj etapoj povas kompensi fidan fiaskon ĉi tie.

Ordinara retservilo povas perfekte fini ĉi tiun etapon kaj tamen fiaski en la sekva. TLS-sukceso estas pruvo pri la atestilo, ne pri la protokolo malantaŭ ĝi.

Etapo 2: la HTTPS-peto

SSTP faras sian peton per specifa metodo, SSTP_DUPLEX_POST, kaj tenas la interŝanĝon malferma anstataŭ redoni dokumenton. Servilo aŭ prokurilo agordita por ordinaraj paĝpetoj povas akcepti la konekton kaj poste malakcepti la metodon. Tiu malakcepto estas la kongrua problemo, kiun homoj kutime priskribas kiel blokitan pordon 443.

Legu la respondan kodon kaj la metodon en la servila protokolo. Malakcepto ĉe ĉi tiu etapo estas malsama problemo ol TCP-tempo, kaj ambaŭ kondukas al malsamaj riparoj.

Etapo 3: regaj mesaĝoj

Post akcepto de la peto, SSTP interŝanĝas regajn mesaĝojn, kiuj intertraktas kaj preparas la tunelon. Tiuj estas protokolaj mesaĝoj ene de la HTTPS-korpo, ne HTTP-petoj, do prokurilo, kiu inspektas kaj reverkas korpojn, povas rompi ilin dum paĝpetoj restas netuŝitaj.

Ĉi tie profunda-inspekta mezkesto gajnas sian reputacion. Se paĝoj ŝargiĝas kaj la VPN fiaskas, kontrolu ĉu la korpo estas modifata anstataŭ ĉu la pordo estas malferma.

Etapo 4: PPP ekregas

Poste PPP liveras sian seancon konduton: liga intertraktado, aŭtentigo kaj la sekva agordo de la reta tavolo. PPP-aŭtentigo estas aparta de la TLS-kontrolo, kiun la kliento jam trapasis. Servila atestilo, kiun la kliento akceptas, diras nenion pri tio, ĉu la akreditaĵoj de la uzanto validas aŭ ĉu la konto estas rajtigita.

Akceptita atestilo kaj malakceptita ensaluto ne kontraŭdiras. Ili estas sinsekvaj etapoj kun sendependaj rezultoj.

Aŭtentigo havas plurajn rolojn

La kliento validigas la identecon de la TLS-servilo kontraŭ sia fida konservejo kaj la agordita nomo. Poste PPP aŭtentigas la uzanton aŭ la maŝinon, laŭ la deplojo. La servilo povas aldoni sian propran politikon pri tio, kiu rajtas konektiĝi kaj kion ili rajtas atingi. Tenu la gastigantnomon kongrua kun la atestila identeco, ĉar anstataŭigo per kruda adreso transformas funkciantan agordon en nomkontrolan fiaskon.

Notu, kiu etapo raportis la fiaskon. Atestilo, metodo, rega mesaĝo, PPP-aŭtentigo, poste itineroj: kvin lokoj, kvin riparoj.

Kion retumila testo povas kaj ne povas montri

Ŝargado de paĝo ĉe la adreso pruvas DNS-dissolvon, TCP-atingeblecon kaj ke io aŭskultas, kiu parolas HTTP. Ĝi ne pruvas, ke la metodo estas akceptita, ke la rega interŝanĝo postvivas aŭ ke PPP-aŭtentigo estas agordita. Uzu klienton, kiu efektivigas SSTP, anstataŭ konverti alian profilon per ŝanĝo de la pordo.

Post kiam la seanco staras, itineroj, DNS kaj servilflanka plusendado ankoraŭ decidas, kion la uzanto povas atingi. La tunelo estas vojo, ne rajtigo.