SSTP za proxy, které kontroluje TLS: kde se relace přeruší

Váš prohlížeč načte firemní intranet, certifikát proxy je důvěryhodný, a přesto klient SSTP spadne poblíž konce spojení. Tento vzorec ukazuje na rozdíl mezi webovým požadavkem a relací v tunelu, ne na špatné heslo. Projděte spojení od TCP nahoru a poznamenejte první fázi, která selže. Právě fáze, ne kód chyby, vám řekne, zda je příčinou proxy.

Začněte tam, kde se klient zastaví

Klient prochází pevnou posloupností: TCP spojení na port 443, handshake TLS, ověření certifikátu, HTTP výměna SSTP, vyjednávání a autentizace PPP, poté konfigurace IP. Selhání v každé fázi zanechává jiný podpis a jejich záměna vás zavede na špatnou stránku nastavení.

Selhání TCP je časový limit nebo reset dřív, než se objeví jakýkoli bajt TLS. Selhání TLS je výstraha nebo časový limit handshake. Selhání certifikátu vytvoří varování o řetězu nebo názvu. Selhání HTTP přichází po úspěšném handshake, často jako stavový kód nebo okamžité zavření. Selhání PPP přichází poté, co je tunel technicky vytvořen, a proto vypadá jako problém autentizace.

Čtěte klientský log kvůli poslední úspěšné fázi, ne prvnímu řádku chyby. Řádek chyby obvykle hlásí následek, zatímco hranice fáze pojmenovává komponentu, která odmítla.

Co SSTP žádá od sítě, aby přenášela

SSTP běží přes TLS na TCP 443 a poté posílá HTTP požadavek SSTP_DUPLEX_POST, definovaný v specifikaci SSTP, na cestu tvaru /sra_{GUID}/. Požadavek deklaruje prakticky neomezenou délku obsahu a udržuje tok otevřený v obou směrech po celou dobu relace. Rámce PPP putují uvnitř tohoto toku.

Proto proxy, které obsluhuje běžné prohlížení, může přesto selhat. GET nebo POST s konečným tělem lze bufferovat, zkontrolovat a předat; duplexní tok s tělem, které nikdy neskončí, ne. Proxy, které čeká na dokončení těla, čeká věčně a klient nakonec vyprší.

Filtrování metod a autentizace přidávají vlastní režimy selhání. Pokud proxy vyžádá přihlašovací údaje k požadavku, klient VPN nemusí odpovědět, i když prohlížeč by odpověděl. Pokud metodu odstraní nebo přepíše, brána požadavek odmítne dřív, než začne PPP.

Proč kontrola mění identitu

Proxy, které kontroluje TLS, ukončí klientské TLS spojení a otevře samostatné spojení k bráně. Klient proto ověřuje certifikát proxy, ne brány, a brána vidí proxy jako svého protějška. Když organizace distribuuje vlastní kořen, prohlížeč i klient VPN mohou tento řetěz přijmout, takže handshake uspěje a problém se posune do další fáze.

Úspěšné ověření neznamená, že proxy relaci unese. Stále musí přeposílat neomezený obousměrný POST bez bufferování a udržet obě spojení živá celé hodiny. Mnoho inspekčních produktů je stavěno na provoz požadavek-odpověď a tento případ zvládá špatně nebo vůbec.

Proto je přidání neznámého kořene nebo vypnutí ověřování špatná oprava. Mění, který certifikát klient přijme; s prací s tokem, která relaci skutečně rozbila, nedělá nic.

Než změníte nastavení, určete vydavatele

Zeptejte se koncového bodu, který certifikát předkládá a kdo jej podepsal. Níže uvedené příkazy ukážou řetěz a vydavatele bez spuštění relace VPN:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

Pokud je vydavatelem veřejná CA, spojení pro tento host pravděpodobně není odposloucháváno a selhání je jinde. Pokud je vydavatelem vlastní CA organizace, kontrola je aktivní a brána je dosažena přes proxy. Porovnejte otisk s tím, který síťový tým očekává, než uděláte závěr jen podle názvu.

Test prohlížeče na stejný host dokazuje jen to, že proxy přijímá GET. Nic neříká o metodě SSTP, URI požadavku ani životnosti těla, takže funkční intranetovou stránku nepovažujte za důkaz, že cesta tunelu je podporována.

Zvolte podporovanou cestu

Položte vlastníkovi sítě jednu konkrétní otázku: povoluje proxy nebufferovaný duplexní POST k této bráně na portu 443? Ano vede k výjimce v proxy nebo k dokumentovanému obchvatu pro host VPN. Ne znamená, že kontrolovaná cesta nemůže unést SSTP, a podporovanou opravou je jiná cesta nebo protokol, ne úprava klienta.

Možnosti obvykle zahrnují nekontrolovaný výstup pro bránu VPN, návrh rozděleného tunelu, který posílá přes proxy jen firemní provoz, nebo alternativní protokol, který organizace podporuje na jiném portu. Každá patří do síťového návrhu a každá by měla být otestována se stejným zařízením a profilem, aby srovnání izolovalo cestu.

Zdokumentujte výsledek: vydavatel, selhávající fáze, pravidlo proxy a zvolená cesta. Další člověk, který uvidí stejné zaseknutí na 98 procentech, může ověřit jediný fakt místo opakování celého průchodu.