SSTP za serwerem proxy sprawdzającym TLS: gdzie urywa się sesja

Przeglądarka ładuje intranet firmowy, certyfikat proxy jest zaufany, a klient SSTP nadal zrywa połączenie pod koniec. Ten wzorzec wskazuje na różnicę między żądaniem WWW a sesją w tunelu, nie na błędne hasło. Przejdź połączenie od TCP w górę i zanotuj pierwszy etap, który zawodzi. To etap, a nie kod błędu, mówi, czy przyczyną jest proxy.

Zacznij tam, gdzie zatrzymuje się klient

Klient przechodzi stałą sekwencję: połączenie TCP z portem 443, uzgadnianie TLS, walidacja certyfikatu, wymiana HTTP SSTP, negocjacja i uwierzytelnianie PPP, a następnie konfiguracja IP. Awaria na każdym etapie zostawia inny ślad, a ich pomylenie prowadzi do niewłaściwej strony konfiguracji.

Awaria TCP to przekroczenie czasu lub reset, zanim pojawi się choć jeden bajt TLS. Awaria TLS to ostrzeżenie lub przekroczenie czasu uzgadniania. Awaria certyfikatu daje ostrzeżenie o łańcuchu lub nazwie. Awaria HTTP przychodzi po udanym uzgadnianiu, często jako kod stanu lub natychmiastowe zamknięcie. Awaria PPP przychodzi po technicznym zestawieniu tunelu, dlatego wygląda jak problem z uwierzytelnianiem.

Czytaj dziennik klienta pod kątem ostatniego udanego etapu, a nie pierwszego wiersza błędu. Wiersz błędu zwykle zgłasza skutek, a granica etapu nazywa komponent, który odmówił.

Czego SSTP wymaga od sieci

SSTP działa przez TLS na TCP 443, a następnie wysyła żądanie HTTP o nazwie SSTP_DUPLEX_POST, zdefiniowane w specyfikacji SSTP, na ścieżkę w postaci /sra_{GUID}/. Żądanie deklaruje praktycznie nieograniczoną długość treści i utrzymuje strumień otwarty w obu kierunkach przez cały czas trwania sesji. Ramki PPP podróżują wewnątrz tego strumienia.

Dlatego proxy obsługujący zwykłe przeglądanie może nadal zawieść. GET lub POST z ograniczoną treścią można buforować, sprawdzić i przekazać; strumienia dupleksowego z treścią, która nigdy się nie kończy, nie można. Proxy czekające na zakończenie treści czeka wiecznie, a klient w końcu przekracza czas.

Filtrowanie metod i uwierzytelnianie dodają własne tryby awarii. Jeśli proxy żąda danych logowania do żądania, klient VPN może nie odpowiedzieć, choć przeglądarka by odpowiedziała. Jeśli usunie lub przepisze metodę, brama odrzuca żądanie, zanim zacznie się PPP.

Dlaczego inspekcja zmienia tożsamość

Proxy sprawdzające TLS kończy połączenie TLS klienta i otwiera osobne połączenie do bramy. Klient waliduje więc certyfikat proxy, a nie bramy, a brama widzi proxy jako swojego partnera. Gdy organizacja rozprowadza własny korzeń, zarówno przeglądarka, jak i klient VPN mogą zaakceptować ten łańcuch, więc uzgadnianie się udaje, a problem przechodzi do następnego etapu.

Udana walidacja nie oznacza, że proxy potrafi przenieść sesję. Nadal musi przekazywać nieograniczony dwukierunkowy POST bez buforowania i utrzymywać oba połączenia żywe przez godziny. Wiele produktów inspekcyjnych jest zbudowanych pod ruch żądanie-odpowiedź i obsługuje ten przypadek źle lub wcale.

Dlatego dodanie nieznanego korzenia lub wyłączenie weryfikacji to zła naprawa. Zmienia to, który certyfikat akceptuje klient; nie robi nic z obsługą strumienia, która faktycznie zerwała sesję.

Ustal wystawcę, zanim zmienisz ustawienia

Zapytaj punkt końcowy, jaki certyfikat prezentuje i kto go podpisał. Poniższe polecenia pokazują łańcuch i wystawcę bez uruchamiania sesji VPN:

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

Jeśli wystawcą jest publiczny CA, połączenie dla tego hosta prawdopodobnie nie jest przechwytywane, a awaria jest gdzie indziej. Jeśli wystawcą jest własny CA organizacji, inspekcja jest aktywna, a brama jest osiągana przez proxy. Porównaj odcisk palca z tym, którego oczekuje zespół sieciowy, zanim wyciągniesz wniosek tylko z nazwy.

Test przeglądarki do tego samego hosta dowodzi tylko, że proxy akceptuje GET. Nic nie mówi o metodzie SSTP, URI żądania ani czasie życia treści, więc nie traktuj działającej strony intranetowej jako dowodu wsparcia ścieżki tunelu.

Wybierz obsługiwaną ścieżkę

Zadaj właścicielowi sieci jedno konkretne pytanie: czy proxy zezwala na niebuforowany dupleksowy POST do tej bramy na porcie 443? Tak prowadzi do wyjątku w proxy lub udokumentowanego obejścia dla hosta VPN. Nie oznacza, że sprawdzona ścieżka nie może przenieść SSTP, a obsługiwanym rozwiązaniem jest inna ścieżka lub protokół, nie dostrajanie klienta.

Opcje zwykle obejmują niekontrolowane wyjście dla bramy VPN, projekt tunelu dzielonego, który wysyła przez proxy tylko ruch firmowy, albo alternatywny protokół obsługiwany przez organizację na innym porcie. Każda należy do projektu sieci i każdą należy przetestować na tym samym urządzeniu i profilu, aby porównanie wyizolowało ścieżkę.

Udokumentuj wynik: wystawca, nieudany etap, reguła proxy i wybrana ścieżka. Następna osoba, która zobaczy to samo zatrzymanie na 98 procent, będzie mogła sprawdzić jeden fakt zamiast powtarzać cały przegląd.