Ta sama tożsamość IKEv2 na dwóch iPhone'ach? Łączą się na zmianę

Dwa telefony, jeden profil i wzorzec, który wygląda nadnaturalnie, dopóki ktoś nie spojrzy na bramę. Jedno urządzenie trzyma tunel, drugie się łączy, a pierwsze traci go w ciągu sekund. Pierwsze łączy się ponownie, a drugie wypada. Oskarża się oszczędzanie baterii, roaming Wi-Fi i NAT operatora, podczas gdy prawdziwa przyczyna siedzi w polu tekstowym skopiowanym razem ze wszystkim innym. IKEv2 identyfikuje peera po nazwie, a oba telefony przedstawiają tę samą.

Tożsamość to klucz, pod którym serwer cię przechowuje

W wymianie IKEv2 każda strona deklaruje, kim jest: inicjator wysyła lokalny identyfikator, responder odpowiada swoim, a responder sprawdza też tożsamość podaną przez inicjatora wobec polityki. Brama przechowuje stan według tożsamości, a nie według urządzenia, ponieważ urządzenie nie jest czymś, co może zobaczyć. Dwa telefony z jednym identyfikatorem przychodzą więc jako jeden peer, a druga wymiana musi nadpisać pierwszą. Problem pojawia się tylko wtedy, gdy oba są w użyciu, dlatego test z jednym telefonem nigdy go nie odtwarza.

Nic z tego nie jest błędem klienta. Klient wysłał dokładnie to, co kazał mu profil.

Jak kolizja wygląda z bramy

Obserwuj listę peerów, gdy oba telefony są obudzone i w użyciu. Kolizja pokazuje jeden wpis, którego adres zmienia się, gdy telefony się zamieniają, a licznik aktywnych sesji nigdy nie osiąga dwóch. Rozłączenie na żądanie wygląda inaczej, a rozróżnienie ich wymaga jednej obserwacji, a nie teorii.

Zapisz oba zdarzenia ze znacznikami czasu, gdy to się dzieje. Zerwanie zbiegające się z połączeniem drugiego urządzenia wskazuje na identyfikator, a zerwanie przychodzące jeden interwał bezczynności po ostatnim pakiecie wskazuje na timer.

Skąd biorą się duplikaty

Wyeksportowanie jednej działającej konfiguracji i edycja tylko adresu serwera tworzy drugi plik, w którym wciąż jest tożsamość pierwszego pliku. To zwykła droga do tej awarii i zwykle zdarza się przy pośpiesznym wdrażaniu małej grupy.

Nazwy pól ułatwiają przeoczenie. Zdalny identyfikator nazywa bramę, której oczekuje telefon, i kopiowanie go jest poprawne. Lokalny identyfikator nazywa to urządzenie wobec bramy, i kopiowanie tej wartości jest całym problemem.

Wydaj wartość dla każdego urządzenia

Użyj czegoś unikalnego dla urządzenia i stabilnego przez cały jego okres życia, na przykład identyfikatora urządzenia z inwentarza albo wartości, którą system zarządzania generuje dla każdej rejestracji. Etykieta działu, nazwa współdzielonego konta usługi lub adres e-mail użytkownika kolidują, gdy tylko ta osoba ma drugie urządzenie.

Generuj ładunek dla każdego urządzenia zamiast dystrybuować jeden plik. Zanotuj, która wartość należy do którego urządzenia, aby wymiana nie przywróciła starego profilu i nie wepchnęła nowego telefonu z powrotem w tę samą kolizję.

Sprawdź też stronę serwera. Brama, która mapuje tożsamość na stały adres tunelu, wciąż może kolidować, gdy dwa różne identyfikatory otrzymają to samo przypisanie, więc potwierdź, że pula ma miejsce i że przypisania nie są przypięte do użytkownika.

Zweryfikuj z oboma telefonami obudzonymi

Połącz pierwszy, dotrzyj do prywatnego zasobu, następnie połącz drugi i zostaw oba bezczynne przez minutę. Obie sesje powinny się utrzymać, a lista peerów powinna pokazywać dwie tożsamości. Potem zablokuj i odblokuj każdy telefon, aby potwierdzić, że przypadek bezczynności nadal zachowuje się poprawnie.

Jeśli jedna sesja nadal pada raz dziennie, gdy nic innego się nie łączy, tożsamość nie jest już podejrzanym. Przejdź do timerów bezczynności i limitów sesji serwera zamiast ponownie edytować profil.