Dlaczego twój tunel IPsec działa do pierwszego odnowienia klucza CHILD SA

Tunel wstał, ping odpowiedział i wszyscy podpisali. Cztery godziny później sesja pada, strony zapisują błąd propozycji lub wymiany kluczy, a pierwsze przypuszczenie jest takie, że coś zmieniło się w sieci. Nic się nie zmieniło. Tunel, który przenosi ruch, udowodnił, że dwie strony zgadzają się co do sposobu uwierzytelniania i ochrony pierwszej asocjacji podrzędnej, a nie udowodnił niczego o wymianie kluczy, której będą wymagać przy odnowieniu. Niezgodność siedzi w luce między tymi dwoma zdarzeniami.

Połączenie nie oznacza, że ustawienia PFS są zgodne

W IKEv2 pierwsza asocjacja podrzędna powstaje podczas wymiany uwierzytelniającej, a jej klucze są wyprowadzane z materiału, który asocjacja IKE już wytworzyła. Dla tej asocjacji podrzędnej nie odbywa się osobna wymiana Diffie-Hellmana, więc polityka wymagająca jej przy odnowieniu nie jest sprawdzana przy podnoszeniu.

Odnowienie to inna wymiana. Gdy klucz asocjacji podrzędnej jest odnawiany, strony mogą wykonać świeżą wymianę kluczy z grupą wskazaną w swoich propozycjach, i to jest pierwszy moment porównania ustawień grupy. Dwie niezgodne strony mogą więc uwierzytelnić się, zainstalować asocjację podrzędną i przepuścić ruch, a potem ponieść porażkę przy odnowieniu.

Gdzie kryje się niezgodność w łańcuchu propozycji

W strongSwan grupa jest dołączana do propozycji podrzędnej, dlatego ciąg taki jak aes256gcm16-prfsha256-ecp256 wygląda jak wybór szyfrowania, ale niesie też wymóg wymiany kluczy. Strona oferująca tylko aes256gcm16-prfsha256 nie ma takiego wymogu, a obie listy pokrywają się w szyfrowaniu, różniąc się w wymianie.

Czytaj propozycję podrzędną i propozycję IKE jako osobne listy. Grupa widoczna na liście IKE nic nie mówi o liście podrzędnej, a edytowanie jednej przy czytaniu drugiej to zwykły sposób przeoczenia tego.

Czytaj awarię, nie plik, który edytowałeś

Znajdź notify, który zakończył wymianę. Odnowienie klucza podrzędnego zwracające „brak akceptowalnej propozycji” wskazuje na listy propozycji; żądanie odnowienia, które nigdy nie dostaje odpowiedzi, wskazuje na ścieżkę albo na stronę, która przestała nasłuchiwać. Te dwa wymagają różnych poprawek, a sformułowanie wiersza logu je rozdziela.

Potwierdź konfigurację działającą, a nie tę na dysku. Plik zapisany, ale niezaładowany, albo połączenie odczytane ponownie z innego include, dadzą niezgodność, której nie naprawi żadna edycja widocznego pliku.

Trzy zdarzenia, które wszystkie nazywa się odnowieniem klucza

Odnowienie klucza asocjacji IKE, ponowne uwierzytelnienie IKE i odnowienie klucza asocjacji podrzędnej to osobne operacje z osobnymi regułami propozycji. Awaria zgłoszona przy jednej z nich nic nie mówi wprost o pozostałych, a log, który je miesza, czyta się jak jeden powracający defekt, choć są trzy.

Zauważ, które zdarzenie nazywa strona, potem sprawdź propozycje tylko dla tego zdarzenia. Zmień jedną listę, przeładuj i wymuś ponownie to samo zdarzenie. Jeśli log nazywa ponowne uwierzytelnienie, czytać trzeba propozycję IKE. Jeśli nazywa odnowienie klucza podrzędnego, propozycja podrzędna niesie ważną grupę.

Wyłączenie odnowienia nie jest naprawą

Ustawienie czasu odnowienia klucza na zero tłumi wymianę, która zawodzi, a tunel żyje potem aż do rozbiórki albo restartu strony. To, co kupiłeś, to dłużej żyjący klucz i niezgodność, która spotka cię ponownie przy migracji, audycie albo aktualizacji dostawcy. To samo dotyczy okresów ważności rozciągniętych daleko poza politykę, której oczekuje druga strona.

Zamiast tego wyrównaj propozycje. Wybierz grupę, którą implementują obie strony, wpisz ją do propozycji podrzędnej na obu końcach i trzymaj politykę odnowienia w zakresie, którego organizacja naprawdę wymaga.

Udowodnij to wymianą, która zawiodła

Skróć czas odnowienia klucza podrzędnego w oknie serwisowym, żeby zdarzenie przyszło w minutach, a nie godzinach, albo wyzwól ręczne odnowienie. Potem obserwuj udane odnowienie i potwierdź, że ruch nadal przez nie przechodzi, bo nowy uścisk dłoni, który instaluje asocjację podrzędną, ale gubi przepływ aplikacji to inny defekt.

Potem przywróć normalny okres ważności i zachowaj oba zapisy zdarzeń, nieudany i udany. Dowód, którego chcesz, to że połączenie przeżywa własny cykl życia, a nie że przeżyło ping.