Retransmisje TCP a odrzucenia powtórzeń IPsec: czytaj każdą warstwę

Trzy różne narzędzia zgłaszają trzy różne duplikaty, a tylko jeden z nich jest zdarzeniem sieciowym, na które można zareagować. Retransmisja TCP to nadawca, który ponownie wysyła zakres, zduplikowany ACK to odbiorca, który powtarza potwierdzenie, a odrzucenie powtórzenia ESP to asocjacja bezpieczeństwa, która odrzuca numer sekwencji już przez nią zaakceptowany. Żadne z trzech nie implikuje pozostałych. Czytaj każdy licznik na warstwie, która go tworzy, zanim połączysz je w jedną historię.

Trzy liczniki, które nigdy nie mierzą tego samego zdarzenia

Adnotacja retransmisji TCP oznacza, że nadawca ponownie umieścił zakres sekwencji na łączu. Utrata jest jednym z powodów, a przechwycenie, które masz, może po prostu nie zawierać oryginalnego pakietu lub potwierdzenia, które wyjaśniłoby czas. Zduplikowany ACK to odbiorca powtarzający potwierdzenie skumulowane zgodnie z regułami odzyskiwania TCP, co nie jest ani zduplikowanym zapisem aplikacji, ani drugą kopią danych.

ESP działa we własnej przestrzeni sekwencji. Każda asocjacja bezpieczeństwa numeruje wysyłane pakiety, a odbiorca utrzymuje okno numerów, które już zaakceptował, więc pakiet ESP, który dotrze dwa razy, jest odrzucany wyłącznie na tej podstawie. Ponownie wysłany segment TCP podróżuje więc w nowym pakiecie ESP z nowym numerem sekwencji, co jest poprawnym zachowaniem na obu warstwach. Te same bajty mogą wyglądać na nowe w jednym liczniku, a na stare w innym, i żadna z warstw nie kłamie.

Co analizator może, a czego nie może zobaczyć

Zacznij od słownictwa analizatora, ponieważ nazwy filtrów opisują obserwacje, a nie wnętrze punktów końcowych. Liczenie tymi samymi nazwami, których używa narzędzie, utrzymuje uczciwość co do tego, co zostało rzeczywiście zmierzone. Liczba z niepełnego przechwycenia to liczba tego, co przetrwało, a nie tego, co wydarzyło się na łączu.

tshark -r trace.pcap -Y "tcp.analysis.retransmission" | wc -l
tshark -r trace.pcap -Y "tcp.analysis.duplicate_ack" | wc -l

Czytaj informacje eksperckie obok tych liczb, ponieważ ostrzeżenia o sumie kontrolnej i kolejności zmieniają, ile wagi zasługują. Połączony ślad z dwóch czujników może pokazać jedną ramkę dwa razy, a liczenie obu kopii wymyśla zdarzenie odzyskiwania, które nigdy nie miało miejsca.

Liczniki ESP żyją w stanie jądra

Numery sekwencji ESP należą do asocjacji bezpieczeństwa, a nie do strumienia TCP, więc brama jest miejscem, gdzie trzeba pytać. Lista stanu podaje liczniki pakietów i błędów dla każdej asocjacji, których żadne przechwycenie nie odtworzy.

ip -s xfrm state
tshark -r trace.pcap -Y "esp" -T fields -e esp.seq | head

RFC 4303 definiuje numer sekwencji i okno chroniące przed powtórzeniami, które go zużywa, dlatego licznik rośnie nawet gdy nic nie jest nie tak. Monotoniczne zewnętrzne numery sekwencji bez odpowiadającej anomalii TCP wskazują na innego nadawcę lub zduplikowaną ścieżkę, a nie na burzę retransmisji. Zewnętrzne przechwycenie szyfrowanego tunelu zwykle ukrywa wewnętrzne numery sekwencji TCP, więc nie może dowieść, co zrobił wewnętrzny stos. Przechwytuj wewnątrz tunelu tylko tam, gdzie polityka na to pozwala, i nigdy nie wyłączaj ochrony przed powtórzeniami, aby wyciszyć niepowiązane ostrzeżenie.

Gdzie punkt obserwacji zmienia odpowiedź

Przed eskalacją zapisz, jak wykonano przechwycenie: interfejs, czy proces przechwytywania zgłaszał utraty i czy znaczniki czasu są porównywalne między czujnikami. Jeden punkt obserwacji nie widzi obu końców ścieżki, więc każde stwierdzenie o zachowaniu odbiorcy jest wnioskiem, a nie pomiarem. Ślad zrobiony na bramie i ślad zrobiony na hoście będą się nie zgadzać co do kolejności pod obciążeniem, a ta niezgodność zwykle należy do przechwycenia, a nie do tunelu. Korelowanie dwóch widoków jest tym, co zamienia liczbę w dowód.

Użyj jednego dozwolonego przepływu aplikacji i zapisz liczniki punktów końcowych obok liczb z przechwycenia w tym samym momencie. Jeśli liczby się nie zgadzają, zaufaj warstwie, która posiada zdarzenie, a drugą traktuj jako artefakt obserwacji, dopóki nie zostanie dowiedzione coś przeciwnego. Ta zasada rozwiązuje większość takich zgłoszeń bez dotykania konfiguracji tunelu.

Czytanie liczb we właściwej kolejności

Zacznij od warstwy, w której zadano pytanie: na ostrzeżenie TCP odpowiada się z przechwycenia TCP, a na odrzucenie ESP odpowiada się z liczników asocjacji bezpieczeństwa na bramie. Dopiero potem pytaj, czy oba widoki opisują ten sam pakiet. Wniosek wymagający obu warstw powinien nazwać obie, ponieważ twierdzenie o tunelu oparte tylko na adnotacji TCP jest domysłem.

Zapisz warstwę, licznik i punkt obserwacji dla każdego ustalenia, a następny czytelnik nie stopi trzech zdarzeń w jedną wymyśloną awarię. Eskaluj z tymi trzema polami, a poprawka zwykle wynika z pierwszego.