Wi-Fi w hotelu: VPN zawodzi, zanim dotrze do serwera

Klient VPN kręci się, potem zgłasza, że nie może dotrzeć do serwera, i wszyscy wnioskują, że hotel blokuje VPN. Zwykle nie stało się nic tak dramatycznego: sieć jeszcze cię nie wypuściła. Portal przechwytujący wstrzymuje każde połączenie, dopóki się nie zalogujesz, a tunel nie może powstać, gdy strona logowania przechwytuje jego pakiety. Przejdź logowanie, zanim obwinisz tunel.

Mit: hotel blokuje VPN

Większość sieci hotelowych nie filtruje tuneli w szczególny sposób. Przechwytują ruch webowy, dopóki gość się nie uwierzytelni, a mogą też ograniczać liczbę urządzeń, kończyć sesje lub dławić przepustowość. Każde z tych zjawisk daje awarię, która z wnętrza klienta VPN wygląda jak blokada.

Tunel jest tu złym narzędziem diagnostycznym, bo to jedyna aplikacja, która na pewno zawiedzie, dopóki portal nie jest autoryzowany. Zwykły dostęp do sieci jest lepszym wskaźnikiem, bo może pokazać samą stronę logowania.

Ta kolejność ma znaczenie z jeszcze jednego powodu: klient z przełącznikiem awaryjnym lub trybem zawsze włączonym odmówi wczytania portalu, a użytkownik uzna, że zepsuła się sieć, a nie ustawienie. Oba fakty są prawdziwe naraz, a w hotelu można zmienić tylko jeden. Wyłącz ochronę przez własne sterowanie klienta, zaloguj się i włącz ją ponownie. Wszystko inne to obejście, które ukrywa prawdziwą kolejność.

Najpierw dokończ portal, potem testuj zwykły HTTPS

Zapytaj personel o oficjalną nazwę sieci i metodę logowania. Przekonujący SSID nie jest dowodem własności, a druga sieć o podobnej nazwie to częsty trik w miejscach publicznych. Użyj własnego monitu logowania systemu operacyjnego, jeśli jest oferowany, albo udokumentowanej strony hotelu.

curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://captive.apple.com/hotspot-detect.html
curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/

Pierwsze żądanie pyta znany punkt wykrywania portalu przechwytującego przez zwykły HTTP; przekierowanie lub nieoczekiwana treść oznacza, że wciąż jesteś za portalem. Drugie testuje zwykłą witrynę HTTPS. Jeśli pierwsze pokazuje przechwycenie, a drugie zawodzi, logowanie jest niepełne i VPN nie ma z tym nic wspólnego.

Na urządzeniu osobistym może być trzeba wyłączyć przełącznik awaryjny lub stały VPN przez obsługiwane sterowanie klienta, aby portal mógł się wczytać. Zamknij wrażliwe aplikacje w tym oknie i natychmiast potem włącz ochronę z powrotem. Na urządzeniu zarządzanym stosuj procedurę zatwierdzoną przez administratora, zamiast samodzielnie usuwać politykę.

Nigdy nie omijaj ostrzeżenia o certyfikacie i nie instaluj nieznanego certyfikatu ani programu pomocniczego, aby wejść online. Jeśli portal żąda czegoś nieoczekiwanego, potwierdź to z personelem, a z administratorem, jeśli urządzenie należy do pracodawcy.

Zachowaj oryginalny profil i jego błąd

Gdy zwykły dostęp działa, połącz oryginalny profil i zapisz dokładny błąd. Odrzucenie uwierzytelnienia to problem konta, przekroczenie czasu podczas negocjacji to problem ścieżki, a tunel, który powstaje, ale nic nie przenosi, to problem routingu lub polityki.

Te trzy wymagają różnych kolejnych kroków, a zrzut ekranu błędu jest wart więcej niż opis. Zapisz też czas, bo limity sesji hotelowej mogą wygasnąć w ciągu godziny i wywołać awarię, która wygląda losowo. Jeśli klient oferuje log, zachowaj fragment wokół pierwszego błędu, a nie cały plik. Ten wyciąg zwykle wystarcza właścicielowi profilu do rozpoznania etapu.

Jeśli zwykły dostęp działa, a negocjacja wciąż się przedawnia, zapytaj hotel, czy obsługuje ten ruch, i porównaj z zaufanym hotspotem, trzymając urządzenie i profil bez zmian. Praca na hotspocie zawęża uwagę do ścieżki hotelu, nie dowodząc niczego o profilu.

Używaj tylko alternatyw dostarczonych przez operatora

Pasujący profil TCP może się udać tam, gdzie oferowana ścieżka UDP nie działa, ale tylko jeśli serwer naprawdę nasłuchuje na tym transporcie i porcie. Port TCP 443 nie jest automatycznie traktowany jak zwykły HTTPS i nie gwarantuje przejścia przez restrykcyjną sieć.

sudo openvpn --config /etc/openvpn/client/office-tcp.conf --verb 4

Uruchomienie dostarczonego profilu z większą szczegółowością utrzymuje pierwszy użyteczny błąd widocznym, zamiast wciskać go w ogólne okno awarii. Użyj pliku od operatora, a nie samodzielnie edytuj porty czy protokoły, bo lokalna zmiana nie może stworzyć pasującego nasłuchu po drugiej stronie.

Jeśli tunel resetuje się wielokrotnie, zanotuj, czy portal wraca albo czy sygnał lokalny spada, i trzymaj się kontroli stabilności, zamiast przełączać kilka protokołów naraz. Potem przetestuj aplikację, której naprawdę potrzebujesz, i przywróć zwykłe kontrole prywatności. Połączenie, które przenosi jedną stronę, ale nie inną, to kwestia routingu lub polityki, nie portalu.

Na koniec sprawdź odzyskiwanie po uśpieniu laptopa. Autoryzacja portalu może wygasnąć niezależnie od tunelu, więc urządzenie, które łączy się ponownie automatycznie, może wrócić do sieci, która już je zapomniała. Ponowne otwarcie strony portalu to normalny krok, nie znak, że VPN się zepsuł.