IKEv2 NO_PROPOSAL_CHOSEN: który etap odrzucił zestaw?

NO_PROPOSAL_CHOSEN w logu kieruje ludzi do wstępnie współdzielonego klucza, a błąd przeżywa tę zmianę. To nigdy nie był problem poświadczeń: peer odrzucił każdą propozycję oferowaną dla tej wymiany, co jest stwierdzeniem o algorytmach, a nie o tożsamości. Pierwsze użyteczne pytanie nie brzmi, który algorytm edytować, ale która wymiana została odrzucona. Odpowiedz na to, zanim cokolwiek porównasz. Następnie porównaj pełny zestaw oferowany z pełnym zestawem, który peer dopuszcza.

Najpierw: która wymiana została odrzucona

IKEv2 negocjuje dwa rodzaje asocjacji. IKE SA chroni samo negocjowanie, a CHILD SA chroni ruch. Każda ma własny zestaw propozycji i każda może zawieść z tym samym powiadomieniem. Odrzucenie podczas początkowej negocjacji IKE i odrzucenie podczas negocjacji CHILD wymagają różnych poprawek, a log zwykle nazywa wymianę wiersz lub dwa powyżej powiadomienia. Czytaj te dwa wiersze razem, inaczej edytujesz niewłaściwą listę propozycji.

Samo powiadomienie nie identyfikuje wymiany. Wiersz powyżej nazywa negocjowane SA, a ta nazwa wskazuje listę propozycji do sprawdzenia.

Porównuj pełne zestawy, nie pojedyncze słowa kluczowe

Propozycja to kombinacja: algorytm szyfrowania, integralność lub AEAD, grupa wymiany kluczy i dowolna funkcja pseudolosowa. Porównywanie tylko nazwy szyfrowania to zwykły błąd, ponieważ dwa peery mogą zgodzić się co do AES-256 i nadal różnić się co do SHA-1 wobec SHA-256. Zapisz zestawy oferowany i dozwolony obok siebie na nieudanym etapie, a następnie szukaj pustego przecięcia.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

Sprawdź też, czy obie implementacje obsługują to, co skonfigurowałeś. Nazwa skopiowana z innej platformy może wyglądać znajomo składniowo podczas gdy wtyczka lub implementacja całkowicie brakuje.

Zestaw IKE i zestaw ESP to różne obiekty

Edycja propozycji IKE nie naprawi odrzuconej propozycji CHILD i odwrotnie. W strongSwan to osobne ustawienia, mniej więcej proposals = aes256-sha256-modp2048 dla IKE SA i osobna lista ESP dla CHILD SA. Zmień listę odpowiadającą nieudanej wymianie, a potem przeczytaj log ponownie, zamiast zakładać, że poprawka zadziałała.

Dla CHILD SA odpowiednim ustawieniem jest lista propozycji ESP, a nie lista IKE. Skopiowanie do niej wiersza IKE tworzy konfigurację, która się parsuje, ale negocjuje niewłaściwy obiekt.

Działający tunel, który zawodzi przy odświeżaniu klucza

Jeśli tunel działał godzinę, a potem zawiódł, początkowa negocjacja nie jest problemem. Odświeżenie klucza może sprawdzić inne warunki: inną grupę wymiany kluczy po pierwszej wymianie, niezgodność czasu życia między peerami lub zmienioną politykę respondera. Zachowaj znacznik czasu odświeżenia i identyfikatory asocjacji z obu stron. Taki wzorzec wymaga porównania propozycji przy odświeżaniu, a nie dłuższego limitu czasu. Zmiana limitu czasu ukrywa objaw i pozostawia niezgodność na miejscu.

ipsec statusall pokazuje każdą asocjację i faktycznie wynegocjowane algorytmy. To wyjście jest najszybszym sposobem potwierdzenia, której listy użyto, i oddziela błąd konfiguracji od starego tunelu, który nigdy nie został ponownie wynegocjowany.

ipsec statusall | grep -E "IKE:|ESP:"

Wybierz przecięcie, a następnie potwierdź obie fazy

Poproś administratora o wybranie udokumentowanego nowoczesnego przecięcia obsługiwanego przez oba peery i zapisanie go. Nie rozwiązuj błędu przez włączenie wszystkich starych algorytmów ani przez wyłączenie weryfikacji tożsamości, ponieważ żadne z nich nie wynika z odrzucenia. Po zmianie ustanów nowe połączenie, a następnie wymuś odświeżenie klucza. Samo pierwsze połączenie nie dowodzi, że ścieżka odświeżania działa.

Zachowaj zaakceptowaną kombinację wraz z wersjami oprogramowania układowego. Jeśli następny błąd dotyczy selektorów ruchu, potraktuj go osobno, ponieważ zgoda co do kryptografii nic nie mówi o tym, które podsieci chroni tunel. strongSwan dokumentacja propozycji obejmuje składnię obu list.