Jak MOBIKE utrzymuje połączenie VPN IKEv2 przy zmianie sieci

Telefon opuszcza Wi-Fi i dołącza do sieci komórkowej, laptop przechodzi z Ethernetu na hotspot, a tunel IKEv2 albo przetrwa, albo nie. MOBIKE to rozszerzenie, które pozwala mu przetrwać, informując drugą stronę, że adres źródłowy się zmienił, zamiast zaczynać od nowa. Czego nie robi, to nie utrzymuje każdej aplikacji przy życiu podczas zmiany. To dwa twierdzenia, a drugie jest tym, co ludzie zwykle mają na myśli.

Przejdź przez zmianę etapami, ponieważ każdy etap zawodzi inaczej.

Co naprawdę zmienia aktualizacja

Dopóki asocjacja bezpieczeństwa jest jeszcze ważna, inicjator poznaje swój nowy adres i wysyła aktualizację do respondera, który następnie używa tego adresu do tej samej asocjacji. Parametry bezpieczeństwa nie są ponownie negocjowane od zera. To cała korzyść: żadnej nowej rundy uwierzytelniania, żadnej nowej wymiany kluczy, żadnego pytania do użytkownika. Oznacza to również, że zachowany stan nadal należy do starej sesji.

MOBIKE może też przenieść ruch do enkapsulacji UDP, dlatego działający tunel czasem zaczyna używać portu 4500 po zmianie sieci. To przejście samo w sobie nie dowodzi wykrycia NAT, choć oba zjawiska często występują razem.

Czy Twój profil naprawdę to włącza

Obie strony muszą obsługiwać rozszerzenie, a wdrożenie musi je włączyć. W strongSwan zachowanie jest konfigurowalne dla każdego połączenia, a zmiany interfejsu lub trasy mogą wywołać wyszukiwanie ścieżki i aktualizację, gdy jest to potrzebne. Sprawdź rzeczywiste ustawienia połączenia, zamiast zakładać, że każdy profil IKEv2 je włącza. Profil skopiowany z przewodnika starszego niż ta funkcja jest częstą przyczyną.

Wynegocjowany stan po obu stronach jest autorytetem, a nie dokumentacja rodziny produktów.

Przejdź przez zmianę etapami

Zapisz stan aplikacji przed zmianą sieci. Następnie zmień i zapisz stan klienta oraz serwera po zmianie. Brakujący adres, nieosiągalny partner i aplikacja, która musi sama ponownie połączyć swoją sesję, to trzy różne wyniki. Tylko dwa pierwsze należą do warstwy VPN; trzeci należy do protokołu, którym mówi aplikacja.

Porównaj przełączenie sieci z testem stacjonarnym, aby wiedzieć, które zdarzenie wywołuje problem. Pomiar przepustowości w sieci docelowej nie może odtworzyć przejścia. Mierzy cel, a nie drogę.

Rozdziel warstwy awarii

Długotrwała sesja TCP może zawieść z powodów poza wymianą IKEv2. Nowa sieć może filtrować, rozwiązywać nazwy lub trasować inaczej. Adres tunelu może się w ogóle nie zmienić, podczas gdy ścieżka pod nim się zmienia. Dlatego ponowne połączenie aplikacji może naprawić coś, czego VPN nigdy nie zepsuł.

Utrzymuj politykę blokowania także podczas odzyskiwania.

Automatyczna mobilność i reguła blokująca ruch bezpośredni to różne mechanizmy, a wyłączanie drugiego, by pierwszy działał, jest złą wymianą. Jeśli aktualizacja mobilności zawiedzie, blokada powinna się utrzymać, a nie przepuszczać ruch wokół tunelu.

Co zapisać, gdy się to powtarza

Zachowaj znaczniki czasu i obie wartości adresów z obu stron. Ten zapis pokazuje, czy aktualizacja zakończyła się przed utratą kontaktu przez aplikację, co jest różnicą między błędem mobilności a przekroczeniem czasu aplikacji. Następnie porównaj kierunek przełączenia: odejście z Wi-Fi do sieci komórkowej nie jest symetryczne z odwrotnym. Jeden kierunek może działać, podczas gdy drugi zawodzi.

Ta asymetria jest dość częsta, by być pierwszą rzeczą do przetestowania.

Mając zapis w ręku, incydent przestaje być kolejną rozłączoną ikoną i staje się jednym zdarzeniem w sekwencji ze znanym właścicielem. I to wszystko, co przegląd może uczciwie obiecać.