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 promet. 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 dovrš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 redom, i kvar koji vidite past ć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 konfiguriran. Nesklad imena ovdje stvara 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 poslužitelj može savršeno dovrš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. Poslužitelj ili proxy konfiguriran za obične zahtjeve stranica može prihvatiti vezu i zatim odbiti metodu. To odbijanje problem je kompatibilnosti koji ljudi obično opisuju kao blokiran port 443.

Pročitajte kod odgovora i metodu u zapisniku poslužitelja. Odbijanje u ovoj fazi drugi je problem od TCP isteka, i oba vode do različitih popravaka.

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 stječ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 odvojena je od TLS provjere koju je klijent već prošao. Certifikat poslužitelja koji klijent prihvati ne govori ništa o tome jesu li korisnikovi vjerodajni 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 poslužitelja prema svojem spremištu povjerenja i konfiguriranom imenu. PPP zatim autentificira korisnika ili stroj, ovisno o postavljanju. Poslužitelj može dodati vlastitu politiku o tome kome 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 popravaka.

Što 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 konfigurirana. Koristite klijent koji implementira SSTP umjesto pretvaranja drugog profila promjenom porta.

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