SSTP on PPP üle HTTPSi, mitte veebileht pordil 443

SSTP kannab PPP-d HTTPS-ühenduse sees, seepärast näeb see kõige jaoks vahepeal välja nagu veebiliiklus. TLS ja HTTP loovad välimise kanali, seejärel valmistavad SSTP juhtteated tunnelit ette ja PPP annab sessiooni käitumise. Brauser, mis laeb lehekülge samal aadressil on läbinud vaid osa esimesest etapist. Selle VPN-testiks pidamine on viis, kuidas töötav puhverserver saab süü protokolli lahknevuses.

Käi neli etappi järjekorras läbi ja tõrge, mida näed, maandub ühes neist.

Etapp 1: TCP ja TLS

Klient avab TCP-ühenduse pordile 443 ja teeb TLS-kätluse. Sertifikaadiahel peab vastama hostinimele, millega klient seadistati. Nime lahknevus tekitab siin tõrke enne, kui ükski SSTP-teade vahetatakse, ja SSTP spetsifikatsioon eeldab, et see välimine HTTPS-kanal on juba olemas. Miski hilisemates etappides ei korva usaldustõrget siin.

Tavaline veebiserver võib selle etapi täiuslikult läbida ja järgmises siiski ebaõnnestuda. TLS-i edu on tõend sertifikaadi kohta, mitte selle taga oleva protokolli kohta.

Etapp 2: HTTPS-päring

SSTP teeb oma päringu kindla meetodiga, SSTP_DUPLEX_POST, ja hoiab vahetuse avatuna, selle asemel et dokumenti tagastada. Tavapäraste leheküljepäringute jaoks seadistatud server või puhverserver võib ühenduse vastu võtta ja seejärel meetodi tagasi lükata. See tagasilükkamine on ühilduvusprobleem, mida inimesed tavaliselt kirjeldavad kui blokeeritud porti 443.

Loe serveri logist vastusekoodi ja meetodit. Tagasilükkamine selles etapis on teine probleem kui TCP aegumine, ja mõlemad viivad erinevate parandusteni.

Etapp 3: juhtteated

Kui päring on vastu võetud, vahetab SSTP juhtteateid, mis läbiräägivad ja valmistavad tunneli ette. Need on protokolliteated HTTPS-i kehas, mitte HTTP-päringud, seega puhverserver, mis kehi kontrollib ja ümber kirjutab, võib need katki teha, jättes leheküljepäringud puutumata.

Siin teenib sügavkontrolli vahesein oma maine. Kui lehed laadivad ja VPN ei tööta, kontrolli pigem, kas keha muudetakse, mitte kas port on avatud.

Etapp 4: PPP võtab üle

Seejärel annab PPP sessiooni käitumise: lingi läbirääkimine, autentimine ja sellele järgnev võrgukihi seadistus. PPP autentimine on eraldi TLS-kontrollist, mille klient on juba läbinud. Serveri sertifikaat, mille klient vastu võtab, ei ütle midagi selle kohta, kas kasutaja mandaadid on kehtivad või kas konto on volitatud.

Vastuvõetud sertifikaat ja tagasilükatud sisselogimine ei ole vastuolus. Need on järjestikused etapid sõltumatute tulemustega.

Autentimisel on mitu rolli

Klient valideerib TLS-serveri identiteedi oma usaldushoidla ja seadistatud nime vastu. Seejärel autendib PPP kasutaja või masina, sõltuvalt juurutusest. Server võib lisada oma põhimõtte, kes tohib ühenduda ja mida tohib saavutada. Hoia hostinimi sertifikaadi identiteediga kooskõlas, sest toores aadress muudab töötava seadistuse nimekontrolli tõrkeks.

Kirjuta üles, milline etapp tõrkest teatas. Sertifikaat, meetod, juhtteade, PPP autentimine, seejärel marsruudid: viis kohta, viis parandust.

Mida brauseriproov näidata saab ja mida mitte

Lehekülje laadimine aadressil tõestab DNS-i lahendust, TCP kättesaadavust ja seda, et miski kuulab ja räägib HTTP-d. See ei tõesta, et meetod võetakse vastu, juhtvahetus püsib või PPP autentimine on seadistatud. Kasuta klienti, mis rakendab SSTP-d, selle asemel et teist profiili porti muutes ümber teha.

Kui sessioon on püsti, otsustavad marsruudid, DNS ja serveripoolne edastamine endiselt, mida kasutaja saavutada saab. Tunnel on tee, mitte volitus.