Zduplikowane pakiety IKE: znajdź brakujące przejście

Dziennik pokazuje to samo żądanie IKE dwukrotnie, ktoś wskazuje na łącze mobilne, a zgłoszenie zamyka się przypuszczeniem. To przypuszczenie jest mitem: powtórzony pakiet to obserwacja jednej wymiany, a nie diagnoza łącza. Retransmisja jest normalnym zachowaniem z własnymi regułami i pojawia się na zdrowych ścieżkach, ilekroć odpowiedź jest wolna. Śledź odpowiedź, zanim obwinisz interfejs.

Mit: powtórzone żądanie dowodzi utraty na jednym łączu

Dwie różne rzeczy tworzą duplikat i żadna nie wskazuje winnego. Żądający może powtórzyć żądanie, bo nie otrzymał odpowiedzi, albo punkt przechwytywania może pokazać ten sam pakiet dwukrotnie z powodu miejsca podpięcia do stosu. Sonda widząca ruch przychodzący i wychodzący na tym samym hoście z ochotą zapisze jeden pakiet jako dwa, a operator czytający ten dziennik nie ma sposobu odróżnić ich bez identyfikatorów wymiany. Traktuj duplikat jako zdarzenie zegara, dopóki nie powiesz, który z dwóch trzymasz w ręku.

Dwa łącza mobilne pogarszają zamieszanie zamiast je zmniejszać. Jedna linia dziennika wskazuje jeden interfejs, podczas gdy odpowiedź mogła wyjść przez drugi, więc interfejs w komunikacie opisuje, gdzie widziano pakiet, a nie kształt rozmowy. Dlatego pierwszym pytaniem jest, której wymiany pilnujesz, a nie które łącze jest wadliwe.

Co retransmisja naprawdę ci mówi

W IKEv2 retransmisja działa tak: żądający powtarza żądanie, gdy nie nadeszła odpowiedź, a odpowiadający może wysłać ponownie swoją zapisaną odpowiedź zamiast liczyć nową. Identyfikatory komunikatów należą do tej wymiany i to właśnie sprawia, że powtórzone żądanie z tym samym identyfikatorem jest rozpoznawalne jako praca protokołu, a nie nowa próba. Pierwsza próba często wymaga do skorelowania więcej niż adres źródłowy lub SPI inicjatora, więc własny zapis wymiany platformy bije listę pakietów. IKEv1 kieruje się innymi regułami z innymi identyfikatorami, a ostrzeżenie dostawcy o zduplikowanym pierwszym pakiecie nie znaczy tego samego w każdej wersji.

Znacznik czasu retransmisji mówi więc, że zegar wygasł. Nie mówi, który skok był wolny, i z pewnością nie mówi, że operator jest winny. To osobne twierdzenia i tylko drugie jest przydatne w zgłoszeniu.

Praktyczną konsekwencją jest zapisanie wymiany przed wyciągnięciem wniosku. Zanotuj lokalny adres odbioru, ścieżkę odpowiedzi wybraną przez politykę, parę peera i identyfikatory wymiany w jednym miejscu, bo każde z nich odpowiada na inne pytanie, gdy zapis czyta się później.

Cztery punkty obserwacji jako jeden łańcuch

Myśl o wymianie jak o czterech ogniwach łańcucha, a nie czterech osobnych miejscach do oglądania. Ogniwo trzyma dowód albo pozostaje nieznane, a łańcuch jest tylko tak informacyjny jak jego najsłabsze zapisane ogniwo. Poniższa tabela to inwentarz: co może ustalić każda pozycja i co pozostawia nietknięte.

Wypełniaj łańcuch tylko tam, gdzie masz dostęp, a resztę oznacz jako nieznaną, zamiast ją wywodzić. Hak zapisujący pakiety na jednej maszynie nie mówi nic o tym, co odebrała maszyna po drugiej stronie, a linia dziennika o tym, że widziano żądanie, nie jest dowodem, że kiedykolwiek wyszła odpowiedź. Uczciwe luki są użyteczniejsze niż wyglądający na kompletny zapis zbudowany z domysłów.

Znajdź pierwsze brakujące przejście

Przejdź łańcuch od inicjatora na zewnątrz i zatrzymaj się na pierwszym ogniwie bez dowodu. Jeśli brama nigdy nie zapisuje żądania, usterka leży na ścieżce przed nią. Gdy brama zapisuje to samo żądanie raz po raz, a klient nigdy nie zapisuje odpowiedzi, podejrzany jest kierunek powrotny: adres źródłowy, translacja i filtrowanie na każdej granicy, którą kontrolujesz. Jeśli odpowiedź dociera, a klient nadal nie rusza dalej, pytanie opuściło transport i stało się polityką lub stanem.

Trzymaj peera i protokół na stałym poziomie podczas porównywania i pamiętaj, że opóźnienie, utrata, polityka i stan dają każdy inną oś czasu. Sieć mobilna nie jest automatycznie przyczyną, a linia stała nie jest automatycznie wystarczająco niezawodna dla każdego wymagania. Przechwyć oba kierunki, dopóki wymiana trwa:

tcpdump -ni any -vv 'udp port 500 or udp port 4500'

Gdy dostęp kończy się przed dalekim końcem, zapis nadal pomaga, jeśli mówi, gdzie się kończy. Przechwycenie tylko na inicjatorze może pokazać żądanie wychodzące i brak nadchodzącej odpowiedzi, co zawęża usterkę do wszystkiego po tym haku, bez udawania, że wie się, który skok ją zgubił. Oznacz dalekie ogniwa jako nieznane i pozwól następnej osobie z dostępem je uzupełnić. Tak zapisane, pozostaje uczciwe i nadal krótkie.

Porównuj, zanim cokolwiek zmienisz. Powtarzanie tego samego żądania do tego samego peera z tym samym protokołem utrzymuje zmienne policzalne, a reset, odnowienie klucza lub zmiana polityki między przechwyceniami niszczy porównanie. Jeśli zmiana jest nieunikniona, przechwyć ponownie zaraz po niej, aby przed i po nadal opisywały tę samą wymianę.

Co mówi użyteczny raport

Raport wart działania łączy jedno żądanie z jego odpowiedzią i nazywa pierwszy krok, za którym nie ma dowodu. To zdanie przetrwa czytanie tydzień później przez inżyniera, którego tam nie było, i daje następnej osobie punkt startu zamiast podejrzanego.

Nigdy nie osłabiaj kontroli tożsamości ani nie poszerzaj dozwolonego zestawu protokołów tylko po to, by sprawdzić teorię retransmisji. Zapisz oryginalne pakiety i rejestry zdarzeń przed jakimkolwiek resetem, bo reset niszczy dokładnie ten materiał, który miałeś zebrać, i wymazuje chronometraż pokazujący, gdzie wymiana utknęła.

Mit głosi, że jeden duplikat dowodzi winy operatora. Rzeczywistość jest taka, że jeden duplikat dowodzi wygaśnięcia zegara, a odpowiedź żyje na ścieżce odpowiedzi.