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

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

Prođite kroz četiri faze po redu, i kvar koji vidite pasti će u jednu od njih.

Faza 1: TCP i TLS

Klijent otvara TCP vezu prema portu 443 i obavlja TLS rukovanje. Lanac certifikata mora odgovarati imenu hosta s kojim je klijent konfigurisan. Nesklad imena ovdje proizvodi kvar prije nego što se razmijeni ijedna SSTP poruka, a specifikacija SSTP-a pretpostavlja da taj vanjski HTTPS kanal već postoji. Ništa u kasnijim fazama ne može nadoknaditi kvar povjerenja ovdje.

Običan web server može savršeno završiti ovu fazu i ipak pasti na sljedećoj. Uspjeh TLS-a dokaz je o certifikatu, a ne o protokolu iza njega.

Faza 2: HTTPS zahtjev

SSTP šalje svoj zahtjev posebnom metodom, SSTP_DUPLEX_POST, i drži razmjenu otvorenom umjesto da vrati dokument. Server ili proxy konfigurisan za obične zahtjeve stranica može prihvatiti vezu i zatim odbiti 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 drugi je problem od TCP isteka, i oba vode do različitih popravki.

Faza 3: kontrolne poruke

Kad je zahtjev prihvaćen, SSTP razmjenjuje kontrolne poruke koje pregovaraju i pripremaju tunel. To su protokolarne poruke unutar tijela HTTPS-a, a ne HTTP zahtjevi, pa proxy koji pregledava i prepisuje tijela može ih slomiti dok zahtjevi stranica ostaju netaknuti.

Tu uređaj za dubinski pregled stiče svoju reputaciju. Ako se stranice učitavaju a VPN pada, provjerite mijenja li se tijelo, a ne je li port otvoren.

Faza 4: PPP preuzima

PPP zatim daje ponašanje sesije: pregovaranje veze, autentifikaciju i konfiguraciju mrežnog sloja koja slijedi. PPP autentifikacija je odvojena od TLS provjere koju je klijent već prošao. Certifikat servera koji klijent prihvati ne govori ništa o tome jesu li korisnikovi akreditivi valjani ili je račun ovlašten.

Prihvaćen certifikat i odbijena prijava nisu proturječni. To su uzastopne faze s neovisnim ishodima.

Autentifikacija ima nekoliko uloga

Klijent provjerava identitet TLS servera prema svojoj trgovini povjerenja i konfigurisanom imenu. PPP zatim autentificira korisnika ili mašinu, zavisno od postavljanja. Server može dodati vlastitu politiku o tome ko se smije povezati i do čega smije doći. Držite ime hosta usklađeno s identitetom certifikata, jer zamjena sirovom adresom pretvara ispravno postavljanje u kvar provjere imena.

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

Šta test u pregledniku može i ne može pokazati

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

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