OpenVPN na 443 nadal zablokowany? Sprawdź, co inspekcjonuje sieć

Tunel łączy się z linii domowej i zatrzymuje w sieci hotelowej lub biurowej, a przeniesienie serwera na port 443 niczego nie zmieniło. Ten wynik jest dość częsty, by mieć kształt: port był łatwą częścią, a reszta decyzji należy do wszystkiego, co siedzi między klientem a serwerem. Dwa pytania rozstrzygają większość przypadków i żadne z nich nie dotyczy szyfrów. Czy sieć przyjmuje uścisk dłoni TLS na ten adres, i czy klient utrzymuje trasę do własnej otoczki, dopóki tunel jest podniesiony?

Uścisk dłoni zdradza więcej niż numer

Rodzimy nasłuch VPN na TCP 443 mówi własnym protokołem już od pierwszego pakietu. ClientHello ma pole wersji, wartość losową i listę rozszerzeń, a urządzenie, które przeczyta kilkaset bajtów, rozpozna różnicę bez niczego odszyfrowywania. Numery portów są tanie do spełnienia, a to kształt protokołu jest tym, co filtr naprawdę sprawdza. Reguły zwykle pisze się też per protokół, więc polityka inspekcjonująca TLS nie mówi nic o UDP.

Przezroczysty serwer pośredniczący, który wymaga ważnej sesji TLS, zrywa połączenie podczas konfiguracji, często po zakończeniu uścisku dłoni TCP. Ten szczegół ma znaczenie później, bo oznacza, że log klienta urywa się po ustanowieniu gniazda.

Otaczanie strumienia tworzy dwa punkty awarii

Otoczka TLS, taka jak stunnel, przywraca oczekiwany kształt: klient łączy się z lokalnym nasłuchem, otoczka otwiera prawdziwą sesję TLS do serwera na 443, a druga otoczka na serwerze przekazuje odszyfrowane bajty do demona VPN. Zewnętrzna sesja wygląda teraz jak każde inne połączenie HTTPS. Demon VPN na serwerze powinien nasłuchiwać tylko na loopbacku, bo nic poza otoczką nie musi do niego dotrzeć.

Trzy osobne rzeczy muszą się zgadzać w tym układzie. Profil klienta wskazuje lokalny nasłuch, certyfikat serwera pasuje do nazwy, którą klient weryfikuje, a przekierowanie po stronie serwera celuje w port, którego demon naprawdę używa. Pomyłka w którejkolwiek z nich i połączenie ginie, zanim dotrze do warstwy VPN. Niezgodność certyfikatu objawia się wtedy jako błąd otoczki, a nie jako błąd VPN, i dlatego warto czytać oba logi obok siebie.

Trasa do otoczki jest pułapką

Gdy tunel się podniesie, trasa domyślna wskazuje do niego, a zewnętrzna sesja TLS potrzebuje drogi, która nie wchodzi w tunel, który niesie. Zwykły klient VPN chroni adres, na który dzwoni; klient w otoczce dzwoni na własny loopback, więc adres docelowy otoczki jest niewidoczny dla tej ochrony.

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

Dokładne adresy wpisujesz sam, a trasa musi istnieć przez cały czas życia połączenia, nie tylko przy starcie. Mały skrypt otoczki, który dodaje trasę przed klientem i usuwa ją potem, jest pewniejszy niż zapamiętane polecenie.

W Androidzie odpowiednikiem tego wyjątku jest ustawienie dla każdej aplikacji: wyklucz aplikację otoczki z tunelu, aby jej własny ruch wychodził przez połączenie mobilne. Bez wykluczenia otoczka jest kierowana do tunelu, który próbuje zbudować, a pętla ponownego łączenia wygląda jak problem serwera.

Przeczytaj czasy, zanim cokolwiek zmienisz

Sesja, która umiera po tym samym interwale za każdym razem, jest podpisem polityki, a nie awarią kryptograficzną, a długotrwałe limity przepływu dają dokładnie taki wzorzec. Połączenie resetowane zaraz po uścisku dłoni sugeruje serwer pośredniczący, któremu nie spodobał się łańcuch certyfikatów.

Porównaj wystawcę certyfikatu zwykłej strony HTTPS z obu sieci. Jeśli w sieci ograniczonej wystawca jest inny, coś kończy TLS w środku, i żadna otoczka nie przetrwa tego przechwycenia bez zmian. To samo porównanie powie ci, czy blokada celuje w nazwę twojego serwera, czy w każdą sesję TLS na tym adresie.

Zapisz zaobserwowane zachowanie: jak długo trwała sesja, czy gniazdo się otworzyło, czy otoczka zapisała uścisk dłoni. Każdy z tych punktów zawęża następny test.

Testuj jedną zmienną naraz

Najpierw sprawdź UDP, bo niektóre sieci odrzucają je całkowicie, a awaria UDP nic nie mówi o 443. Potem spróbuj TCP 443 bez otoczki, następnie otoczki na 443. Czytaj log klienta na każdym kroku i zatrzymaj się, gdy tylko zachowanie się zmieni.

Zmieniaj jeden element na próbę. Nowy port, nowa otoczka i nowy szyfr w tym samym przebiegu nie pozwolą ci powiedzieć, który z trzech się liczył.