Jak czytać pierwszą wymianę IKEv2 w zrzucie pakietów

Zrzuty wykonane w środku sesji to zwykły powód, dla którego ślad IKEv2 wygląda jak szum, ponieważ strony już odnawiają klucze lub wymieniają zaszyfrowane ładunki, gdy rozpoczyna się nagranie. Zacznij zamiast tego od świeżej próby połączenia, aby pierwsza wiadomość w pliku była tą, która otwiera negocjację. Poniższa kolejność czytania to zakłada i zaznacza punkt, w którym pakiet przestaje cokolwiek dowodzić o drugiej stronie. Pominięcie tego kroku sprawia, że działający tunel zostaje zdiagnozowany jako zablokowany port.

Upewnij się, że patrzysz na wymianę otwierającą

Negocjacja IKEv2 zaczyna się od IKE_SA_INIT, typ wymiany 34, identyfikator wiadomości 0. Inicjator wybiera niezerowe SPI, a SPI respondera jest zerowe w tym pierwszym żądaniu i niezerowe w odpowiedzi. Te trzy fakty oddzielają świeżą próbę od odnowienia kluczy lub od wiadomości IKE_AUTH, która przypadkiem znajduje się na górze zrzutu.

Pola nagłówka są czytelne, podobnie jak ładunki propozycji, wymiany kluczy i nonce. Czytelność nie oznacza uwierzytelnienia: żadna ze stron nie udowodniła tożsamości w tym momencie, a prywatna wartość Diffie-Hellmana nigdy nie pojawia się na łączu.

Wypisz pola jako tabelę, zamiast przewijać panel dekodowania, ponieważ retransmisje i niezgodne SPI stają się oczywiste w kolumnach.

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

Czytaj wyjście parami. Żądanie z identyfikatorem wiadomości 0, po którym następuje odpowiedź z tym samym identyfikatorem i niezerowym SPI respondera, to jedna wymiana, nawet gdy pojawia się trzy razy, bo żądanie zostało przesłane ponownie. Trzy identyczne żądania to nie trzy logowania, a traktowanie ich w ten sposób prowadzi do wniosku, że klient kręci się w pętli, gdy jest po prostu cierpliwy. Posortuj według identyfikatora wiadomości, a potem znacznika czasu, a cała rozmowa kurczy się do krótkiej listy prób.

Przeczytaj odrzucenie, zanim przeczytasz sukces

Odpowiedź nie jest automatycznie postępem. Responder może odpowiedzieć powiadomieniem cookie i oczekiwać, że inicjator spróbuje ponownie, albo INVALID_KE_PAYLOAD wskazującym grupę, którą wolałby przyjąć. Oba przychodzą jako poprawnie zbudowane wiadomości IKE i oba wyglądają jak zakończona wymiana dla filtra, który tylko liczy pakiety.

Otwórz ładunek powiadomienia i przeczytaj typ przed wszystkim innym. Wyzwanie cookie oznacza, że responder broni się przed fałszywymi adresami źródłowymi, a klient musi wysłać ponownie z dołączonym cookie. Nieprawidłowa grupa oznacza, że dwie propozycje się nie zgadzają, czego nie zmieni żadna liczba ponownych prób, dopóki nie zmieni się konfiguracja jednej ze stron.

Tylko IKE_AUTH, druga wymiana, niesie zaszyfrowaną tożsamość i ładunki uwierzytelnienia. Ukończone IKE_SA_INIT mówi więc, że strony zgadzają się co do algorytmów i kluczy pochodnych, i zupełnie nic o tym, czy dane logowania zostaną przyjęte. Spodziewaj się tam również dwóch wiadomości i spodziewaj się, że obie będą nieprzejrzyste bez kluczy sesji.

Port 4500 to nie jeden protokół

UDP 500 zwykle przenosi wymianę otwierającą. Gdy wykrywanie NAT już zadziała, IKE przechodzi na 4500 i poprzedza każdą wiadomość czterobajtowym zerowym znacznikiem, który nie jest ESP. Enkapsulowane ESP na tym samym porcie zaczyna się natomiast od niezerowego SPI ESP, a keepalive NAT o długości jednego bajta to trzecia forma, która pojawia się, gdy nic innego się nie dzieje.

Filtr dopasowujący tylko port miesza wszystkie trzy, dlatego "na 4500 jest ruch" rozstrzyga tak niewiele. Rozdziel widok według protokołu, zanim wyciągniesz wnioski o drugiej stronie.

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

Cisza opisuje punkt obserwacji

Żądania bez odpowiedzi ustalają dokładnie jedną rzecz: w tym punkcie zrzutu nie pojawiła się żadna odpowiedź. Filtrowanie, trasa wysyłająca odpowiedź gdzie indziej, nieosiągalny responder lub responder, któremu nie odpowiada propozycja, dają ten sam pusty wynik, a ogólna sonda UDP ich nie rozdzieli.

Nieosiągalność ICMP to dowód innego rodzaju. Przeczytaj zacytowany w nim pakiet i ustal, które urządzenie go wysłało, ponieważ administracyjne odrzucenie routera nie jest uwierzytelnionym błędem od drugiej strony.

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

Powiąż tę samą próbę z logami po stronie serwera tam, gdzie wolno je czytać. Czy żądanie dotarło, czy usługa odpowiedziała i gdzie odpowiedź się zatrzymała? Te trzy odpowiedzi kierują cię do problemu z trasą albo do problemu z polityką, i kosztują mniej niż czwarta rotacja danych logowania.