SSTP je PPP prek HTTPS, ne spletna stran na vratih 443

SSTP prenaša PPP znotraj povezave HTTPS, zato je za vse vmes videti kot spletni promet. TLS in HTTP vzpostavita zunanji kanal, nato nadzorna sporočila SSTP pripravijo tunel, PPP pa zagotovi vedenje seje. Brskalnik, ki naloži stran na istem naslovu je dokončal le del prve stopnje. Obravnavati to kot preizkus VPN je način, kako delujočemu posredniku pripišemo krivdo za neujemanje protokola.

Pojdite skozi štiri stopnje po vrsti, in napaka, ki jo vidite, bo padla v eno od njih.

Stopnja 1: TCP in TLS

Odjemalec odpre povezavo TCP na vrata 443 in izvede rokovanje TLS. Veriga potrdil se mora ujemati z imenom gostitelja, s katerim je bil odjemalec nastavljen. Neujemanje imena tu povzroči napako, preden se izmenja katero koli sporočilo SSTP, in specifikacija SSTP predpostavlja, da ta zunanji kanal HTTPS že obstaja. Nič v poznejših stopnjah ne more nadomestiti napake zaupanja tu.

Običajen spletni strežnik lahko to stopnjo opravi brezhibno in vseeno spodleti v naslednji. Uspeh TLS je dokaz o potrdilu, ne o protokolu za njim.

Stopnja 2: zahteva HTTPS

SSTP pošlje svojo zahtevo s posebno metodo SSTP_DUPLEX_POST in izmenjavo drži odprto, namesto da bi vrnil dokument. Strežnik ali posrednik, nastavljen za običajne zahteve strani, lahko povezavo sprejme in nato metodo zavrne. Ta zavrnitev je težava združljivosti, ki jo ljudje običajno opišejo kot blokirana vrata 443.

Preberite kodo odgovora in metodo v dnevniku strežnika. Zavrnitev v tej stopnji je drugačna težava kot časovna omejitev TCP, in obe vodita do različnih popravkov.

Stopnja 3: nadzorna sporočila

Ko je zahteva sprejeta, SSTP izmenja nadzorna sporočila, ki se pogajajo in pripravijo tunel. To so protokolna sporočila znotraj telesa HTTPS, ne zahteve HTTP, zato lahko posrednik, ki pregleduje in prepisuje telesa, ta sporočila pokvari, medtem ko zahteve strani ostanejo nedotaknjene.

Tu si naprava za globinski pregled prisluži sloves. Če se strani nalagajo, VPN pa spodleti, preverite, ali se telo spreminja, in ne, ali so vrata odprta.

Stopnja 4: PPP prevzame

PPP nato zagotovi vedenje seje: pogajanje o povezavi, overjanje in nastavitev omrežnega sloja, ki sledi. Overjanje PPP je ločeno od preverjanja TLS, ki ga je odjemalec že opravil. Potrdilo strežnika, ki ga odjemalec sprejme, ne pove ničesar o tem, ali so uporabnikove poverilnice veljavne ali je račun pooblaščen.

Sprejeto potrdilo in zavrnjena prijava si nista nasprotujoča. To so zaporedne stopnje z neodvisnimi izidi.

Overjanje ima več vlog

Odjemalec preveri identiteto strežnika TLS glede na svoje shrambo zaupanja in nastavljeno ime. Nato PPP overi uporabnika ali stroj, odvisno od uvedbe. Strežnik lahko doda svojo politiko o tem, kdo se sme povezati in kaj sme doseči. Ime gostitelja naj bo skladno z identiteto potrdila, ker zamenjava s surovim naslovom spremeni delujočo nastavitev v napako preverjanja imena.

Zapišite, katera stopnja je poročala o napaki. Potrdilo, metoda, nadzorno sporočilo, overjanje PPP, nato poti: pet mest, pet popravkov.

Kaj lahko preizkus v brskalniku pokaže in česa ne

Nalaganje strani na naslovu dokaže razreševanje DNS, dosegljivost TCP in da nekaj posluša ter govori HTTP. Ne dokaže, da je metoda sprejeta, da izmenjava nadzora preživi ali da je overjanje PPP nastavljeno. Uporabite odjemalca, ki izvaja SSTP, namesto da pretvorite drug profil s spremembo vrat.

Ko je seja vzpostavljena, poti, DNS in posredovanje na strani strežnika še vedno odločajo, kaj lahko uporabnik doseže. Tunel je pot, ne dovoljenje.