SSTP kontra OpenVPN: ten sam port 443, inny protokół

Obie opcje mogą stać za TCP 443, więc ludzie zakładają, że to wymienne punkty końcowe. Nie są: SSTP serwer mówi PPP wewnątrz HTTPS, podczas gdy serwer OpenVPN mówi własnym protokołem po TLS lub przez surowy strumień UDP. Skierowanie jednego klienta na port drugiego daje połączenie, które nigdy nie dociera do zachęty logowania. Wybór dotyczy tego, jakiego klienta i transportu możesz obsłużyć, a nie numeru.

Wspólny port nie tworzy wspólnego protokołu

Uścisk dłoni TLS może się zakończyć i mimo to donikąd nie prowadzić, bo potem klient i serwer nie zgadzają się co do tego, co powiedzieć dalej. W przechwycie pakietów widać czysty uścisk dłoni, po którym następują dane aplikacji odrzucane lub ignorowane przez drugą stronę. Ten wzorzec jest sygnaturą niezgodności protokołów, a nie blokadą zapory sieciowej.

Ani przemianowany profil, ani inna pozycja menu nie zamienia jednego w drugie. Połączenie SSTP tworzy się w ustawieniach VPN systemu Windows z adresem serwera i danymi uwierzytelniania operatora, natomiast połączenie OpenVPN wymaga klienta i odpowiedniego pliku konfiguracyjnego. Specyfikacja SSTP firmy Microsoft opisuje to pierwsze i nie opisuje uścisku dłoni OpenVPN.

Port 443 to wygoda polityki. Przechodzi przez sieci, które pozwalają na niewiele innego, i to jest realna zaleta, ale nie mówi nic o tym, jaki protokół działa za nim.

SSTP tuneluje PPP wewnątrz HTTPS

Nazwa opisuje konstrukcję: ramki PPP przenoszone w sesji HTTPS, czyli TLS pod spodem i certyfikat, który klient może sprawdzić. Windows zawiera to jako natywny typ VPN, więc zarządzany laptop często może się połączyć bez dodatkowego oprogramowania poza profilem dostarczonym przez operatora.

Inne platformy to inna historia. Klient Linuksa lub macOS wymaga utrzymywanej implementacji, a one różnią się tym, co obsługują i jak zgłaszają błędy. Sprawdź klienta, którego naprawdę zamierzasz używać, zamiast zakładać, że wbudowana możliwość Windows się przeniesie, i potwierdź, że nazwa serwera w profilu odpowiada certyfikatowi przedstawianemu przez serwer.

SSTP jest zwykle tylko TCP. Ten jeden transport wpływa na zachowanie przy stratach, ponieważ retransmisja odbywa się zarówno wewnątrz tunelu, jak i pod nim.

OpenVPN przynosi własnego klienta i wybór transportu

OpenVPN dostarcza własnego klienta i profil, co daje diagnostykę, której natywne okno Windows nie pokazuje. Serwer może nasłuchiwać na UDP lub TCP, a konfiguracja operatora decyduje, którego musi użyć twój klient. Profil wskazujący zły transport zawodzi przed uwierzytelnieniem.

Uwierzytelnianie jest równie zależne od konfiguracji. Wdrożenie może wymagać tylko certyfikatów, certyfikatów oraz nazwy użytkownika i hasła, albo drugiego czynnika dodatkowo, a klient musi dokładnie odpowiadać temu układowi. To, że połączenie dociera do etapu TLS, nie mówi, jakich danych logowania zażąda następnie.

UDP jest zwykłym domyślnym wyborem, bo pozwala uniknąć zagnieżdżania niezawodnego strumienia w innym niezawodnym strumieniu. Tryb TCP istnieje dla sieci blokujących UDP i działa, ale duże straty mogą sprawić, że będzie odczuwany gorzej niż ścieżka UDP, którą zastąpił. Wybieraj TCP, gdy musisz, a nie dlatego, że brzmi bardziej niezawodnie.

Wybieraj według klienta, transportu i wsparcia

Trzy pytania rozstrzygają większość tych decyzji. Czy każde urządzenie klienckie potrzebuje połączenia działającego bez dodatkowego oprogramowania? Czy sieć, od której zależysz, dopuszcza UDP, czy TCP 443 jest jedynym wyjściem? I kto wspiera klienta, jego aktualizacje oraz odzyskiwanie po wygaśnięciu profilu?

Porównując oba, testuj na tym samym urządzeniu i w tej samej sieci dostępowej. Jeśli punkt końcowy SSTP i punkt końcowy OpenVPN to różne serwery lub różne lokalizacje, twój wynik obejmuje te trasy i maszyny zamiast izolować protokół. To najczęstszy sposób, w jaki takie porównania dają pewną, ale błędną odpowiedź.

Następnie potwierdź, które z nich faktycznie nawiązałeś, zanim zaczniesz cokolwiek innego debugować:

> Get-VpnConnection -Name "Office SSTP" | Select-Object TunnelType, ServerAddress
> openvpn --config office.ovpn --verb 4

Tak czy inaczej, zakończ testem zasobu i DNS, których potrzebujesz, zamiast ogłaszać sukces na podstawie stanu tunelu. Oba protokoły można skonfigurować tak, aby przenosiły tylko wybrany ruch prywatny, a połączony tunel bez działającego rozwiązywania nazw wygląda jak zepsute VPN, choć w rzeczywistości jest projektem tunelu dzielonego lub DNS.

W zarządzanej flocie dystrybucja profili i wsparcie aktualizacji zwykle rozstrzygają tę kwestię znacznie wcześniej niż jakikolwiek pomiar transportu.