Dlaczego tcpdump pokazuje tekst jawny IPsec tylko w jednym kierunku
Ta asymetria to artefakt punktu przechwytywania, a nie zepsuta ścieżka odpowiedzi. Oto gdzie szukać ruchu wewnętrznego i zewnętrznego na bramie IPsec z Linuksem.
Uruchamiasz tcpdump na interfejsie zewnętrznym bramy IPsec z Linuksem i widzisz dwie rzeczy naraz: przychodzące ramki ESP oraz, zaraz po nich, odszyfrowane pakiety wewnętrzne. W kierunku wyjściowym pojawia się tylko ESP. Naturalny wniosek jest taki, że odpowiedzi nie są wysyłane albo że IPsec szyfruje jeden kierunek i zapomina o drugim. Żadna z tych tez nie jest prawdziwa.
To, na co patrzysz, to punkt przechwytywania. Jądro przekształca pakiety wychodzące, zanim ścieżka transmisji urządzenia przekaże je do gniazda pakietów, więc gniazdo nigdy nie widzi wewnętrznej postaci na wyjściu. Na wejściu pakiet jest najpierw przechwytywany jako ESP, a odszyfrowana kopia staje się widoczna, gdy ponownie wchodzi do stosu. Ten sam ruch, dwa różne okna obserwacji.
Punkt przechwytywania decyduje, co widzisz
Na zwykłym interfejsie gniazdo AF_PACKET znajduje się blisko warstwy urządzenia. Pakiety opuszczające hosta przechodzą najpierw przez przetwarzanie wyjściowe IPsec, które zamienia wewnętrzny segment TCP na datagram ESP lub UDP-4500, i dopiero potem docierają do tej warstwy. Pakiety przychodzące są kopiowane do gniazda w chwili zejścia z kabla, wciąż zaszyfrowane, a odszyfrowany wynik staje się widoczny później, gdy stos dostarczy go lokalnie lub przekazuje dalej.
Ta kolejność całkowicie wyjaśnia asymetrię. To nie jest dowód dotyczący kierunku, polityki ani zachowania aplikacji, a traktowanie tego jako dowodu każe ludziom gonić odpowiedź, która przez cały czas była wysyłana poprawnie. To jedna z niewielu zagadek sieciowych, w których anomalię tworzy narzędzie, a nie sieć.
Dopasuj filtr do warstwy, którą masz na myśli
Wyrażenie takie jak tcp port 443 wybiera wewnętrzne połączenie TCP. W kierunku wyjściowym to połączenie jest już ESP w chwili, gdy odpytywane jest gniazdo, więc filtr nie dopasowuje niczego. Jeśli chcesz liczyć ruch chroniony, filtruj według postaci zewnętrznej: protokół 50 dla surowego ESP albo port UDP 4500, gdy używane jest przejście NAT. Oba filtry dają liczbę pakietów porównywalną między dwoma stronami, co zwykle jest powodem liczenia. Żaden z nich nie mówi, czy wewnętrzne żądanie otrzymało odpowiedź.
Nie traktuj liczby UDP 4500 jako liczby pakietów ESP. IKE używa tego portu także do komunikatów utrzymania NAT-T i do wymiany enkapsulowanej, więc liczba obejmuje ruch, który nie jest danymi, które chciałeś zmierzyć. Początkowa wymiana IKE na UDP 500 wymaga własnego filtra, jeśli to jest pytanie. Liczba mieszająca ruch sterujący z danymi sprawia też, że każde szacowanie przepustowości jest błędne o nieznany margines. Osobne liczenia odpowiadają na osobne pytania.
Zapisz filtr obok pytania, na które odpowiada. „Ile ESP opuściło skrzynkę” i „czy żądanie sieciowe opuściło skrzynkę” to różne pomiary z różnymi filtrami, a jedno przechwycenie nie rozstrzygnie obu. Bez tej notatki dwie osoby porównają liczby, które nigdy nie liczyły tego samego.
Obserwuj przed transformacją, nie po niej
Jeśli musisz zobaczyć wychodzący tekst jawny, przesuń punkt obserwacji wcześniej, przed przetwarzaniem wyjściowym IPsec. NFLOG daje ci hak Netfilter, w którym reguła może kopiować wybrane pakiety do gniazda w przestrzeni użytkownika, które tcpdump potrafi czytać. Przewodnik strongSwan po zrzucie ruchu dokumentuje to podejście właśnie z tego powodu.
Dopasowanie polityki ogranicza regułę do ruchu, który ma wejść do tunelu. -m policy --pol ipsec --dir out czyni regułę konkretną, zamiast rejestrować każdy pakiet wysyłany przez skrzynkę. Następnie czytaj grupę dziennika z ograniczonym przechwytywaniem: mała liczba zrzutów i limit rozmiaru nie pozwalają diagnostyce stać się archiwum ruchu. Ograniczone przechwytywanie łatwiej też przekazać recenzentowi bez wleczenia nieistotnego ładunku. Ustal liczbę przed rozpoczęciem, a nie po zobaczeniu, ile przyszło.
iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'Wybierz hak dopasowany do przepływu. OUTPUT obejmuje ruch generowany przez samą bramę; tranzyt od klienta LAN przechodzi przez łańcuch FORWARD, a reguła na OUTPUT nigdy go nie zobaczy. Adres i port powyżej to wartości zastępcze dla zatwierdzonego celu testowego.
Co dowodzi obserwacja
NFLOG to cel rejestrowania, a nie decyzja o akceptacji. Pakiet, który się tam pojawia, pokazuje, że dotarł do haka i pasował do reguły. Nie pokazuje, że późniejszy filtr go przepuścił, że urządzenie go przesłało albo że druga strona coś otrzymała.
Pusty dziennik jest równie niejednoznaczny. Sprawdź licznik pakietów reguły, potwierdź kierunek, potwierdź, że przepływ naprawdę pasował do polityki IPsec, i potwierdź miejsce docelowe. Tylko zgodny licznik po obu stronach zamienia obserwację we wniosek. Następnie porównaj liczniki asocjacji bezpieczeństwa po obu stronach dla tej samej kontrolowanej próby, bo liczniki SA są autorytatywnym zapisem tego, co zostało ochronione i wysłane.
Jeszcze jedna pułapka: „tekst jawny” w tym kontekście oznacza poza warstwą szyfrowania IPsec. Wewnętrzna sesja HTTPS nadal ma własny TLS. Przechwycenie odszyfrowanego pakietu nie odszyfrowuje TLS aplikacji, a widoczny tam czytelny HTTP oznacza, że aplikacja w ogóle nie używała HTTPS.
Posprzątaj i porównaj oba końce
Usuń dokładnie tę regułę, którą wstawiłeś, według jej właściciela, gdy tylko obserwacja się skończy. Pozostawiona reguła rejestrowania kosztuje CPU przy każdym pasującym pakiecie i po cichu tworzy problem z retencją danych. Usuń, powtarzając regułę z -D, zamiast czyścić łańcuch, który nie należy do ciebie.
iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5Jeśli wdrożenie używa IPsec w przestrzeni użytkownika, interfejsu XFRM albo odciążenia sprzętowego, punkty obserwacji się przesuwają i ten przepis może w ogóle nie mieć zastosowania. W przypadku libipsec udokumentowanym miejscem obserwacji ruchu wewnętrznego jest urządzenie TUN. Najpierw zidentyfikuj ścieżkę, potem wybierz punkt, który odpowiada na pytanie, i oczekuj, że oba kierunki będą wyglądać różnie tylko wtedy, gdy patrzysz na niewłaściwą stronę transformacji.