Wykrywanie martwego peera IKEv2 nie testuje Twojej aplikacji

Kontrola żywotności IKEv2 zadaje jedno pytanie: czy drugi peer nadal odpowiada w chronionej relacji sterującej. Nie mierzy, czy wewnętrzna aplikacja jest zdrowa, czy za bramką istnieje trasa ani czy przeglądanie wydaje się szybkie. Kontrola może przejść, podczas gdy wszystko użyteczne za tunelem zawodzi.

Przeczytaj oba rodzaje dowodów osobno, zanim zmienisz timer.

O co naprawdę pyta kontrola żywotności

Wymiana żywotności jest wysyłana w ustanowionym stowarzyszeniu bezpieczeństwa IKE i oczekuje odpowiedzi w skonfigurowanym oknie. Sukces oznacza że implementacja IKE peera nadal tam jest i nadal chce rozmawiać. Nie mówi nic o podrzędnych stowarzyszeniach bezpieczeństwa, które przenoszą ruch, nic o routingu za bramką i nic o usłudze, dla której otworzyłeś tunel. To trzy osobne pytania z trzema osobnymi trybami awarii.

Ta różnica decyduje, gdzie patrzeć, gdy sesja cichnie. Peer, który odpowiada dalej, gdy ścieżka danych jest zepsuta, wskazuje na politykę, routing lub usługę poniżej. Peer, który przestaje odpowiadać, wskazuje na osiągalność lub na własny stan drugiego końca.

Przeczytaj stowarzyszenia bezpieczeństwa przed przeglądarką

Stan sterowania i stan danych są wymieniane osobno, gdy zapytasz demona, a liczniki mówią, czy w ogóle czegoś próbowano. Podrzędne stowarzyszenie, które nigdy nie zostało zainstalowane, wygląda zupełnie inaczej niż takie, które zainstalowano, a potem przestało przepuszczać pakiety, choć oba dają tę samą skargę użytkownika.

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

Zapisz nazwy stanów dosłownie w zgłoszeniu, razem z licznikami w chwili skargi. Opis typu tunel padł ukrywa, które z dwóch stowarzyszeń się zakończyło, i zwykle to jedyny fakt, który warto mieć.

Awaria trasy wygląda dokładnie jak martwy peer

Bramka może odpowiadać na wymiany sterujące, gdy prywatny serwer jest offline, brakuje przekierowanej trasy albo wewnętrzne rozwiązywanie nazw zawodzi całkowicie. Z punktu widzenia klienta każdy z tych przypadków wygląda jak sesja, która działa, i cel, który nie działa. Sprawdź ścieżkę powrotną tak samo starannie jak ścieżkę w przód, ponieważ asymetryczny routing po drugiej stronie daje ciszę tylko w jednym kierunku.

Testuj zamierzoną aplikację bezpośrednio i nazwij adres, którego próbowała, zamiast sprawdzać, czy tunel działa. Ping do bramki dowodzi, że bramka odpowiada; nigdy nie dowiódł, że odpowiedziała aplikacja. Zapisz dokładny adres, którego próbowała aplikacja. Ten ciąg zawęża późniejsze poszukiwania i jest jedynym faktem, który zgłoszenie zwykle pomija.

Trzymaj timery z dala od diagnozy

Skrócenie interwału wykrywania nie jest zmianą wydajności i nie dodaje przepustowości. Przy utracie pakietów zmienia, jak szybko awaria zostaje rozpoznana, co może sprawić, że objaw wygląda inaczej, nie poprawiając niczego. Najpierw zapisz rzeczywisty czas awarii, potem zdecyduj, czy tolerancja jest zła dla łącza, które naprawdę masz.

Odświeżanie mapowania NAT należy do tej samej kategorii. Utrzymuje przetłumaczoną ścieżkę w użyciu i nie jest dowodem, że zdalna aplikacja działa.

Pełna polityka odzyskiwania mówi, co klient ma zrobić, gdy peer zostanie uznany za martwego: uruchomić ponownie, zamknąć czy wstrzymać, i co może robić inny ruch, gdy to się dzieje. Bez tego ten sam incydent jest diagnozowany od zera co kwartał.