SSTP je PPP přes HTTPS, ne webová stránka na portu 443

SSTP přenáší PPP uvnitř HTTPS spojení, a proto to pro cokoli uprostřed vypadá jako webový provoz. TLS a HTTP vytvoří vnější kanál, pak řídicí zprávy SSTP připraví tunel a PPP dodá chování relace. Prohlížeč, který načte stránku na stejné adrese dokončil jen část první fáze. Považovat to za test VPN je způsob, jak dát funkčnímu proxy vinu za nesoulad protokolu.

Projděte čtyři fáze popořadě a porucha, kterou vidíte, spadne do jedné z nich.

Fáze 1: TCP a TLS

Klient otevře TCP spojení na port 443 a provede TLS handshake. Řetěz certifikátů musí odpovídat názvu hostitele, se kterým byl klient nakonfigurován. Neshoda názvu zde vyvolá poruchu dřív, než se vymění jakákoli zpráva SSTP, a specifikace SSTP předpokládá, že tento vnější HTTPS kanál už existuje. Nic v pozdějších fázích nedokáže poruchu důvěry zde vykompenzovat.

Běžný webový server tuto fázi zvládne bezchybně a přesto selže v následující. Úspěch TLS je důkaz o certifikátu, ne o protokolu za ním.

Fáze 2: požadavek HTTPS

SSTP posílá svůj požadavek zvláštní metodou, SSTP_DUPLEX_POST, a drží výměnu otevřenou, místo aby vrátil dokument. Server nebo proxy nakonfigurované pro běžné požadavky na stránky může spojení přijmout a pak metodu odmítnout. Toto odmítnutí je problém kompatibility, který lidé obvykle popisují jako zablokovaný port 443.

Přečtěte si kód odpovědi a metodu v logu serveru. Odmítnutí v této fázi je jiný problém než časový limit TCP a oba vedou k jiným opravám.

Fáze 3: řídicí zprávy

Jakmile je požadavek přijat, SSTP si vyměňuje řídicí zprávy, které vyjednají a připraví tunel. To jsou protokolové zprávy uvnitř těla HTTPS, nikoli požadavky HTTP, takže proxy, které těla kontroluje a přepisuje, je může rozbít, zatímco požadavky na stránky zůstanou nedotčené.

Tady si zařízení pro hloubkovou inspekci vydělává pověst. Když se stránky načítají a VPN selhává, zkontrolujte, zda se mění tělo, a ne zda je port otevřený.

Fáze 4: PPP přebírá

PPP pak dodá chování relace: vyjednání spoje, ověření a následnou konfiguraci síťové vrstvy. Ověření PPP je oddělené od kontroly TLS, kterou klient už prošel. Certifikát serveru, který klient přijme, nic neříká o tom, zda jsou přihlašovací údaje uživatele platné nebo zda je účet oprávněn.

Přijatý certifikát a odmítnuté přihlášení si neodporují. Jsou to po sobě jdoucí fáze s nezávislými výsledky.

Ověřování má několik rolí

Klient ověří identitu serveru TLS proti svému úložišti důvěry a nakonfigurovanému názvu. PPP pak ověří uživatele nebo stroj podle nasazení. Server může přidat vlastní pravidla o tom, kdo se smí připojit a čeho smí dosáhnout. Udržujte název hostitele v souladu s identitou certifikátu, protože nahrazení surovou adresou promění funkční nastavení v poruchu kontroly názvu.

Zapište, která fáze poruchu nahlásila. Certifikát, metoda, řídicí zpráva, ověření PPP, pak trasy: pět míst, pět oprav.

Co test v prohlížeči může a nemůže ukázat

Načtení stránky na adrese dokazuje překlad DNS, dostupnost TCP a že něco poslouchá a mluví HTTP. Nedokazuje, že je metoda přijata, že výměna řídicích zpráv přežije nebo že je ověření PPP nakonfigurováno. Použijte klienta, který implementuje SSTP, místo abyste jiný profil převáděli změnou portu.

Když je relace navázaná, o tom, čeho uživatel dosáhne, stále rozhodují trasy, DNS a přesměrování na straně serveru. Tunel je cesta, ne oprávnění.