Utrata Ping w VPN: grupuj żądania Echo przed procentem

Jedno przechwycenie zawiera sześć żądań Echo i trzy odpowiedzi, a ktoś wpisuje w zgłoszeniu 50 procent utraty pakietów. Ta liczba może być prawdziwa dla przechwycenia, a fałszywa dla tunelu. Sześć żądań może należeć do dwóch różnych rozmów z dwiema różnymi umowami dostarczania. Zgrupuj je, zanim podzielisz, a proporcja przestanie być ciekawą częścią raportu.

Krok 1: rozdziel strumienie według źródła i celu

Żądanie Echo niesie źródło i cel, a te dwa pola określają, do której rozmowy należy. Sonda wygenerowana przez bramę używa adresu tunelu bramy, natomiast sonda przekazana w imieniu hosta LAN zachowuje adres tego hosta. Druga strona może mieć trasę powrotną dla jednej, a nie dla drugiej, co sprawia, że obie grupy zachowują się różnie z powodów niezwiązanych z tunelem.

Podziel przechwycenie według tych pól, zanim cokolwiek policzysz, i zachowaj cel jako część klucza. Dwa strumienie do różnych partnerów nie są porównywalne, nawet gdy dzielą źródło.

Zapisz grupy wraz z ich liczbami, ponieważ następny krok decyduje, które odpowiedzi należą do której grupy. Grupa z trzema żądaniami i bez pasującej odpowiedzi jest ustaleniem. Grupa z trzema żądaniami i trzema odpowiedziami jest linią bazową.

Krok 2: dopasuj według identyfikatora i sekwencji

Format Echo w RFC 792 niesie identyfikator i numer sekwencji, i traktuje je jako pola, które łączą odpowiedź z jej żądaniem. Oba są potrzebne do tego zadania. Sam numer sekwencji nie jest unikalny, ponieważ różni nadawcy lub procesy mogą ponownie użyć tej samej wartości w jednym oknie przechwycenia. Identyfikator zawęża nadawcę, a sekwencja pozycję, i to para razem czyni dopasowanie obronnym.

Odpowiedź odwraca kierunek adresów swojego żądania, więc dopasowanie to para żądanie-odpowiedź, a nie dwa identyczne krotki. Porównaj źródło żądania z celem odpowiedzi, a cel żądania ze źródłem odpowiedzi, następnie potwierdź, że identyfikator i sekwencja się zgadzają.

Zachowaj także okno obserwacji, ponieważ długie przechwycenie może zawierać legalne ponowne użycie obu pól. Przycięcie okna do jednego wybuchu usuwa większość tej niejednoznaczności. Czyni też liczby odtwarzalnymi dla każdego, kto czyta zgłoszenie.

tshark -r capture.pcap -Y 'icmp.type == 8' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq
tshark -r capture.pcap -Y 'icmp.type == 0' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq

Krok 3: porównaj krotki na tej samej granicy

Jeśli tłumaczenie adresów sieciowych znajduje się między punktem przechwycenia a partnerem, adresy w żądaniu i odpowiedzi będą różnić się z założenia. Porównaj krotki na jednej granicy, albo przenoś mapowanie jawnie, aby różnica została uwzględniona. Mieszanie żądań sprzed tłumaczenia z odpowiedziami po tłumaczeniu tworzy rozbieżności, których nigdy nie było na przewodzie.

Zdecyduj o granicy, zanim zaczniesz liczyć, i podaj ją w raporcie, aby następna osoba mogła odtworzyć grupowanie. Jedno przechwycenie po stronie klienta i drugie po stronie serwera to dwie różne granice. Każde odpowiada na inne pytanie o to, gdzie zniknęła odpowiedź.

Grupa przetłumaczonych sond dziedziczy również własny stan urządzenia tłumaczącego, który może być prawdziwym powodem, dla którego odpowiedź nigdy nie dociera. Sprawdź ten stan, zanim obwinisz drogę za nim.

tcpdump -ni any icmp and host 10.90.0.1 -c 20
tshark -r capture.pcap -Y 'icmp' -T fields -e ip.src -e ip.dst -e ip.ttl | head -20

Krok 4: powiedz, co przechwycenie może, a czego nie może udowodnić

Zaobserwowana luka nie dowodzi, że odległy host milczał. Punkt przechwycenia może widzieć tylko jeden kierunek, filtr może odrzucić odpowiedź, a bufor mógł się przepełnić w trakcie okna. Każde z nich daje tę samą nieobecność i inny wniosek.

Zapisz miejsce przechwycenia, wyrażenie filtra i liczniki odrzuceń obok liczb, ponieważ proporcji bez nich nie można zaudytować. To właśnie te trzy linie czynią liczbę później obronną.

Następnie oddziel to, co obserwacja ustala, od tego, co sugeruje, w dwóch zdaniach zamiast jednego. Pierwsze zdanie podaje liczby i granicę. Drugie podaje hipotezę i co by ją potwierdziło.

Gdy pytanie brzmi, czy konkretna droga odrzuca pakiety, kontrolowana sonda z jawnym adresem źródłowym jest silniejszym dowodem niż pasywny licznik ruchu mieszanego. Wyślij ją z tej samej maszyny, w tym samym czasie, do tego samego partnera. Zmień jedną zmienną, a porównanie się utrzyma.

Zgłoś grupy i następną granicę

Raport ma trzy wiersze: definicję grupy, dopasowane liczby w każdej grupie i granicę, na której dokonano porównania. Wtedy czytelnik widzi, że jedna grupa odpowiedziała w pełni, a druga nie, co wskazuje na trasę lub uprawnienie, a nie na przypadkową utratę.

Dołącz plik przechwycenia i wyrażenia filtrów, aby grupowanie można było odtworzyć. Podsumowanie bez pliku jest twierdzeniem, a nie wynikiem.

ping -c 5 -I 10.80.0.6 10.90.0.1
ping -c 5 -I 10.30.0.25 10.90.0.1
tshark -r capture.pcap -Y 'icmp.type == 8 || icmp.type == 0' -T fields -e ip.src -e ip.dst -e icmp.ident -e icmp.seq | sort | uniq -c | head

Gdy jedna grupa pokazuje pięć odpowiedzi, a druga żadnej, ustaleniem jest to, że jedno źródło ma działającą trasę powrotną, a drugie nie. To znacznie lepsze zgłoszenie niż mieszany procent, i kieruje następne sprawdzenie na trasę powrotną, a nie na niepowiązaną instancję VPN.