SSTP je PPP preko HTTPS-a, a ne web stranica na portu 443

SSTP prenosi PPP unutar HTTPS veze, zato za sve u sredini izgleda kao web saobraćaj. TLS i HTTP uspostavljaju spoljni kanal, zatim SSTP kontrolne poruke pripremaju tunel, a PPP daje ponašanje sesije. Pregledač koji učita stranicu na istoj adresi završio je samo deo prve faze. Smatrati to VPN testom način je da ispravan proxy bude kriv za nesklad protokola.

Prođite kroz četiri faze redom, i kvar koji vidite pašće u jednu od njih.

Faza 1: TCP i TLS

Klijent otvara TCP vezu prema portu 443 i obavlja TLS rukovanje. Lanac sertifikata mora da odgovara imenu hosta sa kojim je klijent konfigurisan. Nesklad imena ovde stvara kvar pre nego što se razmeni ijedna SSTP poruka, a specifikacija SSTP-a pretpostavlja da taj spoljni HTTPS kanal već postoji. Ništa u kasnijim fazama ne može da nadoknadi kvar poverenja ovde.

Običan web server može savršeno da završi ovu fazu i ipak padne na sledećoj. Uspeh TLS-a dokaz je o sertifikatu, a ne o protokolu iza njega.

Faza 2: HTTPS zahtev

SSTP šalje svoj zahtev posebnom metodom, SSTP_DUPLEX_POST, i drži razmenu otvorenom umesto da vrati dokument. Server ili proxy konfigurisan za obične zahteve stranica može da prihvati vezu i zatim odbije metodu. To odbijanje je problem kompatibilnosti koji ljudi obično opisuju kao blokiran port 443.

Pročitajte kod odgovora i metodu u dnevniku servera. Odbijanje u ovoj fazi je drugi problem od TCP isteka, i oba vode ka različitim popravkama.

Faza 3: kontrolne poruke

Kada je zahtev prihvaćen, SSTP razmenjuje kontrolne poruke koje pregovaraju i pripremaju tunel. To su protokolarne poruke unutar tela HTTPS-a, a ne HTTP zahtevi, pa proxy koji pregleda i prepisuje tela može da ih slomi dok zahtevi stranica ostaju netaknuti.

Tu uređaj za dubinski pregled stiče svoju reputaciju. Ako se stranice učitavaju, a VPN pada, proverite da li se telo menja, a ne da li je port otvoren.

Faza 4: PPP preuzima

PPP zatim daje ponašanje sesije: pregovaranje veze, autentifikaciju i konfiguraciju mrežnog sloja koja sledi. PPP autentifikacija je odvojena od TLS provere koju je klijent već prošao. Sertifikat servera koji klijent prihvati ne govori ništa o tome da li su korisnikovi akreditivi važeći ili je nalog ovlašćen.

Prihvaćen sertifikat i odbijena prijava nisu protivrečni. To su uzastopne faze sa nezavisnim ishodima.

Autentifikacija ima nekoliko uloga

Klijent proverava identitet TLS servera prema svom skladištu poverenja i konfigurisanom imenu. PPP zatim autentifikuje korisnika ili mašinu, zavisno od postavljanja. Server može da doda sopstvenu politiku o tome ko sme da se poveže i do čega sme da dođe. Držite ime hosta usklađeno sa identitetom sertifikata, jer zamena sirovom adresom pretvara ispravno postavljanje u kvar provere imena.

Zapišite koja je faza prijavila kvar. Sertifikat, metoda, kontrolna poruka, PPP autentifikacija, zatim rute: pet mesta, pet popravki.

Šta test u pregledaču može i ne može da pokaže

Učitavanje stranice na adresi dokazuje DNS razrešavanje, TCP dostupnost i da nešto sluša i govori HTTP. Ne dokazuje da je metoda prihvaćena, da kontrolna razmena preživljava ili da je PPP autentifikacija konfigurisana. Koristite klijent koji implementira SSTP umesto pretvaranja drugog profila promenom porta.

Kada je sesija podignuta, rute, DNS i prosleđivanje na strani servera i dalje odlučuju do čega korisnik može da dođe. Tunel je put, a ne ovlašćenje.