SSTP najpierw uwierzytelnia serwer, a dopiero potem użytkownika

Klient SSTP może ukończyć TLS, a mimo to sekundę później odrzucić użytkownika. Ta kolejność nie jest błędem, to stos protokołów: najpierw bezpieczeństwo transportu, potem uwierzytelnienie użytkownika. Ponieważ oba etapy kończą się niepowodzeniem z różnymi komunikatami, wymagają też różnych napraw. Odczytanie, który etap wygenerował błąd, to większość diagnostyki.

Zaufany certyfikat dowodzi punktu końcowego; o koncie nie mówi nic.

Co ustala uzgadnianie TLS

Klient weryfikuje certyfikat przedstawiony przez serwer względem swojego magazynu zaufania, żądanej nazwy hosta, okna ważności i wszelkich dodatkowych zasad stosowanych przez platformę. To chroni połączenie z zamierzonym punktem końcowym. Nie dowodzi jednak, że konkretne konto jest włączone, niewygasłe lub uprawnione do dostępu zdalnego. To osobne pytania zadawane później przez inny komponent.

Dlatego usuwanie kontroli certyfikatów, aby dotrzeć do monitu logowania, jest niewłaściwą naprawą. Otrzymujesz monit logowania na połączeniu, którego nie możesz zweryfikować. Błąd certyfikatu należy do nazwy hosta, zegara, łańcucha lub konfiguracji zaufania.

Co dodają SSTP i PPP

SSTP działa przez HTTPS i przenosi w sobie PPP, z własną wymianą sterującą wokół połączenia. Następnie PPP wykonuje swoje fazy łącza i uwierzytelniania, a metoda uwierzytelniania zależy od polityki serwera i możliwości klienta. PAP, CHAP, MS-CHAPv2 i EAP to wszystkie opcje uwierzytelniania PPP o bardzo różnych właściwościach. Sprawdzenie użytkownika w VPN to właśnie ta faza PPP, a nie warstwa TLS pod nią.

Odrzucenie użytkownika może więc oznaczać poświadczenia, ograniczenie konta lub niezgodność metody.

Przyczyna po stronie serwera jest znacznie bardziej użyteczna niż resetowanie każdego sekretu w profilu. Zdarzenie wyłączonego konta i niepowodzenie negocjacji metody wyglądają podobnie u klienta i nie mają nic wspólnego na serwerze.

Przypisz błąd do etapu

Sprawdź, czy połączenie dociera do TLS, następnie do wymiany HTTP SSTP, następnie do fazy PPP. Utrzymuj znaczniki czasu w logach wyrównane między próbami, aby wcześniejsza awaria nie została pomylona z późniejszym sukcesem. Klient, który rejestruje dwie próby w jednym oknie, w przeciwnym razie wygląda, jakby zawiódł na ostatnim osiągniętym etapie. Czytaj pierwszy istotny błąd, a nie ostatnią linię.

To samo wyrównanie ma znaczenie po stronie serwera, gdzie rekord uwierzytelniania i log transportu to często osobne pliki z osobnymi zegarami. Dwie minuty rozbieżności wystarczą, by oczywista przyczyna wyglądała na niemożliwą.

Po zalogowaniu autoryzacja nadal jest osobna

Udane logowanie nie przyznaje każdego prywatnego zasobu. Trasy określają, co jest osiągalne, DNS określa, co jest rozwiązywane, a każda usługa nadal stosuje własne uprawnienia. Sesja pokazana jako połączona jest stwierdzeniem o tunelu, a nie o udostępnianiu plików. Gdy użytkownik może się połączyć i nie może dotrzeć do jednego hosta, faza tunelu już się zakończyła.

To ta sama warstwowość, którą pokazało uzgadnianie, o poziom wyżej.

Pozostaw odzyskiwanie konta w procesie obsługiwanym przez operatora, zamiast zmieniać ustawienia transportu w odpowiedzi na wyraźną odmowę użytkownika. Zmiana transportu, aby naprawić wyłączone konto, to rodzaj naprawy, który wydaje się działać, gdy konto zostaje ponownie włączone z niepowiązanego powodu.