Port 443 odpowiada, SSTP nadal zawodzi: który etap się zepsuł?

Ukończenie uścisku dłoni TCP do portu 443, podczas gdy tunel nigdy się nie buduje, dowodzi jednej rzeczy, i jest to mała rzecz. Coś nasłuchuje i jest gotowe przyjąć połączenie pod tym adresem. Nie identyfikuje to usługi, certyfikatu, który zostanie przedstawiony, ani tego, co dzieje się po pierwszych bajtach.

Między tym uściskiem dłoni a działającym tunelem są cztery etapy, a każdy generuje inny błąd.

Otwarty port opisuje tylko jedną warstwę

Przyjęcie połączenia TCP oznacza, że proces posiada gniazdo, a ścieżka pozwala na uścisk dłoni. Nie mówi nic o tym, czy ten proces jest serwerem SSTP, czy ma certyfikat ważny dla nazwy w Twoim profilu ani czy autoryzuje Twoje konto. Serwer WWW pod tym samym adresem bezbłędnie odpowiada na uścisk dłoni, a następnie odpowiada na Twoje żądanie SSTP błędem HTTP. Wszystko powyżej tego uścisku dłoni pozostaje niesprawdzone.

Traktuj test portu jako najtańszy możliwy filtr, a nie jako werdykt. Jego wartość polega na tym, że usuwa całą kategorię awarii, a nie na tym, że potwierdza wszystko powyżej.

Mylenie tych dwóch rzeczy jest powodem, dla którego ludzie przeinstalowują klientów po teście, który nigdy nie zbadał rzeczywistego problemu klienta.

Rozdziel cztery etapy dowodami

Etapy to osiągalność transportu, walidacja TLS, wymiana SSTP przez HTTPS i uwierzytelnianie PPP wewnątrz tunelu. Ścieżka, która przechodzi pierwszy etap i zawodzi na czwartym, wymaga poprawy danych logowania; ta, która zawodzi na drugim, wymaga poprawy certyfikatu lub nazwy. Te naprawy nie mają nic wspólnego, a wybór niewłaściwej marnuje awarię.

nc -vz vpn.example.net 443
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
curl -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/

Trzecie polecenie warto przeczytać uważnie. 200 ze zwykłej strony internetowej mówi, że istnieje usługa WWW; nie mówi, że żądanie SSTP zostanie zrozumiane. 404 z tego samego adresu jest równie nieinformacyjne w kwestii VPN. Tylko dziennik klienta mówi, który z czterech etapów został osiągnięty.

Zwróć uwagę, jakiej nazwy użyło każde polecenie. Certyfikat jest wybierany na podstawie nazwy, którą wysyłasz, więc niezgodność między profilem a testem jest niezgodnością, którą sam wprowadziłeś. Zapisanie tej nazwy obok wyniku zapobiega późniejszemu zamieszaniu.

Czytaj częściowy sukces we właściwym kierunku

Pośrednik może zezwalać na zwykłe przeglądanie i odmawiać późniejszej wymiany, dlatego proxy działające dla stron internetowych może nadal zawodzić dla tunelu. Ten sam wzorzec pojawia się, gdy certyfikat jest ważny dla nazwy przeglądarki, ale nie dla nazwy skonfigurowanej w profilu: przeglądarka jest zadowolona, a klient nie, i oba mają rację co do tego, co sprawdziły.

Podczas diagnozowania pozostaw walidację serwera włączoną. Wyłączenie jej zamienia niezgodność certyfikatu w udany uścisk dłoni i ukrywa jedyny dowód, który wyjaśniłby awarię.

Jeśli ten sam profil działa z innej sieci, różnica zależy od ścieżki. To zawęża poszukiwania do pośredników, nie mówiąc którego, i nadal jest użytecznym krokiem naprzód. Zapisz używaną sieć, ponieważ porównanie jest bezwartościowe bez niej.

Następnie przetestuj aplikację, nie tylko sesję

Gdy sesja istnieje, zweryfikuj zamierzoną trasę, rozwiązywanie nazw i uprawnienia usługi od klienta, który ich potrzebuje. Połączony tunel może nadal mieć brakujące przekazywanie po drugiej stronie lub trasę powrotną, która nigdy nie istniała, a te awarie wyglądają dla czekającej osoby dokładnie jak problem aplikacji.

Trzymaj każdy wniosek powiązany z etapem, który go wytworzył. Nazywanie otwartego portu działającym VPN to sposób, w jaki pięciominutowa kontrola certyfikatu staje się dniem reinstalacji oprogramowania.