iPhone Always On VPN: dwa tunele mogą dzielić jeden wirtualny IP

Na nadzorowanym iPhonie z zarządzanym profilem Always On telefon trzyma tunel dla każdego aktywnego interfejsu IP, więc sieć komórkowa i Wi-Fi mają każda swój. Serwer pokazuje wtedy dwa skojarzenia bezpieczeństwa IKE dla jednego urządzenia, często współdzieląc jeden adres wirtualny, a pierwszym odruchem jest nazwanie tego pętlą rekey i rozpoczęcie zmiany timerów. Ten odruch jest zwykle błędny. Przejdź poniższe kroki w kolejności, w jakiej dowody pojawiają się na serwerze, i zostaw ustawienia telefonu w spokoju, dopóki serwer nie powie ci, który przypadek masz.

Zacznij od dwóch wierszy, które serwer już ma

Wypisz skojarzenia za pomocą swanctl --list-sas i odczytaj cztery pola w obu wpisach: adres zdalny, uwierzytelnioną tożsamość, przydzielony wirtualny IP i czas utworzenia. Dwa różne adresy zewnętrzne z jedną tożsamością i jednym wirtualnym IP to kształt, który zapoczątkował to pytanie, i warto go zapisać przed jakąkolwiek zmianą. Następnie sprawdź skojarzenia podrzędne przypięte do każdego z nich, bo selektory ruchu decydują, czy wyszukiwanie celu mogłoby kiedykolwiek odróżnić dwa tunele. Para, która pojawia się i znika w ciągu sekund, to inne zwierzę niż para, w której oba żyją godzinami.

Przed wyciągnięciem wniosku posortuj listę według czasu utworzenia. Sąsiedztwo w wynikach nic nie znaczy, a lista tabelaryczna zaprasza dokładnie do tego błędu.

Ustal, na jakie nakładanie się patrzysz

Rekey IKEv2 i ponowna uwierzytelnianie make-before-break celowo tworzą krótkie nakładanie się, ustanawiając nowe skojarzenie przed usunięciem starego. Znaczniki czasu rozstrzygają sprawę, bo stare SA, które znika sekundę lub dwie po pojawieniu się nowego, jest odnowieniem wykonującym swoją pracę. Niezależne tunele interfejsów nigdy tak nie wyglądają, ponieważ każdy trwa, dopóki jego interfejs jest aktywny, a usunięcie jednego nie wynika z utworzenia drugiego.

Zarządzane zachowanie Always On Apple działa na interfejs, dlatego nadzorowane urządzenie może zgodnie z prawem wyglądać na bardziej zajęte niż profil skonfigurowany ręcznie. Przełącznik automatycznego łączenia w aplikacji dostawcy nie oznacza tego samego, a zwykła reguła on-demand też nie. Przegląd wdrożenia Apple opisuje model na interfejs; porównaj swoje dwa wiersze z nim, zanim założysz pętlę. Oba kształty czerpią też z tej samej puli serwera, więc nakładanie się jest twoim jedynym wczesnym sygnałem.

Zobacz, dlaczego jeden adres wirtualny dla dwóch tuneli psuje odpowiedzi

Odpowiedź do telefonu jest adresowana do adresu wewnętrznego, a jądro wybiera tunel wychodzący według celu i polityki, nie według interfejsu, którego użył telefon. Dwa równoczesne skojarzenia trzymające ten sam wirtualny IP przy pokrywających się politykach zostawiają decyzję routingu bez sposobu, by powiedzieć, do której sesji należy odpowiedź. Niektóre odpowiedzi trafiają w zły tunel, a telefon pokazuje połączenie działające w jedną stronę lub ginące, gdy pojawia się Wi-Fi. Dwa wyniki poleceń dowodzą stanu: swanctl --list-sas pokazuje ten sam wirtualny IP na obu SA, a ip xfrm policy pokazuje dwa identyczne selektory.

Właśnie tę parę wyników wklejasz do zapisu zmiany. Żaden z nich osobno nie jest przekonujący, bo każdy może wyglądać wiarygodnie sam.

To adresowanie i polityka po stronie serwera, nie złe zachowanie telefonu, i żadne ustawienie klienta nie rozdziela dwóch identycznych adresów wewnętrznych. Pula dwa razy wydała tę samą wartość, a instalator polityki ją zaakceptował. Przeczytaj wynik ze strony serwera, zanim obwinisz klienta.

Zmień pulę albo model współbieżności, nie timer rekey

W konfiguracji swanctl unikatowość jest wyraźną polityką na połączeniu: unique = replace usuwa starsze połączenie, gdy nowe się nawiązuje, a unique = keep odrzuca nowego przybysza. Obie wartości działają przy zestawianiu połączenia, nie na podrzędnych SA w nim.

connections {
  ios-alwayson {
    unique = replace
  }
}

Żadna z wartości nie jest neutralna dla klienta na interfejs. keep przywraca uporządkowany ekran stanu, odmawiając drugiego tunelu, i psuje zarządzaną konstrukcję, podczas gdy replace burzy starszy tunel i jest tym samym kompromisem w drugą stronę. Jeśli oba tunele są naprawdę potrzebne, backend puli musi wydawać różne dzierżawy dla jednej tożsamości, a jego klucz dzierżawy musi rozróżniać żądania. Statyczna tabela tożsamość-adres chętnie zwróci ten sam adres dwa razy i odtworzy pierwotny problem z większą konfiguracją. Sprawdź, jak backend tworzy klucze dzierżaw, zanim dodasz drugie statyczne mapowanie.

Testuj przejścia, które naprawdę wdrażasz

Wyjdź poza zasięg Wi-Fi z aktywną sesją, potem wróć, i sprawdź, że odpowiedzi docierają w obu kierunkach. Zrób to dwa razy, bo przy drugim przejściu zwykle pojawia się nieaktualna polityka. Przetestuj usługą, która odpowiada na połączeniu, które otworzyłeś, i powtórz wyjście, gdy tunel niesie ruch, a nie stoi bezczynnie. Telefon, który potrafi wysyłać, ale nie odbierać, wygląda zdrowo w logu uzgadniania, a zepsuty w przeglądarce.

Ekran stanu zredukowany do jednego wiersza nie jest dowodem działającej konstrukcji, tylko dowodem, że jeden tunel zniknął. Oba kierunki muszą działać, zanim przejście zostanie zaliczone. Zapisz, co zaobserwowałeś, razem z dwoma wynikami kontroli nakładania się, aby następny inżynier mógł porównać, zamiast powtarzać spacer.