IPsec z wieloma podsieciami gubi ruch powrotny? Policz reqid

Ruch opuszcza jedną lokalizację i nigdy nie wraca, obie bramy zgłaszają zakończone negocjacje, a jedyną wskazówką jest stos pakietów wychodzących bez odpowiedzi. Na punkcie końcowym Linux zwykłą przyczyną nie jest siła szyfrowania, MTU ani tablica routingu. To granularność wpisów polityki i numer, który wiąże każdą politykę z asocjacją bezpieczeństwa. Poniższa procedura czyta te dwie bazy, zanim cokolwiek innego zostanie tknięte.

Rozdziel objaw, zanim cokolwiek zmienisz

Awaria jednokierunkowa przy zakończonych negocjacjach IKE zawęża problem do ścieżki danych. Albo polityka wychodząca pasowała i odpowiedź została odrzucona, albo odpowiedź nigdy nie dotarła, bo druga strona nie miała czym jej wysłać. Z perspektywy aplikacji oba przypadki wyglądają identycznie, a bazy xfrm je rozróżniają.

Nie zaczynaj od MTU. Błędne MTU daje zacięcia i objawy fragmentacji, a nie czysty podział kierunku z rosnącymi licznikami wychodzącymi.

Przeczytaj bazę polityk i bazę stanów

W Linuksie o szyfrowaniu decydują wpisy polityki, więc pasująca polityka, a nie trasa, wprowadza pakiet do tunelu. Uruchom ip xfrm policy, aby zobaczyć selektory, kierunek, priorytet i szablon każdego wpisu, oraz ip xfrm state, aby zobaczyć ustanowione asocjacje z ich reqid. Polityka i asocjacja są połączone tym reqid.

Spójrz na wszystkie trzy kierunki. Wychodzący i przychodzący obejmują ruch do i od tego hosta; kierunek przekazywania ma znaczenie, gdy host routuje za innych. Brakujący lub niezgodny wpis w jednym kierunku wyjaśnia wynik jednokierunkowy bez żadnej usterki kryptograficznej.

Klasyczna asymetria: jeden reqid dla wielu podsieci

Częsta awaria pochodzi od partnera, który instaluje polityki dla wszystkich wynegocjowanych podsieci pod jednym reqid, co zdarza się z generate_policy require w racoonie. Ruch wychodzi wtedy przez asocjację ustanowioną ostatnio, podczas gdy druga strona trzyma osobną asocjację dla każdej podsieci. Odpowiedzi przychodzą na asocjację, której reqid nie wskazuje polityki, która powinna je przyjąć, a jądro odrzuca je po odszyfrowaniu.

Poprawka to zmiana konfiguracji, a nie reguła zapory: generate_policy unique; daje każdej polityce własny reqid, dzięki czemu asocjacje partnera na politykę mają pasujących partnerów. Zastosuj to, wynegocjuj ponownie i policz różne reqid dla oczekiwanych podsieci, zanim ogłosisz sukces.

Jeśli dwie podsieci nadal dzielą reqid, a druga strona oczekuje dwóch, znalazłeś asymetrię. Zapisz mapowanie, bo jest ono dowodem, że następna zmiana je naprawiła lub zachowała.

Selektory pochodzą z negocjacji, a nie z twojej konfiguracji

Chronione zakresy to to, na co zgodziły się oba końce, a nie to, o co prosiła jedna ze stron. Klient oferujący parę hostów wobec szerokiego zakresu zdalnego otrzymuje zawężoną wersję bramy i nie może jej poszerzyć. Czytaj zainstalowane selektory, a nie te z lokalnego pliku.

Gdy celem jest odwrotność, utrzymanie jednego celu poza tunelem, dodaj politykę obejścia z niższym numerem priorytetu, aby wygrała z automatycznie zainstalowanym wpisem. Polityka bez szablonu zezwala na tekst jawny, co czyni ją świadomym wyjątkiem dla rejestru zmian, a nie krokiem debugowania.

Sprawdzaj w tej kolejności i wiedz, jak się wycofać

Wypisz polityki dla każdej podsieci w obu kierunkach, w tym kierunek przekazywania, jeśli host routuje. Policz różne reqid i potwierdź jeden na politykę po stronie, która go oczekuje. Porównaj zainstalowane selektory z wynegocjowanymi. Po odnowieniu klucza ponownie odczytaj liczniki asocjacji, bo asocjacja, którą sprawdziłeś, może już zniknąć. Trasy sprawdź na końcu, ponieważ brakująca trasa do zdalnej podsieci daje podobny objaw jednokierunkowy przy czystych licznikach polityki.

Zanim zmienisz partnera, zapisz bieżące wyjście obu poleceń xfrm. Jeśli nowe ustawienie nie przywróci kierunku powrotnego, przywrócenie tego wyjścia jest szybszym wycofaniem niż odbudowa tunelu z pamięci i utrzymuje uczciwe porównanie.