W otwartej sieci punkt dostępowy nie przekazuje pakietów po prostu do internetu. Punkt polityki wyżej sprawdza, czy urządzenie jest już autoryzowane, a dopóki nie jest, prawie wszystko jest odrzucane. Klient VPN czyta tę ciszę jako martwy serwer. Rzadko to mówi: WireGuard powtarza uścisk dłoni w pustkę, OpenVPN zgłasza przekroczenie limitu czasu połączenia, a IKEv2 wraca jako błąd 809 o zdalnym serwerze, który nie odpowiada.

Co portal naprawdę kontroluje

Portal przechwytujący to dwie rzeczy sklejone razem: punkt decyzyjny polityki i przekierowujący. Gdy urządzenie się przyłączy i pobierze dzierżawę DHCP, sieć stawia cię w stanie przed autoryzacją.

Ten stan to zbiór reguł zapory. Zwykle przepuszcza DNS i zezwala na HTTP lub HTTPS do krótkiej listy hostów portalu, a wszystko inne odrzuca. Dozwolona lista to ogrodzony ogród i prawie nigdy nie zawiera punktu końcowego VPN.

Żadne z tych odrzuceń nie jest uprzejme. Pakiety kierowane do serwera VPN są odrzucane, a nie odrzucane z odmową, więc klient nie dostaje ani ICMP unreachable, ani TCP reset, tylko brak odpowiedzi. W zależności od dostawcy przekierowujący może odpowiedzieć na porcie 80 przekierowaniem na stronę logowania, podczas gdy port 443 jest odrzucany lub przechwytywany. Przekierowania łatwo rozpoznać, bo niosą zwykłą odpowiedź HTTP; przechwycenie na 443 wymaga certyfikatu, któremu przeglądarka odmówi zaufania.

Sama autoryzacja jest zwykle powiązana z adresem MAC urządzenia, czasem z dzierżawionym IP, i żyje w tablicy sesji z licznikiem czasu. Zalogowanie tworzy wpis. Reguła zapory przepuszczająca twój ruch istnieje tylko tak długo, jak istnieje ten wpis, i dlatego cały problem wraca później, choć po twojej stronie nic się nie zmienia.

Dlaczego uścisk dłoni VPN umiera, zanim się zacznie

Każdy protokół ma własny transport, a zapora przed autoryzacją psuje każdy inaczej. IKEv2 w Windows i iOS idzie przez UDP 500 i UDP 4500; odrzucenie na tych portach objawia się jako 809 albo jako błąd w stylu rozwiązywania nazw u klientów, które raportują fazy osobno. OpenVPN przez UDP 1194 pozostaje w stanie łączenia, aż upłynie limit czasu. OpenVPN przez TCP 443 to ciekawy przypadek, bo portal może dokończyć uścisk TCP i odpowiedzieć swoją stroną przekierowania, więc widzisz błąd TLS zamiast limitu czasu.

WireGuard pokazuje ten mechanizm najwyraźniej. Z założenia jest tylko UDP, bez zapasu TCP, więc zapora odrzucająca nieznane UDP usuwa transport całkowicie. Klient dalej wysyła inicjacje uścisku dłoni z rosnącą przerwą i zgłasza uścisk, który nigdy się nie kończy. Nic w tym komunikacie nie wspomina Wi-Fi i nic nie sugeruje, że masz otworzyć przeglądarkę.

Platformy próbują zauważyć stan wcześniej niż twój VPN. Windows pobiera znany URL, by zdecydować, czy pokazać powiadomienie o logowaniu, Android prosi o punkt końcowy, który powinien odpowiedzieć 204 No Content, a urządzenia Apple otwierają małe okno sieci przechwytującej. Te sondy działają, bo portal odpowiada przekierowaniem zamiast oczekiwanej treści. To samo zachowanie wyjaśnia, jak portal może wyglądać całkiem zdrowo, gdy tunel jest martwy: sonda i tunel są oceniane według różnych reguł.

Co naprawdę resetuje wygaśnięcie sesji

Miejsca kończą sesje z powodów niezwiązanych z kontem VPN: limit bezczynności, maksymalna długość sesji, nowa dzierżawa DHCP albo ponowne przyłączenie do innego punktu dostępowego. Gdy licznik zadziała, wpis w tablicy sesji znika, a zbiór reguł przed autoryzacją wraca dokładnie taki, jaki był przy zameldowaniu.

Ustanowiony tunel często żyje dość długo, by wyglądać zdrowo. Komunikaty utrzymania życia nadal wychodzą, a to, czy klient to zauważy, zależy od tego, jak traktuje ruch bez odpowiedzi, więc lampka stanu może jeszcze przez chwilę być zielona po zniknięciu trasy. Potem tunel pada i każda próba ponownego połączenia zawodzi na tych samych zablokowanych portach.

W tym momencie błąd klienta mówi, na jakim etapie jesteś, jeśli przeczytasz go uważnie:

SymptomWhat it meansNext check
Handshake times out with no replyPre-authorization drop on UDPLoad any HTTP page and see whether the portal appears
Immediate TLS error on 443The portal answered your TCP connectionAuthorize, then retry the same profile
Authentication rejectedYour credentials reached the serverThe network is fine, so treat this as an account problem
Connects, then drops repeatedlySession or lease churnWatch the portal timer and the lease time

Jeden szczegół myli ludzi: gdy sesja jest przypisana do adresu MAC, ponowne wczytanie strony logowania może nie pomóc. Musisz zerwać przyłączenie i dołączyć ponownie, żeby portal zobaczył nową próbę autoryzacji zamiast wygasłej.

Najpierw się zaloguj, potem podnieś tunel

Działająca kolejność to: autoryzuj urządzenie, udowodnij trasę, uruchom VPN, udowodnij tunel, a potem przywróć swoje zwykłe blokowanie. Ten ostatni krok jest ważny, bo stan tymczasowy potrzebny do dotarcia do portalu to dokładnie ten stan, któremu wyłącznik awaryjny ma zapobiegać.

Klient desktopowy z opcją blokowania poza tunelem musi zostać wstrzymany, by strona portalu się wczytała, a wrażliwe aplikacje trzymaj zamknięte w tym oknie poza tunelem; to jedyny przedział, w którym ruch lokalny wychodzi bez ochrony. Zarządzane urządzenie stale włączone powinno użyć procedury opublikowanej przez właściciela, a nie tego, że ty zdejmujesz politykę. Jeśli portal pokaże ostrzeżenie o certyfikacie, zatrzymaj się: przyjęcie go prowadzi sesję przez lokalne proxy przechwytujące, a to proxy może czytać wszystko, co wysyłasz. W Androidzie blokada pod stale włączonym VPN zatrzymuje ruch, zanim tunel wstanie, a niektóre kompilacje nie potrafią wyłączyć ruchu portalu; jeśli twoja nie potrafi, użyj alternatywnego dostępu w miejscu albo innego urządzenia, zamiast zostawiać blokadę wyłączoną. Reguły na żądanie Apple można napisać tak, by odmawiały tunelu, dopóki sonda się nie powiedzie, i to jest zachowanie, którego chcesz w sieciach hotelowych.

Sprawdź po kolei dostępnymi narzędziami. Przed tunelem uruchom sondę z widocznymi nagłówkami i treścią i zobacz, czy transport VPN dostaje w ogóle jakąkolwiek odpowiedź:

curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'

Przed autoryzacją zwykły portal daje jedną z dwóch odpowiedzi: 302, którego Location wskazuje stronę logowania, albo 200 z treścią HTML, która jest stroną portalu. Zanotuj, którą dostałeś. Przekierowanie przed logowaniem nie jest porażką; portal mówi ci, gdzie iść. Gdy portal zgłosi sukces, powtórz polecenie i oczekuj 200, którego treścią jest dosłownie słowo Success. To właśnie ten ciąg czyni sondę sensowną. Jeśli host odpowiada normalnie, zanim kiedykolwiek się zalogujesz, w tej sieci nie ma portalu przechwytującego. W przechwyceniu odrzucenie przed autoryzacją to pakiety wychodzące, z których nic nie wraca, a działająca trasa pokazuje odpowiedź na ten sam strumień w ciągu około sekundy. Połącz się, a potem powtórz przechwycenie.

Jeśli tunel nadal zawodzi, gdy portal mówi tak

Sukces logowania to nie to samo co dozwolony transport. Wiele miejsc pozwala na portal i zwykłe przeglądanie, a całkowicie blokuje UDP, co zostawia WireGuard i OpenVPN przez UDP zepsute, a TCP 443 działa. Jeśli TCP 443 przechodzi, a UDP nie, to polityka miejsca, a nie źle skonfigurowany klient, więc zmień transport albo przyjmij ograniczenie i idź dalej. Jeśli ponowne połączenie nadal zawodzi, zachowaj dokładny błąd; nazywa etap, na którym utknąłeś.

Inne błędy mieszkają w urządzeniu. Sesja wciąż przypisana do starego MAC, drugi adapter Wi-Fi z własną dzierżawą albo klient, który zapisał wyjątek certyfikatu portalu, mogą dalej zawodzić po czystej ponownej autoryzacji. Zerwij przyłączenie, autoryzuj ponownie i spróbuj raz, zanim dotkniesz ustawień klienta. RFC 8952 warto przeczytać, jeśli chcesz architektury stojącej za obserwowanymi elementami.

Jeśli sam portal odmawia autoryzacji, problem jest w koncie albo w przydziale urządzenia i żadne ustawienie VPN tego nie naprawi. Zmiana kraju wyjścia VPN nie resetuje lokalnego stanu dostępu w miejscu; ta tablica jest przypisana do twojego urządzenia, a nie do wybranego serwera. Zapytaj operatora miejsca i daj mu czas, bo to tablicę sesji będzie oglądał.

Przed następną podróżą zapisz trzy rzeczy: stronę portalu jako krok zerowy, krok wstrzymania blokady dla każdego urządzenia, które bierzesz, i jeden zapasowy transport, który naprawdę przetestowałeś. Gdy tunel, który działał dziesięć minut temu, znów się zatrzyma, potraktuj to jako wygasłą autoryzację i sprawdź portal ponownie, zanim dotkniesz profilu VPN.

Powiązane artykuły