IKEv2: odświeżanie kluczy a ponowne uwierzytelnianie — dlaczego połączenie pada później

Tunel wstaje rano i działa godzinami. Potem pada, łączy się ponownie po jednej próbie i następnego dnia robi to samo. W sieci nic się nie zmieniło i nikt nie dotknął hasła. Sesje, które zawodzą na granicy odświeżania, zwykle przekraczają jedną z dwóch różnych operacji, a tylko jedna z nich ponownie sprawdza twoje dane logowania. Odczytanie, która zadziałała, to cała diagnoza.

Dwie operacje, które z zewnątrz wyglądają podobnie

Odświeżanie kluczy zastępuje asocjacje bezpieczeństwa lub materiał kluczy w ramach wymiany zdefiniowanej przez protokół. Uwierzytelnianie nie jest powtarzane, więc tożsamość przyjęta na początku sesji jest po prostu przenoszona dalej.

Ponowne uwierzytelnianie idzie dalej: ustanawia nową uwierzytelnioną relację, co oznacza, że dane logowania są oceniane od nowa. Wszystko, co wygasło, zostało odwołane lub zmienione w katalogu, staje się widoczne w tej chwili.

Co tak naprawdę zastępuje odświeżanie kluczy

IKEv2 utrzymuje dwa rodzaje asocjacji o osobnych cyklach życia. IKE SA chroni kanał sterowania, a CHILD SA chronią rzeczywisty ruch. Odświeżenie jednej nie jest synonimem ponownego połączenia klienta.

Ten podział wyjaśnia znany schemat: ruch płynie dobrze, potem asocjacja CHILD SA zostaje odświeżona i propozycja już nie pasuje, bo ktoś tygodnie wcześniej zmienił fazę 2 po jednej stronie. Zmiana leżała tam nieszkodliwie, dopóki odświeżenie jej nie sprawdziło.

Niezgodności czasu życia zachowują się tak samo. Strona, która pierwsza osiągnie swój limit, rozpoczyna wymianę, a druga musi ją przyjąć.

Co ponowne uwierzytelnianie ocenia od nowa

Przy ponownym uwierzytelnianiu certyfikat klienta, który był ważny przy logowaniu, może już wygasnąć. Odwołane dane logowania, zmienione hasło lub niedostępny drugi czynnik wychodzą tutaj, a nie w momencie odświeżania.

Dlatego wydłużanie każdego czasu życia wygląda jak poprawka i nią nie jest. Odłożyłeś sprawdzenie zamiast je przejść. Następne odświeżenie przychodzi z tym samym defektem i krótszym oknem przerwy, by to zauważyć.

Niektóre implementacje nakładają stary i nowy stan podczas ponownego uwierzytelniania. Inne tworzą krótką lukę. Dlatego identyczne ustawienia u dwóch dostawców mogą dawać różne doświadczenia użytkownika. Testuj zachowanie, zamiast zakładać, że standard je narzuca.

Przeczytaj znaczniki czasu, zanim cokolwiek zmienisz

Uchwyć moment awarii wraz ze stanem asocjacji przed i po. Jeśli stara asocjacja została zastąpiona bez wymiany uwierzytelniania, byłeś na granicy odświeżania. Jeśli bezpośrednio przed awarią pojawia się wymiana AUTH, byłeś przy ponownym uwierzytelnianiu.

strongSwan udostępnia to jako osobne ustawienia: rekey steruje odświeżaniem kluczy, reauth steruje tym, czy następuje nowe uwierzytelnienie, a wartości margin decydują, jak długo przed wygaśnięciem zaczyna się każde z nich. dokumentacja odświeżania kluczy opisuje tę interakcję i warto ją przeczytać, zanim skopiujesz czas życia z postu na forum.

Odróżnij to wszystko od zwykłej utraty sieci. Zerwane łącze daje zdarzenie wykrycia martwego peera lub burzę retransmisji, a nie czystą wymianę z pasującymi propozycjami.

Zmień to, co zawiodło

Odrzucenie danych logowania wymaga naprawy problemu tożsamości: odśwież certyfikat, przywróć konto, zarejestruj ponownie czynnik. Niezgodność propozycji lub czasu życia wymaga porównania parametrów po obu stronach.

Rozciąganie czasów życia, by uniknąć objawu, to jedyna opcja, która zawsze wygląda, jakby zadziałała, i nigdy nie działa.

Przetestuj kontrolowane odświeżenie

Wymuś odświeżenie, zamiast czekać na nie dzień. Potem powtórz z ponownym uwierzytelnianiem, jeśli wdrożenie je obsługuje, i obserwuj oba końce.

Udane pierwsze logowanie nie ćwiczy niczego z tego. Cykl życia po nim to miejsce, w którym te wdrożenia naprawdę się psują.