SA podrzędna IPsec jest podniesiona, ale liczniki pakietów pozostają na zerze

Podniosłeś tunel, timer rekey liczy w dół, a oba kierunki nadal pokazują zero pakietów. Nic w tej parze liczb nie mówi, że peer odrzucił twój tunel: zainstalowana CHILD SA z bezczynnymi licznikami to normalny stan asocjacji, do której jeszcze nic nie pasowało. Zadanie polega na wykazaniu, że jakiś pakiet powinien był pasować, a potem na znalezieniu miejsca, w którym opuścił ścieżkę opisaną przez selektory. Zrób to raz, po kolei, i utrzymuj identyczne żądanie między przebiegami.

Co naprawdę dowodzi zerowy licznik

CHILD SA to para selektorów plus klucze i SPI, które szyfrują ruch mieszczący się w tych zakresach. Zainstalowanie jej oznacza tylko, że oba peery zgodziły się co do tych zakresów i wyprowadzonych kluczy; jądro będzie ją trzymać godzinami, nawet gdy nie przyjdzie ani jeden pakiet. Pytanie więc nigdy nie brzmi, czy tunel istnieje, lecz czy jakikolwiek pakiet wysłany przez twój test zmieścił się w zakresach wynegocjowanych przez oba peery. Jeśli żaden się nie zmieścił, liczniki pozostają na zerze, a asocjacja wygasa niewykorzystana pod koniec swojego czasu życia.

To rozróżnienie zmienia to, co sprawdzasz najpierw. Odrzucona propozycja, błąd uwierzytelniania albo umierająca IKE SA pojawiają się w logu lub na liście SA, a nie jako ciche zero. Tunel, który czysto negocjuje, a potem pozostaje bezczynny, wskazuje raczej na dopasowanie, routing albo pochodzenie ruchu testowego.

Wyślij przepływ, który potrafisz opisać, zanim go wyślesz

Wybierz cel wewnątrz chronionej podsieci i otwórz do niego nowe połączenie; strona wczytana godzinę temu może być podana z pamięci podręcznej, a buforowana odpowiedź nigdy nie dotyka tunelu. Następnie zapisz cztery wartości, gdy żądanie jest jeszcze hipotetyczne: adres źródłowy, który zwiąże aplikacja, cel, rodzinę adresów oraz nazwę lub parę selektorów obserwowanej SA podrzędnej. Ten zapis właśnie zamienia płaski licznik w sprawdzalne twierdzenie.

Adres źródłowy to wartość, którą ludzie pomijają, i to ona najczęściej psuje test. Laptop z adresem przewodowym, adresem Wi-Fi i adresem tunelu może związać każdy z nich w zależności od wyszukania trasy, a tylko jeden może leżeć w wynegocjowanym zakresie. Użyj narzędzia, które pozwala przypiąć źródło, na przykład ping -I 10.1.0.5 10.2.0.9 lub curl --interface 10.1.0.5, żeby pakiet nie mógł po cichu wybrać innego adresu. Gdy przypięty przebieg porusza liczniki, a nieprzypięty nie, znalazłeś problem routingu, a nie problem IPsec.

Które liczby czytać i gdzie one mieszkają

W systemie Linux ip -s xfrm state wypisuje każdą asocjację z linią lifetime current:, której suma bajtów i suma pakietów należą wyłącznie do tej SA, po czym następuje linia stats: z liczbami powtórzeń i błędów. U peera strongSwan swanctl --list-sas wypisuje jedną linię in i jedną linię out na każdą zainstalowaną SA podrzędną, każda kończy się liczbą bajtów i liczbą pakietów; starsze narzędzia stroke nazywają tę samą parę bytes_i i bytes_o. Czytaj oba kierunki osobno, bo ten, który pozostał płaski, jest ustaleniem. Zsumowanie ich ukrywa dokładnie tę asymetrię, której szukasz.

Oba widoki są przypisane do asocjacji, więc rekey instaluje nową parę SPI i twoja linia bazowa wraca do zera, choć nic się nie zepsuło. Zanotuj SPI, który obserwujesz, zanim zadziała timer rekey, inaczej porównasz nową SA ze starą liczbą. Jeśli wychodzący rośnie, a przychodzący pozostaje płaski, selektor pasował, ale odpowiedź nigdy nie wróciła, co przenosi śledztwo na przekazywanie u peera i jego własną politykę. Dokumentacja konfiguracji IKEv2 strongSwana omawia cykl życia SA podrzędnej i czas rekey stojący za tymi liczbami.

Punkt obserwacji jest osobną zmienną od pochodzenia pakietu. Odciążenie sprzętowe może zwiększać liczniki asocjacji, podczas gdy przechwycenie programowe na interfejsie nic nie pokazuje, bo odciążone pakiety omijają hak, na którym siedzi przechwycenie, a ruch przychodzący może odbiegać w ten sam sposób. Gdy oba się nie zgadzają, użyj liczników, aby odpowiedzieć, czy coś pasowało, a przechwycenia, aby odpowiedzieć, jak pakiet wyglądał.

Trasa, selektory i miejsce narodzin pakietu

Porównaj trzy rzeczy obok siebie: trasę, którą jądro wybiera dla twojego celu, politykę kierującą ruch do tunelu oraz parę selektorów wynegocjowaną przez SA podrzędną. ip route get 10.2.0.9 from 10.1.0.5 nazywa interfejs i źródło, których użyłoby jądro, a to często nie jest para, którą zakładałeś. ip xfrm policy pokazuje szablony i selektory zainstalowane lokalnie, a swanctl --list-sas pokazuje, na co zgodził się peer. Wyszukanie, które wysyła pakiet przez interfejs fizyczny, w ogóle nie dociera do polityki, więc liczniki nie mogą się ruszyć.

Niezgodności występują w kilku odmianach, które od strony licznika wyglądają identycznie. Cel IPv6 poza selektorem IPv4, adres źródłowy z niewłaściwej podsieci i polityka węższa niż SA podrzędna dają to samo zero. Napraw najpierw najwęższą przyczynę, bo poszerzenie selektora tylko po to, by przesunąć liczbę, zmienia to, czego tunel chroni.

Jest jeszcze pochodzenie pakietu, pułapka, którą brama zastawia na własnego operatora. Ruch generowany przez samą bramę jest dopasowywany do polityki wyjściowej, a pakiet przekazywany dla klienta do polityki przekazywania, więc ping z pudełka może się udać na ścieżce, której żaden klient nigdy nie bierze.

Jedna odwracalna zmiana i raport, który przetrwa przegląd

Zmień jeden element, powtórz identyczne żądanie i odczytaj te same liczniki. Wyczyszczenie wszystkich reguł zapory albo podmiana wszystkich selektorów naraz przesunie liczbę i zniszczy dowody, które mówiły ci dlaczego. Jeśli drugi przebieg nadal pokazuje zero, wyeliminowałeś jedną hipotezę, zamiast zmarnować popołudnie.

Zapisz ustalenie w formie, którą ktoś inny może odtworzyć: nazwa SA podrzędnej, zaakceptowane zakresy, przypięte źródło, testowany cel, kierunek, który pozostał na zerze, oraz SPI, który czytałeś. To zdanie oddziela asocjację, której nikt nie użył, od zdalnej aplikacji, która odebrała ruch i go odrzuciła. Wycofaj zmianę, gdy nie poruszyła liczników, i zachowaj zapis; następna osoba zaczyna tam, gdzie ty skończyłeś. Nic w tunelu nie wymagało odbudowy, i o to chodzi w sprawdzaniu dopasowania, zanim dotknie się konfiguracji.