Dlaczego polityka bezpieczeństwa IPsec nie jest wpisem w tabeli routingu

Wyślij ping do 10.20.0.5 przez tunel i nic nie wraca, choć tabela routingu upiera się, że ta podsieć jest osiągalna. Routing i IPsec odpowiadają na różne pytania, a tylko jedno z nich dotyczy osiągalności. Wyszukanie w przód wybiera ścieżkę, potem baza polityki bezpieczeństwa decyduje, czy tę ścieżkę trzeba chronić, zostawić bez zmian czy odrzucić. Gdy te dwa się nie zgadzają, pakiet ginie po cichu, więc czytaj je w tej kolejności.

Zacznij od wyszukania, nie od tabeli

Zapytaj jądro, co naprawdę by zrobiło: ip route get 10.20.0.5 wypisuje wybraną trasę, interfejs wyjściowy i adres źródłowy, którego by użyło. Prefiks, reguła polityki, znacznik lub preferowane źródło mogą zmienić tę odpowiedź, dlatego wyszukanie na żywo bije czytanie tabeli na oko.

Testuj cel wewnątrz chronionego zakresu, a nie adres bramy. Dotarcie do bramy po drugiej stronie dowodzi tylko, że jakaś trasa istnieje; nic nie mówi o podsieci, której naprawdę potrzebujesz. Potem potwierdź, że interfejs wybrany przez wyszukanie to ten, którego oczekujesz od tunelu.

Dopasuj selektory po obu stronach

Baza polityki ma własne wpisy, a każdy z nich podaje kierunek, źródło, cel i protokół, a potem mówi, co ma się stać z pasującymi pakietami. Użyj ip xfrm policy, aby je wylistować; flagi pokazują, czy akcja to ochrona, obejście czy blokada. Polityka, której selektory są szersze lub węższe niż twój przepływ testowy, nie dopasuje się do niego, a pakiet wychodzi niechroniony. To właśnie ta usterka, której szukasz, a nie brakująca trasa.

Porównaj rzeczywiste wartości: źródło, cel, protokół i porty. Jeśli wyszukanie rozwiązało jedną parę adresów, a wpis polityki obejmuje inną, oba widoki opisują inny ruch. Uruchom oba ponownie z tym samym krotem, zanim wyciągniesz wniosek, inaczej zmodyfikujesz politykę, która nigdy nie była na ścieżce.

Dopasowanie polityki nie jest zainstalowanym stanem

Pasująca polityka mówi tylko, że pakiet musi być chroniony; jądro nadal potrzebuje asocjacji bezpieczeństwa, aby wykonać ochronę. Wylistuj je za pomocą ip xfrm state, lub za pomocą swanctl --list-sas, gdy negocjuje strongSwan, i przeczytaj selektory oraz liczniki każdego wpisu.

Gdy polityka pasuje, a żadna asocjacja nie obejmuje tych samych selektorów, pakiet jest odrzucany, zamiast wysyłany otwartym tekstem. To jest odrzucenie, którego trzeba szukać, gdy tunel działa, ale jedna podsieć zawodzi. Liczniki mówią resztę: asocjacja, która nigdy nie rośnie, nigdy nie została wybrana, a ta, która rośnie i mimo to kończy się odrzuceniem, wskazuje na stronę zdalną. Naprawa selektorów i odświeżenie kluczy to różne naprawy, więc zdecyduj, której potrzebujesz, zanim dotkniesz konfiguracji.

Czego tunel oparty na trasie nadal wymaga

Interfejs XFRM sprawia, że tunel wygląda jak urządzenie, do którego można routować, co jest naprawdę przydatne. Nie usuwa jednak polityki i stanu, które decydują, co się dzieje, gdy pakiet tam dotrze. Trasa wnosi następny skok i nic więcej.

Jeśli urządzenie istnieje, a trasa wskazuje do niego, podczas gdy żadna asocjacja nie pasuje do wewnętrznych selektorów, pakiet jest odrzucany, i żadna ilość edycji tras nie tworzy kluczy ani selektorów. Sprawdź interfejs z tym samym źródłem i celem, które routowałeś, a potem porównaj to z listą stanów.

Ustal własność, zanim cokolwiek zmienisz

Zapora sieciowa hosta dodaje trzecią decyzję, o której żadna z dwóch baz nie wie. Poprawna trasa plus pasująca polityka plus zainstalowana asocjacja nadal mogą skończyć się odrzuconym pakietem, a aplikacja zgłasza tylko przekroczenie czasu. Potwierdź, że zapora przepuszcza chroniony ruch, zanim obwinisz IPsec. Przechwycenie na urządzeniu tunelu i na interfejsie fizycznym pokazuje, po której stronie szyfrowania pakiet zniknął.

Własność konfiguracji decyduje, czy twoja poprawka przetrwa restart. Jeden komponent może instalować stan, podczas gdy inny zarządza trasami, a ręczna zmiana w drugim jest nadpisywana przy następnym podniesieniu tunelu. Zmień konfigurację właściciela, a potem przeczytaj oba widoki ponownie; RFC 4301 utrzymuje dwie bazy osobno, gdy musisz wyjaśnić ten podział komuś innemu.