VPN zablokowany w sieci tylko web? Przejdź warstwy

Sieć kampusowa lub hotelowa, w której przeglądarka działa, a każdy tunel umiera, to nie jeden problem, lecz cztery warstwy. Ścieżka może dopuszczać tylko TCP 443, wymagać uwierzytelnionego proxy, sprawdzać handshake albo po prostu zakazywać dostępu zdalnego polityką. Przejście ich po kolei pozwala nie kupować nowego klienta, żeby naprawić regułę sieci. Poniższa instrukcja zajmuje około dziesięciu minut i kończy się pisemną odpowiedzią, która warstwa cię odrzuciła.

Udowodnij, która warstwa odrzuca połączenie

Nie zaczynaj od klienta VPN. Zacznij od zwykłego żądania HTTPS do tego samego hosta i czytaj fazy czasu, bo faza, która zawodzi, mówi, które urządzenie jest odpowiedzialne:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

Brak odpowiedzi i brak czasu connect oznacza, że TCP nigdy się nie zakończył, więc w grze jest zapora, wymóg proxy lub zły cel. Czas connect bez czasu tls oznacza, że coś pośrodku przyjęło połączenie i zatrzymało handshake, a tak wygląda proxy inspekcjonujące z perspektywy klienta.

Teraz sprawdź certyfikat, który faktycznie otrzymujesz. To najszybszy sposób, by dowiedzieć się, czy rozmawiasz z serwerem, czy ze skrzynką pośrednią, która ponownie podpisała sesję:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

Przeczytaj wiersz wystawcy. Twoje własne CA oznacza, że dotarłeś do usługi; wystawca firmowy lub urządzenia oznacza, że filtr zakończył połączenie i decyduje, co będzie dalej. Zapisz oba wyjścia ze znacznikiem czasu, bo ten sam test godzinę później w sieci gości może dać inną odpowiedź.

Klient świadomy proxy zmienia pierwszy pakiet, nie politykę

Jeśli sieć wymaga CONNECT przez uwierzytelnione proxy, trzeba to powiedzieć klientowi VPN, inaczej spróbuje otworzyć gniazdo na adres, którego nie potrafi trasować. Przetestuj proxy osobno od klienta, żeby awaria miała jedno wyjaśnienie:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

Pierwsze polecenie dowodzi, że proxy przeniesie cel. Drugie każe klientowi użyć TCP na 443, jedynego transportu, który większość ścieżek tylko web w ogóle przepuszcza. Jeśli pierwsze się udaje, a drugie nadal zawodzi, proxy nie jest przeszkodą.

Niektóre klienty czytają proxy systemu operacyjnego zamiast nadpisania, a niektóre nie czytają żadnego. Sprawdź dokumentację aplikacji, zanim uznasz, że ustawienie systemowe obowiązuje. Klient, który rozwiązuje punkt końcowy przez resolver, którego proxy nie obsługuje, też tu zawiedzie, i dlatego zmiana DNS może wyglądać jak poprawka, gdy jest tylko objazdem.

Zwróć też uwagę na wzorzec sterowania. Filtrowana sieć może odpowiedzieć na nazwę hosta wykrywania dostawcy czymś własnym, co zmienia, który profil proxy wybiera klient. Nie buduj procesu wokół tej osobliwości. Różni się w zależności od miejsca, zmienia się bez zapowiedzi i nie jest czymś, co możesz wspierać dla kogoś innego.

Port 443 jest osiągalny, nie dozwolony

Opakowanie tunelu w TLS na 443 rozwiązuje osiągalność i nic więcej. Filtr sprawdzający port go przepuści; filtr pobierający odcisk handshake nie, a zaszyfrowane client hello ukrywa nazwę serwera tylko wtedy, gdy obsługują to oba końce. Uruchom test i dowiedz się, za jakim filtrem jesteś, zamiast mieć nadzieję.

Jest też koszt wydajności, który ludzie odkrywają później. Niezawodny transport w niezawodnym transporcie wzmacnia straty, bo wewnętrzny stos ponownie wysyła segmenty, które zewnętrzny już ponownie wysłał. Na czystym łączu nikt tego nie zauważa. W zatłoczonej kampusowej sieci bezprzewodowej tunel staje się bezużyteczny dokładnie wtedy, gdy go potrzebujesz, a wykres wygląda jak utrata pakietów, choć nic nie jest celowo odrzucane.

UDP jest zwykle pierwszą ofiarą, i warto to potwierdzić, a nie zgadywać. Jeśli WireGuard lub domyślny OpenVPN nigdy nie kończy handshake, podczas gdy TCP 443 działa, sieć odrzuca UDP, i żadne odtwarzanie kluczy tego nie zmieni:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

Pusty znacznik czasu handshake obok peera, który wczoraj działał, to odpowiedź UDP. Dwa zapytania DNS odpowiadają na inne pytanie: jeśli lokalny resolver i publiczny resolver nie zgadzają się co do adresu punktu końcowego, jesteś sterowany, a argument o transporcie jest niewłaściwy.

Sprawdź, co naprawdę opuściło maszynę

Logi klienta opisują, w co wierzy klient. Przechwycenie opisuje, co widziała sieć, i różnica między nimi jest miejscem, w którym rozwiązuje się większość takich przypadków:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

Jeśli widzisz pakiety SYN i brak SYN-ACK, blokada jest wyżej, a klient jest niewinny. Jeśli widzisz ukończony handshake do adresu, który nie jest adresem serwera, rozmawiasz z proxy lub przechwytywaczem. Jeśli nie widzisz nic, sprawdź, czy przechwytywałeś na właściwym interfejsie, zanim cokolwiek wywnioskujesz.

Lista gniazd łapie subtelniejszy przypadek: drugi tunel, który już trzyma trasę domyślną. Dwa klienty walczące o tablicę routingu dają okresowe awarie, które wyglądają dokładnie jak zablokowana sieć, a przechwycenie pokaże ruch wychodzący przez interfejs, którego się nie spodziewałeś.

Wycofanie i notatka, którą warto zachować

Cofnij zmiany w odwrotnej kolejności do tej, w jakiej je wprowadziłeś. Usuń zmienne proxy, zatrzymaj klienta uruchomionego ręcznie i usuń każde nadpisanie trasy lub resolvera, które dodałeś:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

Pozostawienie ręcznie uruchomionego klienta w działaniu to sposób, w jaki laptop kończy z zepsutą siecią przy następnej wizycie w biurze. Zmienne proxy zostawione w profilu powłoki psują niezwiązane narzędzia tygodnie później, a osoba, która je debuguje, nie połączy tych dwóch zdarzeń.

Potem napisz cztery linijki: sieć, znacznik czasu, faza, która zawiodła, i widziany wystawca. Ścieżka, która działa na jednym kampusie i zawodzi na następnym, jest normalna, a następna osoba musi wiedzieć, czy różnicą było proxy, resolver czy filtr. Jeśli odpowiedź brzmi, że sieć zabrania dostępu zdalnego, zatrzymaj się tam i poproś administratora o wspieraną trasę, zamiast wnosić obejście do polityki, której nie przeczytałeś.