Jak sprawdzić, czy klient VPN naprawdę obsługuje SSTP

Nazwanie produktu klientem VPN nic nie mówi o tym, czy mówi on SSTP, a port 443 w adresie dowodzi jeszcze mniej. SSTP uruchamia TLS po TCP 443, potem wymianę kontrolną SSTP, potem PPP dla samego łącza, a na wierzchu walidację certyfikatu i metodę uwierzytelniania PPP. Klient obsługuje protokół tylko wtedy, gdy wskazana implementacja w zainstalowanej wersji przechodzi każdą z tych warstw zgodnie z wymaganiami serwera. Wykonaj poniższe kontrole po kolei i zatrzymaj się na pierwszej, która zawiedzie, bo to ją warto rozwiązać.

Dopasuj implementację, wersję i platformę

Zacznij od platformy, aplikacji i zainstalowanej kompilacji, bo jedna nazwa producenta może stać nad dwiema zupełnie różnymi implementacjami. Wbudowane typy VPN i klienci firm trzecich to nie to samo, a wtyczka może pokazywać nazwę adaptera, która nie opisuje protokołu pod spodem. Dokumentacja bieżącego wydania nie opisuje kompilacji działającej na maszynie przed tobą. Przeczytaj stronę dla konkretnej wersji, a potem porównaj ją z tym, co klient podaje o sobie.

W Windows typ tunelu pochodzi z platformy, a nie z interfejsu graficznego, więc pytaj platformy. Get-VpnConnection -Name 'Work' | Select-Object TunnelType, ServerAddress pokazuje Sstp, gdy natywny klient spróbuje protokołu, a dokumentacja typów połączeń wymienia go wśród wbudowanych typów tunelu. W Linuksie nie ma w ogóle natywnego klienta SSTP, więc pytanie brzmi, czy osobna implementacja, taka jak sstpc z pakietu sstp-client, jest zainstalowana i aktualna.

Przeczytaj format profilu przed etykietą

Profile nie są wymienne, a plik, który ci przekazano, zwykle rozstrzyga sprawę szybciej niż jakakolwiek lista funkcji. Dyrektywy OpenVPN, klucze WireGuard i ustawienia połączenia SSTP opisują trzy niepowiązane protokoły i żadne okno importu nie zamienia jednego w drugi. Wspólny port TCP 443 niczego nie tłumaczy, bo SSTP, OpenVPN po TLS i zwykła usługa HTTPS mogą zajmować ten sam port i nie mieć nic wspólnego ponad nim.

Jeśli plik jest .ovpn albo konfiguracją WireGuard, odpowiedź jest już jasna: ten klient nie ma mówić SSTP. Import do klienta obsługującego wyłącznie SSTP kończy się niepowodzeniem już na etapie profilu, długo przed rozpoczęciem jakichkolwiek negocjacji protokołu.

Czego TLS nie dowodzi o wdrożeniu

Zakończony uścisk dłoni TLS dowodzi, że serwer ma certyfikat, i nie dowodzi niczego o tym, czy klient ufa łańcuchowi wystawcy albo czy zgadza się wpisana w nim nazwa. Walidacja musi się powieść wobec zamierzonego serwera, łącznie z każdym prywatnym CA prowadzonym przez organizację, a klient oferujący pomijanie błędów certyfikatu usunął kontrolę zamiast zyskać obsługę protokołu. Walidacja łańcucha i zgodność nazwy to dwa osobne testy, a stos, który przechodzi jeden, może zawieść na drugim. Oba należą do kryteriów akceptacji, nie do aneksu rozwiązywania problemów.

Następnie potwierdź metodę uwierzytelniania PPP, bo wdrożenie z EAP-TLS potrzebuje klienta, który potrafi przedstawić certyfikat wewnątrz PPP, a metoda oparta na haśle wymaga obsługi tej wymiany. Adres serwera i hasło nie opisują rzeczywistego wymagania organizacji, zwłaszcza gdy stoi przed nim drugi czynnik lub kontrola urządzenia. Zapytaj, którą metodę wymusza serwer, zanim uznasz, że klient ją spełni.

Śledź sesję przez cztery etapy

Obserwuj, jak połączenie przekracza cztery granice: TCP i TLS do serwera, wymiana kontrolna SSTP, negocjacja PPP, a potem zasób, którego naprawdę potrzebujesz. Dziennik, który zatrzymuje się po TLS, opisuje inną usterkę niż ten, który zatrzymuje się wewnątrz PPP, a oba prowadzą do różnych właścicieli. Załadowanie przez przeglądarkę strony hosta dowodzi tylko, że coś odpowiedziało na 443, co jest najczęstszym fałszywym wynikiem pozytywnym w tej dziedzinie. Jeśli ta strona się ładuje, a klient wciąż zawodzi, problem leży powyżej TLS i serwer WWW nie jest podejrzanym.

Zakończ prawdziwym prywatnym zasobem i wyszukaniem nazwy, bo sesja, która się zestawia i nic nie przenosi, wygląda w większości okien stanu tak samo jak działająca. Jedno udane żądanie do potrzebnego zasobu rozstrzyga pytanie, na które ikona nie odpowie.

Gdy brakuje obsługi, zmień plan

Jeśli klient nie potrafi mówić SSTP, zdobądź zatwierdzoną alternatywę albo poproś właściciela serwera o protokół obsługiwany przez obie strony. Usuwanie nierozpoznanych opcji, aż import się uda, daje profil, który z niczym się nie łączy, a to wolniejsza droga do tego samego ślepego zaułka. Instalator z nieznanego źródła reklamujący uniwersalną zgodność dodaje do maszyny niezatwierdzoną ścieżkę zaufania i często zastępuje klienta platformy czymś, czego organizacja nie może zaktualizować. Żaden z tych ruchów nie jest naprawą i oba trudniej cofnąć niż pierwotny problem.

Traktuj kwestię zgodności osobno od wydajności i wyboru punktu końcowego, bo bliski serwer jest bezużyteczny, gdy klient nie potrafi mówić jego protokołem. Strojenie opóźnień nie naprawia etapu, który nigdy się nie kończy.