SSTP za proxy, ktoré kontroluje TLS: kde sa relácia preruší

Váš prehliadač načíta podnikový intranet, certifikát proxy je dôveryhodný, a napriek tomu klient SSTP spadne blízko konca spojenia. Tento vzorec ukazuje na rozdiel medzi webovou požiadavkou a reláciou v tuneli, nie na nesprávne heslo. Prejdite spojenie od TCP nahor a poznamenajte prvú fázu, ktorá zlyhá. Práve fáza, nie kód chyby, vám povie, či je príčinou proxy.

Začnite tam, kde sa klient zastaví

Klient prechádza pevnou postupnosťou: TCP spojenie na port 443, handshake TLS, overenie certifikátu, HTTP výmena SSTP, vyjednávanie a autentizácia PPP, potom konfigurácia IP. Zlyhanie v každej fáze zanecháva inú stopu a ich zámena vás zavedie na nesprávnu stránku nastavení.

Zlyhanie TCP je časový limit alebo reset skôr, než sa objaví čo i len jeden bajt TLS. Zlyhanie TLS je výstraha alebo časový limit handshake. Zlyhanie certifikátu vytvorí varovanie o reťazi alebo názve. Zlyhanie HTTP prichádza po úspešnom handshake, často ako stavový kód alebo okamžité zatvorenie. Zlyhanie PPP prichádza po tom, čo je tunel technicky vytvorený, a preto vyzerá ako problém s autentizáciou.

Čítajte klientsky log kvôli poslednej úspešnej fáze, nie prvému riadku chyby. Riadok chyby zvyčajne hlási následok, zatiaľ čo hranica fázy pomenúva komponent, ktorý odmietol.

Čo SSTP žiada od siete, aby prenášala

SSTP beží cez TLS na TCP 443 a potom posiela HTTP požiadavku SSTP_DUPLEX_POST, definovanú v špecifikácii SSTP, na cestu tvaru /sra_{GUID}/. Požiadavka deklaruje prakticky neobmedzenú dĺžku obsahu a udržiava tok otvorený v oboch smeroch po celý čas relácie. Rámce PPP putujú vnútri tohto toku.

Preto proxy, ktoré obsluhuje bežné prehliadanie, môže napriek tomu zlyhať. GET alebo POST s konečným telom možno bufferovať, skontrolovať a odoslať ďalej; duplexný tok s telom, ktoré sa nikdy neskončí, nie. Proxy, ktoré čaká na dokončenie tela, čaká večne a klient napokon vyprší.

Filtrovanie metód a autentizácia pridávajú vlastné režimy zlyhania. Ak proxy vyžiada prihlasovacie údaje k požiadavke, klient VPN nemusí odpovedať, hoci prehliadač by odpovedal. Ak metódu odstráni alebo prepíše, brána požiadavku odmietne skôr, než sa začne PPP.

Prečo kontrola mení identitu

Proxy, ktoré kontroluje TLS, ukončí klientske TLS spojenie a otvorí samostatné spojenie k bráne. Klient preto overuje certifikát proxy, nie brány, a brána vidí proxy ako svojho partnera. Keď organizácia distribuuje vlastný koreň, prehliadač aj klient VPN môžu tento reťaz prijať, takže handshake uspeje a problém sa posunie do ďalšej fázy.

Úspešné overenie neznamená, že proxy reláciu unesie. Stále musí preposielať neobmedzený obojsmerný POST bez bufferovania a udržať obe spojenia živé celé hodiny. Mnohé inspekčné produkty sú stavané na prevádzku požiadavka-odpoveď a tento prípad zvládajú zle alebo vôbec.

Preto je pridanie neznámeho koreňa alebo vypnutie overovania nesprávna oprava. Mení, ktorý certifikát klient prijme; s prácou s tokom, ktorá reláciu skutočne rozbila, nerobí nič.

Pred zmenou nastavení určite vydavateľa

Opýtajte sa koncového bodu, ktorý certifikát predkladá a kto ho podpísal. Nižšie uvedené príkazy ukážu reťaz a vydavateľa bez spustenia relácie VPN:

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

Ak je vydavateľom verejná CA, spojenie pre tento host pravdepodobne nie je odpočúvané a zlyhanie je inde. Ak je vydavateľom vlastná CA organizácie, kontrola je aktívna a brána sa dosahuje cez proxy. Porovnajte odtlačok s tým, ktorý očakáva sieťový tím, než urobíte záver len podľa názvu.

Test prehliadača na rovnaký host dokazuje len to, že proxy prijíma GET. Nič nehovorí o metóde SSTP, URI požiadavky ani životnosti tela, takže funkčnú intranetovú stránku nepovažujte za dôkaz, že cesta tunela je podporovaná.

Zvoľte podporovanú cestu

Položte vlastníkovi siete jednu konkrétnu otázku: povoľuje proxy nebufferovaný duplexný POST k tejto bráne na porte 443? Áno vedie k výnimke v proxy alebo k dokumentovanému obchvatu pre host VPN. Nie znamená, že kontrolovaná cesta nemôže uniesť SSTP, a podporovanou opravou je iná cesta alebo protokol, nie úprava klienta.

Možnosti zvyčajne zahŕňajú nekontrolovaný výstup pre bránu VPN, návrh rozdeleného tunela, ktorý posiela cez proxy len podnikový provoz, alebo alternatívny protokol, ktorý organizácia podporuje na inom porte. Každá patrí do sieťového návrhu a každá by sa mala otestovať s rovnakým zariadením a profilom, aby porovnanie izolovalo cestu.

Zdokumentujte výsledok: vydavateľ, zlyhávajúca fáza, pravidlo proxy a zvolená cesta. Ďalší človek, ktorý uvidí rovnaké zaseknutie na 98 percentách, môže overiť jediný fakt namiesto opakovania celého prechodu.