Limit czasu SSTP czy błąd certyfikatu: jak je rozróżnić

Połączenie SSTP zawodzi na dwa sposoby, które z krzesła użytkownika wyglądają tak samo, a naprawa każdego leży na innej warstwie. Limit czasu oznacza, że wymagana wymiana nigdy się nie zakończyła; błąd certyfikatu oznacza, że materiał tożsamości dotarł i został odrzucony. Traktowanie drugiego jak pierwszego prowadzi do zapór ogniowych i haseł, które nigdy nie były problemem. Rozstrzygający dowód jest w logu samego klienta, jeśli przeczytasz go, zanim cokolwiek zmienisz.

Dwie awarie, dwie różne wymiany

SSTP przenosi tunel wewnątrz sesji o kształcie HTTPS, dlatego przetrwa w sieciach, które nie pozwalają na nic oprócz 443. Klient kończy uzgadnianie TLS, wysyła żądanie HTTP metodą właściwą dla protokołu, a następnie tunel działa w tym strumieniu. Awaria na którymkolwiek z tych etapów zatrzymuje połączenie, a tylko późniejsze dotyczą danych logowania.

Ta kolejność jest diagnozą. Jeśli uzgadnianie TLS nigdy się nie kończy, nie wysłano żadnych danych logowania, więc reset hasła nie może pomóc. Jeśli uzgadnianie kończy się i potem zastyga, tożsamość została przyjęta, a coś na ścieżce żądania ją odrzuciło. Jeśli uzgadnianie zawodzi z komunikatem walidacji, serwer odpowiedział, a klientowi nie spodobało się to, co usłyszał. Trzy wyniki, trzy warstwy.

Wiersz logu zwykle mówi, w którym z trzech przypadków jesteś, dlatego warto go zapisać przed pierwszą zmianą.

Limit czasu oznacza, że etap nigdy się nie zakończył

Zacznij od rozwiązywania nazw i osiągalności TCP, bo limit czasu tam wygląda identycznie jak limit czasu później. Sprawdzanie portu, które zgłasza 443 jako otwarty, dowodzi jedynie, że nasłuchujący przyjął połączenie, i niczego więcej.

Następnym podejrzanym jest ścieżka, a nie host. Proxy i zapory ogniowe świadome aplikacji czasem odrzucają metodę żądania używaną przez SSTP albo zrzucają strumień, który pozostaje otwarty godzinami, i oba zachowania wyglądają z perspektywy klienta jak limit czasu. Zwykła strona HTTPS serwowana przez ten sam host ładuje się bezbłędnie, podczas gdy metoda tunelu jest odrzucana, dlatego przeglądanie punktu końcowego dowodzi tak niewiele. Przetestuj z sieci bez proxy, aby rozdzielić te dwa przypadki.

Test-NetConnection vpn.example.com -Port 443
netsh http show sslcert
Get-WinEvent -LogName 'Microsoft-Windows-RasSstp/Operational' -MaxEvents 20

Limit czasu przed jakąkolwiek odpowiedzią drugiej strony nic nie mówi o koncie, a zmiana hasła w tym momencie dodaje tylko jedną zmienną.

Błąd certyfikatu oznacza, że tożsamość została odrzucona

Tu serwer rzeczywiście odpowiedział, więc sieć działa, a pytanie przenosi się na tożsamość. Porównaj nazwę, na którą dzwoni klient, z nazwami, które certyfikat naprawdę deklaruje, a potem sprawdź daty ważności i łańcuch wystawcy.

Prywatny CA, któremu klient nie ufa, daje tę samą klasę błędu co wygasły certyfikat, podobnie jak zegar mylący się o godziny. Wybieranie surowego adresu tworzy nową niezgodność, bo certyfikat deklaruje nazwy, a nie adresy. W zarządzanym wdrożeniu pobierz zamierzoną konfigurację zaufania od jej administratora, zamiast przyjmować zastępczy korzeń proponowany przez stronę błędu. Walidacja pozostaje włączona, dopóki naprawiasz przyczynę.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName
w32tm /query /status

Zostaw udany etap TLS nietknięty, gdy już przejdzie, bo cofnięcie go później ukrywa, która zmiana naprawdę naprawiła tunel.

Gdzie te dwa się mylą

Obie awarie wyglądają jak połączenie, które nie wstaje, i obie pojawiają się po tym, jak użytkownik zmienił coś niezwiązanego. To właśnie ta zbieżność sprawia, że błędna naprawa przez jakiś czas wygląda wiarygodnie.

Dwa nawyki trzymają je osobno. Zapisz log klienta, zanim dotkniesz konfiguracji, aby pierwszy stan pozostał zachowany. Zmieniaj jedną warstwę na próbę, aby następny wynik należał do znanej zmiennej. Sprawdzanie portu i przeglądarka to obserwacje częściowe, a nie cała sekwencja, i żadne z nich nie zastępuje raportu samego klienta. Żaden nawyk nic nie kosztuje, a oba skracają śledztwo.

Kwestia certyfikatu i kwestia osiągalności są udokumentowane osobno nie bez powodu.

Przetestuj ponownie prawdziwym klientem, potem idź do środka

Gdy konkretna poprawka jest na miejscu, spróbuj ponownie z rzeczywistym klientem SSTP i prawdziwym profilem, a nie z kartą przeglądarki.

rasdial "Corp SSTP" /disconnect
rasdial "Corp SSTP" user '*'
Get-VpnConnection -Name "Corp SSTP" | Select-Object ServerAddress, TunnelType, AuthenticationMethod

Jeśli sesja się łączy, a zasoby nadal zawodzą, tunel nie jest już podejrzanym: przejdź do routingu, DNS i dostępu do usług. To inne śledztwo z innymi dowodami. Zachowanie działających etapów TLS i uwierzytelniania zapobiega temu, by stało się powtórzeniem pierwszego. Zapisz w zgłoszeniu etap, który zawiódł, inaczej następna osoba znów zacznie od góry.