Dlaczego zajęty tunel IPsec wcześnie odnawia klucze: limity czasu i wolumenu

Mniej więcej co pięćdziesiąt minut tunel na zajętym łączu spada na kilka sekund, a pierwszym podejrzanym jest zegar. Asocjacje mogą kończyć się na limicie czasu lub na liczbie bajtów, i która granica nadejdzie pierwsza, ta je wysyła na emeryturę. Na łączu przenoszącym rzeczywisty ruch limit wolumenu może zadziałać długo przed upływem skonfigurowanej godziny. Więc „za wcześnie” to stwierdzenie o zegarze, a nie o asocjacji.

Licz to, co liczy asocjacja, a nie interfejs

Suma bajtów interfejsu, łączna przepustowość pulpitu i własny licznik asocjacji to trzy osobne liczby, a tylko jedna z nich jest porównywana z limitem. Rejestruj asocjację przychodzącą i wychodzącą osobno wraz z ich identyfikatorami, aby zmiana kluczy dotykająca jednego kierunku pojawiła się jako zdarzenie kierunkowe, a nie zagadka. Licznik asocjacji także zaczyna się od nowa przy zmianie kluczy, dlatego suma pobrana z interfejsu rośnie, podczas gdy istotna wartość jest resetowana.

Obliczenie warto wykonać raz, aby rząd wielkości przestał wydawać się dowolny. Zliczony budżet jednego gibibajta zużywany w stałym tempie 128 mebibajtów na minutę wyczerpuje się w osiem minut, i jest to przeliczenie jednostek, a nie pomiar twojego tunelu. Jeśli wynikowa liczba leży znacznie poniżej limitu czasu, mechanizmem jest wolumen i żadne patrzenie na zegar nie wyjaśni odstępu. Jeśli leży znacznie powyżej, limit bajtów nie jest twoim wyzwalaczem i poszukiwania należą gdzie indziej.

Miękki i twardy próg to dwa różne zdarzenia

Miękki próg prosi o zastąpienie długo przed tym, jak twardy limit zakończy asocjację, a implementacje dokładają własne marginesy i losowość ponad to, co skonfigurowałeś. Dlatego zaobserwowany odstęp prawie nigdy nie jest okrągłą liczbą. architektura IPsec opisuje czasy życia wyrażone w czasie i liczbie bajtów z dwoma rodzajami progów, i obowiązuje wcześniejsze wygaśnięcie. Jeśli potraktujesz jeden wydrukowany czas życia jako harmonogram, pomylisz się o wielkość marginesu.

Odczytaj efektywną politykę ze stanu działania, zamiast wnioskować ją z liczby w pliku, ponieważ margines należy do implementacji, a nie do twojej intencji. Oprzyj się pokusie rozciągnięcia limitów do ich maksimum, aby uciszyć objaw: tunel, który odnawia klucze zgodnie z harmonogramem, zachowuje się tak, jak zaprojektowano, a dłuższy czas życia tylko odkłada zdarzenie, utrzymując skompromitowany klucz dłużej użytecznym. Gdy sama wymiana zawodzi, limit jest posłańcem, a nie winą.

Odczytaj efektywny czas życia ze stanu działania

Na strongSwan swanctl --list-sas wypisuje podsumowanie asocjacji wraz z czasami zmiany kluczy i życia, więc wartość, którą demon zamierza egzekwować, jest widoczna bez zgadywania. Na hoście Linux bez widoku demona ip xfrm state zgłasza skonfigurowane miękkie i twarde limity bajtów i pakietów obok bieżących liczników. Oba odczyty odpowiadają na różne pytania i oba warto zachować w zgłoszeniu.

swanctl --list-sas
ip -s xfrm state

Porównaj wydrukowany miękki próg z zmierzonym odstępem, ponieważ zastąpienie zaczynające się z marginesem poniżej twardego limitu jest normalne, a takie, które nigdy się nie zaczyna, nie jest. Jeśli demon pokazuje jeden czas życia, a stan jądra inny, patrzysz na dwie niezgodne warstwy, i to samo w sobie jest ustaleniem.

Obserwuj wymianę, która zastępuje SA

Trzymaj trzy odnowienia osobno, ponieważ zawodzą w różny sposób: zmiana kluczy IKE SA buduje nową asocjację kontrolną, zmiana kluczy CHILD SA zastępuje asocjację danych, a ponowna uwierzytelnienie powtarza wymianę tożsamości. W IKEv2 każda strona decyduje o własnych czasach życia, zamiast negocjować jedną wspólną wartość, więc wymiana, której nie zainicjowałeś, jest zwyczajna. Niezgodność perfect forward secrecy jest częstą przyczyną śmierci nowej child SA dokładnie w odstępie zmiany kluczy, i wygląda dokładnie jak awaria timera, dopóki ktoś nie przeczyta propozycji.

Porównaj starą asocjację z jej następczynią i z wymianą, która ją wytworzyła. Zniknięcie identyfikatora to rutynowe zastąpienie; odrzucona propozycja, brakująca odpowiedź lub brak użytecznego stanu następcy to inne zdarzenie z innym właścicielem. Zachowaj te dowody, zanim cokolwiek zmienisz, ponieważ notatki specyficzne dla wersji, propozycja partnera i wynegocjowane czasy życia są tym, co czyni sprawę czytelną tydzień później, po rotacji logów.

Udowodnij odnowienie, zamiast je ukrywać

Zaakceptuj wdrożenie, przechodząc przez zaplanowane odnowienie, a nie przez takie, które ci się przytrafia. Wymuś jedną zmianę kluczy w oknie konserwacji, a następnie potwierdź, że oba kierunki przenoszą dane, a wynik aplikacji jest niezmieniony, nie tylko to, że wskaźnik tunelu jest zielony. Zapisz, który limit zadziałał i która wymiana była zaangażowana.

Wniosek o takim kształcie wytrzymuje kontrolę, natomiast zmieniona wartość timera, która sprawiła, że połączenie wyglądało spokojnie przez popołudnie, nie. Jeśli przesunął się tylko timer, dowody przesunęły się razem z nim.