IKE SA ustanowione, CHILD SA brakuje: gdzie zatrzymują się dane

Klient twierdzi, że uwierzytelnienie się powiodło, stan IKE wygląda dobrze, a liczniki pakietów stoją na zero. Ta kombinacja nie jest sprzecznością: IKEv2 utrzymuje relację sterowania i relację danych oddzielnie, i pierwsza może się udać, podczas gdy druga nigdy nie wstanie. Rodzic prowadzi negocjacje; dziecko obsługuje ruch. Przeczytaj obie warstwy osobno, zanim nazwiesz tunel martwym.

Co robią oba SA

IKE SA to relacja sterowania: uwierzytelnia strony i przenosi wymiany, które negocjują, zastępują i usuwają ochronę. Nigdy nie przenosi pakietów twojej aplikacji. Zdrowy rodzic dowodzi więc tylko, że oba końce mogą się zgodzić co do polityki bezpieczeństwa, i niczego więcej.

CHILD SA to relacja danych, utworzona pod rodzicem, z selektorami ruchu i materiałem klucza dla jednego chronionego zbioru. Jest kierunkowa, więc wyjście statusu wymienia asocjację przychodzącą i wychodzącą z osobnymi identyfikatorami i zwykle osobnymi licznikami dla każdego kierunku. Ta para jest powodem, dla którego jeden kierunek może działać, a drugi pada, i dlaczego zdanie tunel jest podniesiony nic nie mówi o ruchu. Jeden rodzic może też trzymać kilka dzieci, i tak jedna etykieta połączenia ukrywa to, którego potrzebujesz.

Czytaj wpisy dziecka, nie etykietę połączenia

Otwórz razem status rodzica i listę dzieci i znajdź dziecko, którego selektory pasują do testowanego przepływu. Zanotuj jego selektory ruchu, wynegocjowane algorytmy, czas życia i liczniki w obu kierunkach. Jeśli dzieci jest kilka, dopasowuj po selektorach, a nie po pozycji, bo pozycja zmienia się po odnowieniu klucza. Zapisz identyfikatory, zanim cokolwiek zmienisz.

Jeśli rodzic wymienia inny zbiór ruchu niż testowany, czytasz niewłaściwe dziecko. To problem selektorów, a nie zepsuty tunel.

Zapisuj też znaczniki czasu. Odnowienie klucza może zastąpić jedną warstwę, podczas gdy druga pozostaje ustanowiona, a dziecko, które wygląda na nowe, może być zamiennikiem tego, które obserwowałeś. Porównaj identyfikatory, zanim uznasz, że dziecko zniknęło.

Gdy nie ma żadnego dziecka

Uwierzytelnienie może się udać, podczas gdy propozycja danych lub selektory zawiodą, i wtedy rodzic zostaje całkiem bez dziecka. Zwykłą przyczyną jest niezgodność algorytmów lub niezgodność selektorów ruchu, a obie strony logują odrzuconą propozycję. Czytaj oba końce, bo strona, do której docierasz, może pokazywać tylko odrzucenie. Napraw niezgodność, zamiast restartować rodzica, bo to powtarza tę samą nieudaną negocjację i dokłada do dowodów kolejną przerwę.

Rodzic, który wciąż ustanawia się od nowa, to inna awaria niż rodzic, który stoi bez dziecka. W drugim przypadku logi nazywają odrzuconą propozycję, więc zbierz tę propozycję z obu końców, zanim zmienisz politykę.

Gdy dziecko istnieje, ale liczniki stoją na zero

Wyślij świeże żądanie zgodne z selektorami dziecka. Żądanie do celu poza tą polityką nie ruszy jego liczników, choćby wyglądało na udane.

Sprawdź trasę, która powinna wpchnąć przepływ do tunelu, bo dziecko bez ruchu to często dziecko, do którego nic nie jest routowane. Liczniki ruszające się tylko w jednym kierunku wskazują na niezgodność selektorów lub polityki na drodze powrotnej. Spójrz na selektory powrotne zdalnego peera, zanim dotkniesz strony lokalnej. Świeże żądanie daje też znacznik czasu do porównania z wyjściem statusu obu końców.

Nazwij warstwę w raporcie

Zgłoś awarię jako trzy pola, a nie werdykt: warstwę, która zawiodła, wymianę lub dziecko, które sprawdziłeś, oraz dowód, który masz. Warstwa jest jedną z trzech: rodzic nigdy się nie ustanowił, negocjacja dziecka została odrzucona albo dziecko istnieje i ruch do niego nie dociera. Dowodem jest identyfikator dziecka z jego selektorami i licznikami albo odrzucona propozycja zacytowana z obu logów. Każdy, kto to czyta, może od razu przejść do wymiany, która ma znaczenie, zamiast pytać, o który VPN chodzi.

dokumentacja strongSwan IKEv2 pokazuje, jak te warstwy wyglądają w wyjściu statusu. Dołącz wyjście dziecka, które testowałeś, a nie tylko podsumowanie rodzica.