SSTP selhává tam, kde HTTPS v prohlížeči funguje: proč
SSTP běží uvnitř TLS na portu 443, ale není to webový požadavek. Testujte TCP, identitu TLS, výměnu SSTP a autentizaci PPP jako samostatné fáze.
Prohlížeč otevře název hostitele VPN přes HTTPS bez stížnosti a klient SSTP přesto odmítá připojení. Na této dvojici není nic protichůdného. SSTP používá TLS jako vnější transport a poté v tomto spojení provozuje vlastní požadavek a užitečné zatížení PPP, takže úspěšné načtení stránky dokazuje jen jednu úzkou věc: hostitel odpovídá na GET na portu 443. Klient se ptá na jinou otázku a server na ni může odpovědět špatně.
Stránka se načte a tunel ne
Lidé sahají po testu v prohlížeči, protože je rychlý, a výsledek pak berou jako důkaz, že server je dostupný a nakonfigurovaný. Je to důkaz o GET na cestu, kterou otevřela adresní řádek, nic víc. VPN rozhovor začíná po stejném TLS handshake, ale posílá metodu a cestu, které webová stránka nikdy nepoužívá. Odpověď 200 pro prohlížeč tedy nic neříká o tom, zda koncový bod SSTP existuje.
Oddělte obě pozorování a hledání se zkrátí. Transport a řetězec certifikátů fungují a něco ve výměně protokolu nad nimi ne. To je jiné vyšetřování než rozbitý port nebo prošlý certifikát a vyžaduje jiné důkazy.
Co klient SSTP skutečně posílá
Klient posílá HTTP požadavek s metodou SSTP_DUPLEX_POST na cestu /sra_{GUID}/ a poté drží tělo spojení otevřené jako obousměrný proud nesoucí rámce PPP. Vyhovující server odpoví HTTP/1.1 200 a přestane se chovat jako webový server. Cokoli jiného je podpis: 405 nebo 404 znamená, že koncový bod není, 301 nebo 302 znamená, že něco požadavek přesměrovává, a okamžitý FIN znamená, že proxy nebo server proud uzavřel.
Proto musí být cílem server SSTP, nikoli webový server s přišroubovaným TLS certifikátem. Metoda, cesta a dlouho otevřené tělo jsou požadavky protokolu, takže reverzní proxy je nemůže přidat pouhou konfigurací. Proxy, která dokonale předává běžné HTTPS, může přesto odmítnout metodu, kterou nezná.
Kde proxy nebo webový server přeruší proud
Prostředník zkontroluje řádek HTTP požadavku, než cokoli předá, a vlastní metoda s neobvyklou cestou může jeho pravidla nesplnit. Některá zařízení obsluhují normální stránku, zatímco tunel odmítají nebo přerušují, takže klient hlásí spojení, které začne a pak zemře, místo čistého odmítnutí. Jiná požadavek přijmou a pak uplatní časový limit těla nebo nečinnosti, který keepalive PPP nepřežijí. Obě vypadají z pohledu klienta stejně, proto je fáze, která selhala, důležitější než text chyby.
Sdílení portu 443 mezi webem a SSTP je volba směrování, ne slib, že každý skok zvládne oba rozhovory stejně. Pokud je v cestě vyvažovač zátěže, firewall nebo TLS terminátor, přidejte ho na seznam podezřelých, než se dotknete konfigurace VPN.
Testujte fáze odděleně
Proveďte kontroly v pořadí a zastavte se u prvního selhání, protože každá fáze vylučuje jinou vrstvu. TLS sonda níže odděluje identitu certifikátu od všeho, co SSTP dělá. Nahraďte název hostitele svým koncovým bodem a přečtěte subjekt a řetězec, který vypíše.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comPoté přiřaďte zbývající důkazy k fázím, místo abyste hádali z chyby klienta. Tabulka níže je kontrolní seznam pro tiket s podpisem, který odděluje jedno selhání od dalšího.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
Do tiketu zapište poslední úspěšnou fázi, místo abyste psali "nelze se připojit". Specifikace MS-SSTP dokumentuje požadavek a výměnu PPP, které následují po TLS handshake, a je referencí pro to, proč test v prohlížeči nemůže nahradit ani jedno z nich.
Nejprve identita, potom PPP
Identita TLS a autentizace PPP jdou za sebou, nejsou alternativou, a jejich záměna posílá lidi ke špatnému nastavení serveru. Klient nejprve ověří certifikát serveru a jeho zamýšlený účel, poté PPP vyjedná svůj stav a autentizuje uživatele metodou výzva-odpověď nebo EAP. Problém s certifikátem dává jinou chybu než odmítnuté heslo a ani jedna chyba nepopisuje fázi, kterou pokrývá ta druhá.
Nahrazení názvu hostitele adresou nebo prokliknutí varování o certifikátu odstraní kontrolu, která by identifikovala selhávající fázi, místo aby ji opravilo. Varování si nechte a přečtěte ho. Neresetujte PPP heslo, když HTTP výměna nikdy nedospěla k chování SSTP, protože přihlašovací údaj nebyl nikdy vyžádán.