SSTP zawodzi tam, gdzie HTTPS w przeglądarce działa: dlaczego
SSTP działa wewnątrz TLS na porcie 443, ale nie jest żądaniem sieciowym. Testuj TCP, tożsamość TLS, wymianę SSTP i uwierzytelnianie PPP jako osobne etapy.
Przeglądarka otwiera nazwę hosta VPN przez HTTPS bez protestu, a klient SSTP nadal odmawia połączenia. W tej parze nie ma nic sprzecznego. SSTP używa TLS jako transportu zewnętrznego, a następnie wykonuje własne żądanie i ładunek PPP w tym połączeniu, więc udane wczytanie strony dowodzi tylko jednej wąskiej rzeczy: host odpowiada na GET na porcie 443. Klient zadaje inne pytanie, a serwer może odpowiedzieć na nie źle.
Strona się ładuje, a tunel nie
Ludzie sięgają po test w przeglądarce, bo jest szybki, a potem traktują wynik jako dowód, że serwer jest osiągalny i skonfigurowany. To dowód dotyczący GET na ścieżkę otwartą przez pasek adresu, nic więcej. Rozmowa VPN zaczyna się po tym samym uścisku dłoni TLS, ale wysyła metodę i ścieżkę, których strona internetowa nigdy nie używa. Dlatego odpowiedź 200 dla przeglądarki nic nie mówi o tym, czy punkt końcowy SSTP istnieje.
Oddziel oba spostrzeżenia, a poszukiwanie się skraca. Transport i łańcuch certyfikatów działają, a coś w wymianie protokołu nad nimi nie działa. To inne śledztwo niż zepsuty port czy wygasły certyfikat i wymaga innych dowodów.
Co klient SSTP faktycznie wysyła
Klient wysyła żądanie HTTP metodą SSTP_DUPLEX_POST na ścieżkę /sra_{GUID}/, a następnie utrzymuje treść połączenia otwartą jako strumień dwukierunkowy przenoszący ramki PPP. Zgodny serwer odpowiada HTTP/1.1 200 i przestaje zachowywać się jak serwer WWW. Wszystko inne jest podpisem: 405 lub 404 oznacza, że punktu końcowego nie ma, 301 lub 302 oznacza, że coś przekierowuje żądanie, a natychmiastowy FIN oznacza, że proxy lub serwer zamknął strumień.
Dlatego celem musi być serwer SSTP, a nie serwer WWW z przykręconym certyfikatem TLS. Metoda, ścieżka i długotrwała treść są wymogami protokołu, więc odwrotne proxy nie może ich dodać samą konfiguracją. Proxy, które doskonale przekazuje zwykły HTTPS, nadal może odrzucić metodę, której nie rozpoznaje.
Gdzie proxy lub serwer WWW przerywa strumień
Pośrednik sprawdza wiersz żądania HTTP, zanim cokolwiek przekaże, a niestandardowa metoda z nietypową ścieżką może nie przejść jego reguł. Niektóre urządzenia serwują normalną stronę, jednocześnie odrzucając lub przerywając tunel, więc klient zgłasza połączenie, które zaczyna się i potem umiera, zamiast czystej odmowy. Inne akceptują żądanie, a następnie stosują limit czasu treści lub bezczynności, którego keepalive PPP nie przetrwają. Oba wyglądają tak samo z perspektywy klienta, dlatego etap, który zawiódł, jest ważniejszy niż tekst błędu.
Współdzielenie portu 443 między witryną a SSTP to wybór routingu, a nie obietnica, że każdy przeskok obsłuży obie rozmowy tak samo. Jeśli na ścieżce stoi balansujący obciążenie, zapora lub terminator TLS, dodaj go do listy podejrzanych, zanim dotkniesz konfiguracji VPN.
Testuj etapy osobno
Wykonaj kontrole po kolei i zatrzymaj się na pierwszej porażce, bo każdy etap wyklucza inną warstwę. Sonda TLS poniżej oddziela tożsamość certyfikatu od wszystkiego, co robi SSTP. Zastąp nazwę hosta swoim punktem końcowym i odczytaj subject oraz łańcuch, który wypisuje.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comNastępnie przypisz pozostałe dowody do etapów, zamiast zgadywać z błędu klienta. Tabela poniżej to lista kontrolna do zacytowania w zgłoszeniu, z podpisem, który oddziela jedną porażkę od następnej.
| 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 |
W zgłoszeniu zapisz ostatni udany etap, zamiast pisać "nie można się połączyć". Specyfikacja MS-SSTP dokumentuje żądanie i wymianę PPP, które następują po uścisku dłoni TLS, i jest odniesieniem, dlaczego test w przeglądarce nie może zastąpić żadnego z nich.
Najpierw tożsamość, potem PPP
Tożsamość TLS i uwierzytelnianie PPP są sekwencyjne, nie alternatywne, a mieszanie ich prowadzi ludzi do niewłaściwego ustawienia serwera. Klient najpierw weryfikuje certyfikat serwera i jego zamierzone przeznaczenie, potem PPP negocjuje własny stan i uwierzytelnia użytkownika metodą wyzwanie-odpowiedź lub EAP. Problem z certyfikatem daje inny błąd niż odrzucone hasło i żaden z błędów nie opisuje etapu, który obejmuje drugi.
Zastąpienie nazwy hosta adresem lub kliknięcie poza ostrzeżeniem o certyfikacie usuwa kontrolę, która zidentyfikowałaby zawodzący etap, zamiast go naprawić. Zachowaj ostrzeżenie i przeczytaj je. Nie resetuj też hasła PPP, gdy wymiana HTTP nigdy nie osiągnęła zachowania SSTP, bo dane logowania nigdy nie zostały poproszone.