OpenVPN nie łączy się z Wi-Fi w hotelu? Spróbuj TCP 443

Otwórz klienta, naciśnij Połącz i czytaj wiersz stanu zamiast okna, które pojawia się potem. Profil, który po sieci hotelowej, kampusowej lub komórkowej zatrzymuje się na Łączenie lub Oczekiwanie na serwer, zwykle gdzieś po drodze utracił transport, a nie dane logowania. Następnym pożytecznym krokiem jest ustalenie, co ta sieć przenosi, zanim dotkniesz serwera. Nie zmieniaj niczego, dopóki ten sam profil nie zadziała gdzie indziej.

Najpierw przetestuj z hotspota telefonu. Jeśli tunel tam wstanie, serwer, certyfikat i konto są w porządku, a jedyną zmienną, która została, jest sieć przed tobą.

Zacznij od klienta: przeczytaj wiersz stanu

Wiersz stanu mówi, który etap zawiódł. Klient utknięty na Łączenie wciąż rozwiązuje nazwę hosta albo otwiera zewnętrzne gniazdo; ten, który dociera do Oczekiwanie na serwer, ma ścieżkę, ale nie ma odpowiedzi; ten, który uwierzytelnia się i potem odpada, ma zupełnie inny problem. Dziennik klienta i własne pola remote oraz proto profilu pokazują, co klient próbuje zrobić, a --verb 4 w kliencie z wiersza poleceń drukuje ten sam szczegół. To właśnie porównanie z siecią przed tobą zamienia 'VPN jest zablokowany' w konkretne twierdzenie.

Następnie sprawdź sieć narzędziami, które już masz. nc -vzu 203.0.113.10 1194 wysyła datagram UDP, curl -v telnet://203.0.113.10:443 informuje, czy uścisk TCP się kończy, a przeglądarka ładująca stronę HTTPS dowodzi tylko, że wychodzący 443 dociera do tego jednego hosta. Małe sondy odpowiadają na to, czego klient VPN nie potrafi: który port i który protokół w ogóle opuszczają tę sieć.

Trzy zachowania sieci wyglądają z klienta tak samo i wymagają różnych odpowiedzi. Wychodzący 443 może być otwarty, może być dozwolone tylko proxy, albo 443 może być przezroczyście przekazywany do skrzynki inspekcyjnej, która nie potrafi odczytać, co przenosi. Pierwsze naprawia zmiana profilu poniżej, drugie ustawienia proxy, a trzecie może ukończyć uścisk i potem stanąć, gdy inspektor uzna, że nie lubi strumienia. Wiedza, z którym z trzech masz do czynienia, to różnica między zmianą na dziesięć minut a popołudniem reinstalowania klientów.

Przenieś nasłuch i profil razem

Po stronie serwera ustaw nasłuch na to, co sieć dopuszcza: port 443 i proto tcp w konfiguracji serwera, potem uruchom usługę ponownie i potwierdź gniazdo przez ss -lntp. Po stronie klienta profil musi się zgodzić, bo transport i port leżą poza tunelem: proto tcp i port 443 w .ovpn albo odpowiednie pola na ekranie ustawień aplikacji. Profil wciąż skierowany na UDP 1194 zawodzi dokładnie jak wcześniej, a pokusa każe obwiniać zaporę, która już została naprawiona. Jeśli ten sam host odpowiada też przez HTTPS na 443, dwa nasłuchy nie mogą dzielić tego adresu i protokołu; daj VPN-owi drugi adres albo postaw przed nim demultiplekser.

Obserwuj pierwsze połączenie przez tcpdump -ni any port 443 po obu stronach. Pakiety, które opuszczają klienta i nigdy nie docierają, oznaczają, że sieć jednak filtruje, albo że adres w profilu nie jest tym, który zakładasz. Pakiety, które docierają bez odpowiedzi, odsyłają cię do dziennika serwera, gdzie niezgodność protokołu natychmiast objawia się jako odrzucony pakiet.

Gdy z sieci wychodzi tylko proxy

Niektóre sieci gościnne nie pozwalają na nic poza proxy HTTP, co jest innym ograniczeniem niż zamknięty port i wyklucza więcej niż OpenVPN. Klienci mówiący wyłącznie PPTP, L2TP/IPsec albo gołym IPsec nie mają tam drogi, bo te konstrukcje oczekują, że ich zewnętrzny protokół dotrze do serwera bezpośrednio. OpenVPN potrafi, z http-proxy proxy.example.net 8080 w profilu klienta, o ile proxy zezwala na metodę CONNECT na twój port. Proxy SOCKS jest jeszcze łatwiejsze, bo przekazuje strumień bez troski o to, co jest w środku.

Tam, gdzie klient nie ma obsługi proxy, zwykle zostaje tunel SSH przez 443. Dokłada drugą warstwę, a operator sieci może mieć coś do powiedzenia, więc traktuj go jako mostek na jedną podróż, a nie jako architekturę.

Wyceń rozwiązanie awaryjne, zanim je zostawisz

TCP w TCP ma znany koszt. Gdy zewnętrzne połączenie jest TCP, a ładunek też jest TCP, utracony segment wywołuje retransmisję na obu warstwach, a wewnętrzne połączenie cofa się przed stratą, której nie widzi. Przeglądanie to znosi; sesje interaktywne i rozmowy to odczuwają. Zostaw nasłuch TCP 443 jako rozwiązanie awaryjne dla sieci, które go wymagają, a UDP pozostaw domyślnym dla wszystkiego, co jeszcze go przepuszcza.

Zapisz wybór w nazwie profilu i w notatkach pomocy technicznej: który port, który protokół i która sieć go wymusiła. Potem zapytaj administratora sieci, czy ten port pozostanie otwarty po następnej wymianie sprzętu, bo rozwiązanie awaryjne, które po cichu znika, jest gorsze niż brak jakiegokolwiek.