VPN łączy się ponownie podczas jazdy: zmiana radia czy zmiana IP?

Połączenie spada, gdy mijasz rogatki miasta, i ikona VPN znika w tej samej chwili. Kuszące jest zapisać to jako „zmiana stacji zabiła tunel”. Stały się dwie różne rzeczy, a tylko jedna z nich dotyczy stacji. Przekazanie radiowe może pozostawić twój adres IP, trasę domyślną i sesję całkowicie nietknięte, podczas gdy prawdziwa zmiana adresu zerwie każdy tunel, który nie potrafi się z nią przenieść. Porównanie, jak klienci radzą sobie z drugim przypadkiem, jest właśnie pożytecznym ćwiczeniem, bo mówi, czy widzisz zaprojektowane zachowanie, czy błąd.

Zmiana stacji nie musi być zmianą adresu

Sieci komórkowe utrzymują sesję pakietową przy przekazaniach, dopóki kotwica mobilności operatora pozostaje ta sama. Łącze radiowe się zmienia, tunel tego nie zauważa i w żadnym logu nie powinno pojawić się ponowne połączenie. To zwykły przypadek ruchu w obrębie miasta.

Adres zmienia przejście między kotwicami, zmiana z Wi-Fi na sieć komórkową albo odtworzenie tunelu po stronie operatora po długiej przerwie. Te zdarzenia zastępują adres źródłowy, który niosą twoje pakiety, a peer VPN widzi peera, który się przemieścił.

Praktyczny wniosek jest taki, że ruch nie jest dowodem. Urządzenie, które przejechało czterdzieści kilometrów, mogło trzymać jeden adres przez całą drogę, a nieruchome urządzenie mogło dwa razy zmienić adres, bo sieć tak zdecydowała. Zapisanie zdarzenia to jedyny sposób, by je rozróżnić.

Dwa projekty: przenieść tunel albo zbudować go od nowa

Klienci różnią się tym, jak bardzo przejmują się zmianą zewnętrznego źródła. Niektórzy wiążą tunel z adresem, na którym został zbudowany, i wymagają pełnego odtworzenia. Inni weryfikują każdy pakiet niezależnie i tylko aktualizują, gdzie wysyłają odpowiedzi.

Górny wiersz wyjaśnia wiele zagmatwanych raportów. WireGuard nie ma sesji, którą można zerwać: każdy pakiet niesie indeks peera i jest uwierzytelniany, więc prawidłowy pakiet przychodzący z nowego adresu jest z definicji od tego peera, a zapisany punkt końcowy za nim podąża. Klient, który przez całą jazdę pokazuje „połączono”, mówi prawdę.

Dolny wiersz też nie jest defektem. Odbudowa sesji ponownie wykonuje uwierzytelnienie wobec bieżącego adresu, co jest dokładnie tym, czego chcesz, gdy stary adres może teraz należeć do kogoś innego.

Obserwuj zdarzenie, a nie ruch

W Androidzie podsystem łączności raportuje zmiany sieci jako zdarzenia, i to je należy korelować z zachowaniem klienta. Zrzut jest długi, ale istotne części to sieć domyślna i jej adres:

adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40

Po stronie serwera istnieje bezpośredni pomiar dla przypadku roamingu. WireGuard przechowuje ostatni uwierzytelniony punkt końcowy dla każdego peera, więc zmiana adresu objawia się jako zmieniona wartość, a nie jako ponowne połączenie:

sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakes

Porównaj punkt końcowy przed jazdą i po niej. Jeśli adres i port się nie zmieniły, tunel nie musiał nic robić, a ponowne połączenie przyszło skądinąd, zwykle z aplikacji. Jeśli punkt końcowy się zmienił, a znacznik czasu uścisku dłoni pozostał blisko normalnego interwału odświeżania klucza, tunel się przemieścił, a nie uruchomił ponownie.

Ponowny start wygląda inaczej: znacznik czasu uścisku dłoni resetuje się do momentu ponownego połączenia, a klient zapisuje sekwencję inicjalizacji zamiast cichego kontynuowania.

Kiedy ponowne połączenie jest właściwym zachowaniem

Traktowanie każdego ponownego połączenia jako awarii prowadzi do konfiguracji, które utrzymują martwe sesje przy życiu. Peer, którego adres się zmienił, bo sieć przydzieliła go ponownie, nie powinien dalej odbierać ruchu dla starego mapowania, a klient, który po cichu kontynuuje, może skończyć na wysyłaniu w czarną dziurę, podczas gdy ikona pozostaje zielona.

Porównaj obie awarie z perspektywy użytkownika. Ponowne połączenie kosztuje kilka sekund i nowe uwierzytelnienie. Przestarzały tunel kosztuje aplikację, która zawiesza się bez błędu, co jest znacznie trudniejsze do wyjaśnienia i znacznie częściej zgłaszane jako „internet się zepsuł”.

Pod tym kryje się też pytanie o politykę. W luce między utratą jednej ścieżki a ustanowieniem drugiej niektórzy klienci wracają do bezpośredniego wysyłania ruchu. Zapobieganie temu to osobna kontrola od automatycznego odzyskiwania, a klient może być dobry w jednym, a słaby w drugim. Zdecyduj, czego potrzebujesz, zanim dostroisz którekolwiek z nich.

Zapisz zaobserwowaną sekwencję

Użyteczny raport nazywa źródło zdarzenia: zmianę sieci domyślnej z nowym adresem, przejście z Wi-Fi na sieć komórkową albo przekazanie bez żadnej zmiany adresu. Potem podaje, co zrobił klient, ze znacznikiem czasu ze strony serwera, a nie z pamięci.

Jeśli tunel się przemieścił, powiedz to i zapisz nową rodzinę punktów końcowych. Jeśli został odtworzony, zapisz, czy uwierzytelnienie powiodło się za pierwszym razem i jak długo trwała luka. Te trzy fakty odróżniają zdrowy projekt mobilny od klienta miotającego się między sieciami.

I unikaj sformułowania „zmiana stacji”, chyba że log urządzenia naprawdę to potwierdza. Dokumentacja Androida dotycząca łączności opisuje wywołania zwrotne, które odróżniają dostępność od zmiany sieci domyślnej, i właśnie tego rozróżnienia potrzebuje twój raport. Wszystko inne to opowieść o jeździe.