Co wchodzi w skład propozycji IPsec? Pola IKE i ESP

IKE startuje, obie strony ogłaszają AES, a tunel i tak zawodzi z NO_PROPOSAL_CHOSEN. Dziennik nazywa propozycję, ale nie pole, które się nie zgadzało. Propozycja to jedna kompletna oferta, a jedno niezgodne pole unieważnia całą kombinację, a nie tylko ten wiersz. Czytanie jej jako worka niezależnych wyborów algorytmów jest zwykłym powodem, dla którego niedopasowanie pozostaje niewidoczne.

Dwie negocjacje z osobnymi listami propozycji

IKEv2 buduje dwie asocjacje bezpieczeństwa. Pierwsza to IKE SA, która chroni samą wymianę kontrolną, a druga to CHILD SA, która przenosi ruch przez ESP. Każda ma własną listę propozycji, a strona może przyjąć jedną i odrzucić drugą.

Ten podział wyjaśnia częste zamieszanie: działająca IKE SA dowodzi tylko, że algorytmy kanału kontrolnego się zgadzały. Jeśli propozycja CHILD zawiedzie, tunel nie przeniesie ani jednego pakietu, choć pierwsza faza jest zakończona, a dzienniki u góry wyglądają zdrowo.

Kolejność wewnątrz każdej listy też ma znaczenie. Odpowiadający wybiera z uporządkowanych ofert inicjatora, więc przeniesienie szeroko zgodnego wpisu nad wąski zmienia to, który zestaw zostanie zainstalowany, nie zmieniając ani jednej nazwy algorytmu. Zablokuj tę kolejność w konfiguracji, zamiast polegać na wartościach domyślnych. Stabilna kolejność czyni też porównywanie dzienników między lokalizacjami sensownym.

Które pola należą do której propozycji

Zestaw pól jest niewielki, ale nie jest identyczny w obu negocjacjach. Czytaj tabelę wiersz po wierszu, ponieważ pole w jednej kolumnie może nie występować w drugiej. Składnia różni się w zależności od implementacji; dokumentacja propozycji strongSwan jest jednym konkretnym odniesieniem.

Pole szyfrowania nazywa szyfr i, w większości składni, długość jego klucza. Pole integralności nazywa hash używany do uwierzytelnienia tekstu zaszyfrowanego, a PRF nazywa funkcję wyprowadzającą materiał klucza dla IKE SA. Grupa DH ustanawia świeży wspólny tajny materiał, dlatego pojawia się po obu stronach, ale w różnych celach.

Rozszerzone numery sekwencji należą tylko do ścieżki danych. Poszerzają przestrzeń sekwencji i są negocjowane jako część propozycji CHILD, więc niedopasowanie tam odrzuca ofertę CHILD, pozostawiając IKE SA nietkniętą.

Jak wybierana jest jedna kompletna oferta

Każda propozycja jest zbiorem, a odpowiadający szuka zbioru, w którym każde wymagane pole jest dopuszczalne. Dwie listy mogą obie zawierać AES i SHA-256 i wciąż nie mieć żadnego zgodnego wpisu, bo różni się długość klucza, PRF lub grupa DH. Porównanie odbywa się per propozycja, a nie per algorytm.

Gdy nic nie pasuje, odpowiadający wysyła NO_PROPOSAL_CHOSEN z typem SA, który zawiódł. Przeczytaj, której listy propozycji dotyczy powiadomienie, zanim zmienisz konfigurację; zmiana algorytmów ESP, gdy propozycja IKE została odrzucona, marnuje jeden cykl debugowania.

Warto znać zachowanie wyboru, gdy dostrajasz profil. Niektóre implementacje wolą kolejność inicjatora, inne przestawiają według polityki lokalnej, dlatego zestaw, który działa między dwoma dostawcami, może zniknąć gdy odwrócisz stronę rozpoczynającą połączenie.

AEAD usuwa pole, zamiast je dodawać

AES-GCM i ChaCha20-Poly1305 uwierzytelniają i szyfrują w jednej operacji. Gdy któryś z nich zostanie wybrany dla ESP, algorytm integralności nie jest negocjowany osobno, ponieważ konstrukcja AEAD już go obejmuje. Dlatego propozycja łącząca AES-GCM z SHA-256 jest w najlepszym razie zbędna, a w najgorszym odrzucona.

PRF pozostaje osobny po stronie IKE, ponieważ wyprowadza klucze dla kanału kontrolnego, a nie chroni ładunku. Dlatego propozycja IKE może legalnie łączyć szyfr AEAD z PRF i grupą DH, podczas gdy odpowiadająca jej propozycja ESP wymienia tylko szyfr AEAD i opcjonalną grupę PFS.

Długość klucza jest częścią tokenu szyfrowania, więc AES-128-GCM i AES-256-GCM to różne oferty. Profil skopiowany z poradnika, który zakładał klucze 256-bit, nie dopasuje się do punktu końcowego skonfigurowanego na 128-bit, choć oba wiersze mówią AES-GCM. Dwie strony mogą zgodzić się co do rodziny szyfrów i nadal odrzucić się nawzajem z powodu liczby po myślniku.

Czytaj zainstalowaną SA, a nie konfigurację

Skonfigurowana lista propozycji jest ofertą; zainstalowana SA jest wynikiem. Na strongSwan i jądrze Linux dostępne są oba widoki:

sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policy

swanctl --list-sas wypisuje wynegocjowane algorytmy dla każdej SA, w tym czy CHILD używa AEAD. ip xfrm state pokazuje, co jądro faktycznie zainstalowało, i tam potwierdzasz, że odnowienie kluczy nie spadło na inny zestaw niż udokumentowany.

Zapisz te dane wyjściowe obok konfiguracji po poprawce. Gdy aktualizacja klienta zmieni wartości domyślne, zapisany zestaw daje punkt odniesienia do porównania, a porównanie wskazuje pole, które się przesunęło, zamiast zaczynać śledztwo od nowa.