Dlaczego profil OpenVPN działa w domu, ale zawodzi w hotelu

Biurowe Wi-Fi i pokój hotelowy mogą dać temu samemu laptopowi dwie bardzo różne sieci, a profil pomiędzy nimi nic o tym nie wie. To, co działa w domu, zakłada ustępliwe łącze nadrzędne, działające rozwiązywanie nazw i lokalną podsieć, która nie koliduje z niczym, co niesie tunel. Każde z tych założeń może zawieść osobno.

Użyteczny sposób debugowania to potraktowanie sieci jako czterech osobnych faktów, a następnie sprawdzenie ich po kolei. Zgadywanie przy profilu na początku zwykle daje zmianę, która niczego nie naprawia i zaciemnia dowody.

Cztery fakty sieciowe zmieniają się między lokalizacjami

Pierwszy fakt to, czy sieć lokalna w ogóle wypuszcza cię na zewnątrz. Portal logowania wpuszcza urządzenie na stronę logowania i blokuje wszystko inne, dopóki ta strona nie zostanie ukończona, co oznacza, że tunel nie może się rozpocząć, niezależnie od tego, jak poprawny jest profil.

Drugi to rozwiązywanie nazw. Portal przechwytujący DNS odpowiada na każde zapytanie własnym adresem, więc nazwa hosta VPN rozwiązuje się na portal, a klient próbuje zbudować tunel do strony internetowej.

Trzeci to filtrowanie transportu. Sieci, które chcą zezwalać tylko na przeglądanie, przepuszczają TCP 443 do dowolnych miejsc docelowych i odrzucają prawie wszystko inne, łącznie z UDP.

Czwarty to adresowanie. Lokalna podsieć może nakładać się na sieć za tunelem albo łącze nadrzędne może w ogóle nie zapewniać użytecznej trasy IPv4.

Rozwiązywanie nazw i portal logowania

Zastąp nazwę hosta w profilu numerycznym adresem serwera i spróbuj ponownie. Jeśli IP się łączy, a nazwa nie, winne jest rozwiązywanie nazw, a sam profil jest w porządku.

Otwórz przeglądarkę i spróbuj otworzyć zwykłą stronę HTTP, zanim dotkniesz VPN. Przekierowanie na stronę logowania oznacza, że portal wciąż czeka; ukończ go, a potem połącz się ponownie. Wiele hoteli po kilku godzinach kończy też sesję, co wygląda jak przerwa w środku dnia, a nie problem z logowaniem.

Jeśli numeryczny adres też zawodzi, rozwiązywanie nazw nie jest wyjaśnieniem, więc przejdź do transportu. Zachowaj adres, który testowałeś, bo mówi on następnemu sprawdzeniu, czy pakiety w ogóle opuściły maszynę.

Filtrowanie transportu: najpierw UDP, TCP 443 jako zapas

Przepływ OpenVPN przez UDP 1194 nie wygląda jak nic, co rozpozna hotelowy firewall, więc jest odrzucany bez błędu. Klient ponawia próby, aż upłynie jego limit czasu, a użytkownik widzi połączenie, które nigdy się nie nawiązuje, zamiast odmowy. Zapory, które tak się zachowują, rzadko logują odrzucenie w miejscu, które możesz zobaczyć. Brak odmowy sam w sobie jest wskazówką.

TCP 443 to niezawodny zapas, ponieważ sieć nie potrafi odróżnić go od zwykłego HTTPS. Użyj profilu TCP operatora, jeśli istnieje, bo serwer też musi nasłuchiwać na tym transporcie i porcie; zmiana tylko klienta daje inny rodzaj awarii. Jeśli nie ma profilu TCP, zapytaj operatora, zamiast wymyślać go przez edycję portu. Strona serwera też musi się zgodzić, a niezgodność znowu wygląda jak problem z firewallem.

Spodziewaj się kosztu wydajności. TCP w TCP wzmacnia retransmisje na łączu z utratami, więc działający tunel TCP może nadal wydawać się wolny w zatłoczonej sieci hotelowej. To wymiana za osiągalność, a nie usterka, której trzeba gonić.

Kolizje adresów i łącza nadrzędne bez IPv4

Tunel może się nawiązać i mimo to niczego nie przenosić. Gdy lokalna sieć LAN i sieć zdalna dzielą prefiks taki jak 192.168.1.0/24, klient uznaje zdalny host za połączony bezpośrednio i wysyła pakiet do łącza lokalnego zamiast do tunelu. Objawem jest udane połączenie z jedną nieosiągalną podsiecią, co łatwo błędnie odczytać jako problem z trasą po stronie serwera.

Trwałym rozwiązaniem jest przeniesienie zdalnej sieci LAN do nietypowego zakresu prywatnego. Wybór zakresu, którego nikt nie używa w domu, na przykład 10.42.0.0/24, zapobiega problemowi w każdej przyszłej lokalizacji, a nie tylko w jednej. Lokalnym obejściem jest unikanie tego hotelu, hotspotu lub routera, co wcale nie jest rozwiązaniem.

Mobilne łącza nadrzędne dodają dwa warianty. NAT na poziomie operatora oznacza, że połączenia przychodzące nie docierają, co ma znaczenie, jeśli hostujesz serwer, ale nie dla klienta wychodzącego. APN skonfigurowany tylko z IPv6 i tłumaczeniem NAT64 może spowodować awarię klienta, który nalega na prawdziwą ścieżkę IPv4, a zwykłym lekarstwem jest zmiana protokołu APN na IPv4 lub podwójny stos.

Objawy po podniesieniu tunelu

Tunel, który łączy się, a potem milknie, to zwykle problem z keepalive lub MTU, a nie zablokowany port. Połączenie, które spada po ustalonej liczbie minut, wskazuje na timer keepalive lub renegocjacji. Ustaw klienta tak, aby sondował partnera i restartował się, gdy odpowiedzi ustaną, i przetestuj mniejszy MTU tunelu, jeśli pingi przechodzą, a duże transfery się zatrzymują.

Zanim poprosisz o pomoc, zapisz trzy rzeczy: adres, którego próbowałeś, i czy odpowiedział, transport i port, których użyłeś, oraz lokalną podsieć sieci, która zawiodła. Razem oddzielają rozwiązywanie nazw od filtrowania transportu i od kolizji adresów, a to są przyczyny, które przetrwają zetknięcie z dowodami.