ESP odszyfrowuje poprawnie, a wewnętrzny pakiet nadal nigdzie nie dociera

Licznik odbioru ESP rośnie, tunel pozostaje włączony, a aplikacja nigdy nie widzi pakietu. Odszyfrowanie się odbyło, weryfikacja integralności przeszła, a potem odbiorca musiał zdecydować, czym właściwie jest chroniony ładunek. Właśnie na tym ostatnim kroku pojawia się niezgodność formatu, a z zewnątrz wcale nie wygląda to na problem z zaporą sieciową.

Co widzisz, gdy etykieta kłamie

Nic w logu klienta nie odróżnia tego od czarnej dziury w routingu. Oba dają przekroczenie czasu aplikacji obok zdrowego tunelu, dlatego najpierw obwinia się liczniki.

Rosnący licznik odbioru to naprawdę dobra wiadomość: pakiety docierają i są uwierzytelniane. To nie jest dowód, że wewnętrzny pakiet miał sens dla czegokolwiek powyżej warstwy kryptograficznej.

Typ mieszka w trailerze

W zwykłym trybie tunelowym IPsec chroniony przez ESP ładunek zawiera kompletny wewnętrzny pakiet IP. Pole następnego nagłówka w trailerze określa, czym jest ten ładunek, i nie jest to port TCP, nie numer protokołu w nagłówku zewnętrznym i nie część początkowego pola SPI oraz numeru sekwencji. RFC 4303 sekcja 2.6 definiuje je jako pole typu ładunku, co jest precyzyjną nazwą dla precyzyjnego zadania.

Wartości, które spotkasz, są małe i warte zapamiętania: IPv4 to 4 (0x04), a IPv6 to 41 (0x29).

Te liczby pochodzą z przydziałów numerów protokołów IANA, a nie z lokalnej konwencji. Nadawca, który deklaruje IPv4, a jednocześnie opakowuje pakiet IPv6, wytworzył niezgodność formatu, i żadna reguła zapory nie naprawi bajtów sprzecznych z ich własną etykietą.

Jak odróżnić to od zwykłych podejrzanych

Większość brakujących pakietów to nie defekty kodowania. Najpierw sprawdź selektory, ponieważ selektor ruchu wykluczający prefiks IPv6 odrzuca ruch, zanim cokolwiek zostanie enkapsulowane. Potem sprawdź routing, a następnie filtrowanie lokalne na hoście odbierającym. Dopiero gdy to wykluczysz, niezgodność formatu ładunku staje się wiarygodnym wyjaśnieniem.

Zaszyfrowany zrzut tego nie rozstrzygnie, bo chroniony następny nagłówek znajduje się wewnątrz zaszyfrowanego ładunku. Potrzebujesz diagnostyki implementacji albo wspieranego odszyfrowanego punktu obserwacyjnego, a oba wymagają zgody przed użyciem.

Jeśli nikt nie potrafi przedstawić tego dowodu, nie masz błędu formatu. Masz teorię, a selektory pozostają lepszym zakładem.

Czym nie jest naprawa

Nie wyłączaj kontroli integralności, żeby ruch przechodził. Nie przepisuj zaszyfrowanych pakietów na routerze pośrednim, bo to nie może działać i uszkodzi przepływ, choć w zrzucie wygląda na pomocne. Nie otwieraj szerszej reguły zapory aplikacji w oparciu o teorię, że port jest blokowany. Nic z tego nie dotyka niezgodności etykiety.

Jeśli potwierdzona niezgodność pochodzi z implementacji partnera, zachowaj minimalne oczyszczone odtworzenie i zanieś je do wspieranego kanału tej implementacji.

Sprawdź przepływ, nie licznik

Po korekcie przetestuj rzeczywisty przepływ IPv6 od początku do końca: żądanie aplikacji przez tunel, jego odpowiedź i para adresów, którą obserwuje każda strona. Rosnący licznik ESP dowodzi tylko, że pakiety są odbierane i uwierzytelniane. Nic nie mówi o tym, czy wewnętrzny pakiet był użyteczny.

Zapisz oba wyniki w zgłoszeniu. Ruch licznika plus działający przepływ to naprawa; sam ruch licznika to dokładnie to, co miałeś przed rozpoczęciem.