SSTP to PPP nad HTTPS, a nie strona internetowa na porcie 443

SSTP przenosi PPP wewnątrz połączenia HTTPS, dlatego dla wszystkiego pośrodku wygląda jak ruch webowy. TLS i HTTP ustanawiają zewnętrzny kanał, następnie komunikaty sterujące SSTP przygotowują tunel, a PPP zapewnia zachowanie sesji. Przeglądarka, która ładuje stronę pod tym samym adresem ukończyła tylko część pierwszego etapu. Traktowanie tego jako testu VPN to sposób, w jaki działające proxy zostaje obwinione o niezgodność protokołu.

Przejdź cztery etapy po kolei, a widoczna awaria trafi do jednego z nich.

Etap 1: TCP i TLS

Klient otwiera połączenie TCP na port 443 i wykonuje uzgadnianie TLS. Łańcuch certyfikatów musi odpowiadać nazwie hosta, z którą skonfigurowano klienta. Niezgodność nazwy powoduje tutaj awarię, zanim wymieniony zostanie jakikolwiek komunikat SSTP, a specyfikacja SSTP zakłada, że ten zewnętrzny kanał HTTPS już istnieje. Nic w późniejszych etapach nie zrekompensuje awarii zaufania tutaj.

Zwykły serwer WWW może doskonale ukończyć ten etap i mimo to ponieść porażkę w następnym. Sukces TLS jest dowodem na temat certyfikatu, a nie protokołu za nim.

Etap 2: żądanie HTTPS

SSTP wysyła swoje żądanie określoną metodą, SSTP_DUPLEX_POST, i utrzymuje wymianę otwartą zamiast zwracać dokument. Serwer lub proxy skonfigurowane do zwykłych żądań stron może przyjąć połączenie, a następnie odrzucić metodę. To odrzucenie jest problemem zgodności, który ludzie zwykle opisują jako zablokowany port 443.

Przeczytaj kod odpowiedzi i metodę w dzienniku serwera. Odrzucenie na tym etapie to inny problem niż przekroczenie czasu TCP, a oba prowadzą do różnych poprawek.

Etap 3: komunikaty sterujące

Gdy żądanie zostanie przyjęte, SSTP wymienia komunikaty sterujące, które negocjują i przygotowują tunel. To komunikaty protokołu wewnątrz treści HTTPS, a nie żądania HTTP, więc proxy, które sprawdza i przepisuje treści, może je zepsuć, pozostawiając żądania stron nietknięte.

Tutaj urządzenie do głębokiej inspekcji zdobywa reputację. Jeśli strony się ładują, a VPN zawodzi, sprawdź, czy treść jest modyfikowana, a nie czy port jest otwarty.

Etap 4: PPP przejmuje

Następnie PPP zapewnia zachowanie sesji: negocjację łącza, uwierzytelnianie i następującą konfigurację warstwy sieciowej. Uwierzytelnianie PPP jest oddzielne od sprawdzenia TLS, które klient już przeszedł. Certyfikat serwera, który klient akceptuje, nic nie mówi o tym, czy dane logowania użytkownika są ważne albo czy konto jest upoważnione.

Zaakceptowany certyfikat i odrzucone logowanie nie są sprzeczne. To kolejne etapy o niezależnych wynikach.

Uwierzytelnianie ma kilka ról

Klient weryfikuje tożsamość serwera TLS wobec swojego magazynu zaufania i skonfigurowanej nazwy. Następnie PPP uwierzytelnia użytkownika lub maszynę, zależnie od wdrożenia. Serwer może dodać własną politykę dotyczącą tego, kto może się łączyć i do czego może dotrzeć. Utrzymuj nazwę hosta zgodną z tożsamością certyfikatu, bo zastąpienie jej surowym adresem zamienia działającą konfigurację w awarię sprawdzania nazwy.

Zapisz, który etap zgłosił awarię. Certyfikat, metoda, komunikat sterujący, uwierzytelnianie PPP, potem trasy: pięć miejsc, pięć napraw.

Co test w przeglądarce może, a czego nie może pokazać

Załadowanie strony pod adresem dowodzi rozwiązywania DNS, osiągalności TCP i tego, że coś nasłuchuje i mówi po HTTP. Nie dowodzi, że metoda jest akceptowana, że wymiana sterująca przetrwa albo że uwierzytelnianie PPP jest skonfigurowane. Użyj klienta, który implementuje SSTP, zamiast konwertować inny profil przez zmianę portu.

Gdy sesja jest podniesiona, trasy, DNS i przekazywanie po stronie serwera nadal decydują, do czego użytkownik może dotrzeć. Tunel to ścieżka, a nie upoważnienie.