iOS IKEv2 do strongSwan: brak wybranej propozycji, popraw listę

iPhone podnosi tunel, brama nie odpowiada niczym, a telefon pokazuje ogólny błąd. Dziennik strongSwana jest konkretniejszy: no proposal chosen. Ten komunikat oznacza, że dwie listy akceptowalnych zestawów szyfrów nigdy się nie pokryły, więc wymiana zakończyła się, zanim zaczęła się uwierzytelnianie. To problem dopasowania, a rozwiązaniem jest przecięcie list.

Gdzie brama deklaruje swoją politykę

strongSwan zapisuje swoją politykę w konfiguracji, a wykrzyknik na końcu decyduje o tym, jak tę politykę czytać. Ze znakiem lista jest wyczerpująca: przyjmowane są tylko te wpisy i nic więcej. Bez znaku ta sama linia jest kolejnością preferencji i demon może wybrać coś, czego nie zamierzałeś. Zapytaj, która forma jest wdrożona, zanim cokolwiek przetłumaczysz, bo obie zachowują się inaczej wobec tego samego klienta. Zapisz dokładną linię wraz ze znakiem i testuj względem niej.

Klient oferujący szerszą listę nadal może połączyć się z przypiętą bramą, o ile jedna kombinacja występuje po obu stronach. Nie może za to dojść do negocjacji poza przypiętym zbiorem.

Dlatego profil skopiowany z innej aplikacji VPN może działać tam, gdzie twój nie działa: tamta aplikacja wysłała inną listę.

Nazwy muszą się zgadzać, a nie poprawiać

Dwa tłumaczenia mylą ludzi przenoszących wartości z strongSwana do iOS. Algorytm integralności zapisany jako SHA1 w propozycji IKE wędruje w skróconej formie, którą iOS nazywa .SHA96. Grupa Diffiego-Hellmana zapisana jako modp1024 to grupa 2, którą iOS nazywa .group2. Zastąpienie jej przez SHA-256 lub grupę 14 nie wynegocjuje z bramą, która przyjmuje tylko starszą parę. Klient musi opisać ten sam algorytm, a nie mocniejszy.

Ustaw te wartości jawnie w NEVPNProtocolIKEv2. Wartości domyślne mogą być szersze lub węższe niż zastępowany profil, a różnica wychodzi dopiero wtedy, gdy uzgadnianie zawiedzie.

Propozycja potomna zawodzi później i ciszej

Skonfiguruj także asocjację bezpieczeństwa potomną, nie tylko tę IKE. Gdy zgadzają się tylko parametry IKE, tunel się uwierzytelnia, a potem nie niesie ruchu, co jest znacznie cichszą awarią niż odmowa. Ustaw szyfrowanie, integralność, grupę i czas życia potomnej w tym samym kroku. Trzymaj czas życia klienta na poziomie wartości bramy lub niżej, bo upieranie się przy dłuższym daje ten sam komunikat no proposal chosen z innej przyczyny. Niezgodność tam wygląda identycznie jak niezgodność IKE w dzienniku.

Sprawdź, czy profil uwierzytelnia się certyfikatami, czy wspólnym sekretem, kiedy jesteś w konfiguracji. Odrzucenie propozycji i odrzucenie uwierzytelnienia pojawiają się w różnych liniach, a naprawianie niewłaściwego kosztuje dzień. Testuj na świeżym połączeniu po każdej zmianie, po jednej zmiennej naraz, bo stan z pamięci podręcznej ukrywa, który parametr się przesunął.

Zostaw stary zestaw tylko tak długo, jak jest potrzebny

Przypięcie SHA-1 z grupą 1024 bity to most, nie cel. Oba są przestarzałe, a nowsze klienty mogą je wprost odrzucić, co oznacza, że profil zawiedzie na następnym urządzeniu bez żadnej zmiany po twojej stronie. Traktuj przypięcie jako tymczasowe i zapisz to w protokole.

Jeśli strongSwan jest twój, dodaj nowoczesną propozycję i pozwól obu stronom negocjować w górę, podczas gdy stary wpis zostaje dla starszych urządzeń. Przeczytaj wyjście statusu demona, żeby zobaczyć, którego zestawu faktycznie użyło każde połączenie. Potem usuń przypięcie po stronie klienta, gdy nowoczesna para zostanie potwierdzona. Podniesiony tunel to za mało dowodów, bo może się podnieść na zestawie, który próbowałeś wycofać. Dokumentacja strongSwana dotycząca IKEv2 opisuje składnię propozycji i znacznik strict.