Prawidłowa odpowiedź to analiza ruchu w sieci, bo dokładnie do tego służy tcpdump. Jest to klasyczne narzędzie linii poleceń w systemach z rodziny UNIX/Linux, wykorzystywane do przechwytywania i wyświetlania pakietów sieciowych „przelatujących” przez interfejsy sieciowe. W praktyce tcpdump działa w oparciu o bibliotekę libpcap, która udostępnia niskopoziomowy dostęp do ramek i pakietów. Dzięki temu możesz podejrzeć nagłówki protokołów takich jak Ethernet, IP, TCP, UDP, ICMP, a nawet analizować konkretne porty, adresy IP czy flagi w pakietach TCP. Moim zdaniem to jedno z podstawowych narzędzi administratora sieci i bezpieczeństwa – coś jak stetoskop dla lekarza. Tcpdump pozwala np. sprawdzić, czy ruch dociera do serwera, czy dochodzi do retransmisji, czy występują podejrzane połączenia na nietypowe porty. Typowy przykład z życia: masz usługę na porcie 80, która „nie działa”. Za pomocą tcpdump możesz od razu zobaczyć, czy w ogóle przychodzą pakiety SYN na ten port i jak serwer odpowiada. Innym praktycznym zastosowaniem jest filtrowanie ruchu według wyrażeń BPF (Berkeley Packet Filter), np. przechwytywanie tylko ruchu DNS lub tylko połączeń z konkretnym hostem. To jest zgodne z dobrymi praktykami diagnostyki sieci: najpierw obserwacja ruchu, potem zmiany konfiguracji. Warto też wiedzieć, że tcpdump może zapisywać ruch do pliku w formacie pcap, który potem da się otworzyć w Wiresharku czy innym analizatorze. W środowiskach produkcyjnych często używa się tcpdump w trybie bez interakcji, np. jako element skryptów diagnostycznych. Narzędzie nie służy do zmieniania konfiguracji sieci, tylko do pasywnej obserwacji. I to jest klucz: tcpdump jest snifferem/analitykiem, a nie menedżerem konfiguracji TCP/IP czy routingu.
Tcpdump bardzo często myli się z innymi narzędziami sieciowymi właśnie dlatego, że wszędzie pojawia się w kontekście „sieci”. Warto to sobie raz porządnie poukładać. Tcpdump jest narzędziem do przechwytywania i analizy ruchu sieciowego, czyli działa pasywnie: ogląda pakiety, nie zmienia ustawień systemu. Jeżeli ktoś kojarzy je z modyfikacją tablicy routingu, to najpewniej miesza je z poleceniami typu route, ip route czy w starszych materiałach z ifconfig. Tablica routingu to logika „którędy wysłać pakiet”, a tcpdump tylko pokazuje, co tymi trasami faktycznie płynie. Z mojego doświadczenia to częsty błąd: ktoś widzi, że tcpdump pokazuje ruch na różnych interfejsach i zakłada, że może też tym ruchem „sterować”. Podobnie jest z DNS. Wysłanie zapytania do serwera DNS realizuje się narzędziami takimi jak dig, nslookup albo host. Tcpdump może co najwyżej podejrzeć, jak wygląda zapytanie i odpowiedź DNS na poziomie pakietów UDP/TCP, ale samo nie generuje tych zapytań w sensie funkcjonalnym. Można oczywiście uruchomić tcpdump z filtrem portu 53 i oglądać zapytania DNS, lecz to dalej jest czysta analiza, a nie aktywne pytanie serwera o rekordy. Kolejna kwestia to modyfikacja ustawień protokołu TCP/IP. Za to odpowiada konfiguracja systemu, pliki konfiguracyjne, polecenia ip, sysctl, edycja parametrów jądra, konfiguratory sieciowe w dystrybucjach Linuksa. Tcpdump nie ustawia MTU, nie zmienia masek sieciowych, nie definiuje bramy domyślnej ani nie przełącza interfejsów. Ono jedynie „podsłuchuje”, jak te ustawienia przekładają się na realny ruch. Typowy błąd myślowy polega na tym, że skoro narzędzie pokazuje bardzo szczegółowe informacje o protokołach, to ludzie zakładają, że musi też dać się nimi zarządzać. W dobrze prowadzonym środowisku sieciowym rozdziela się jednak narzędzia konfiguracyjne od narzędzi diagnostycznych. Tcpdump należy zdecydowanie do tej drugiej grupy – jest świetny do analizy, debugowania, audytu bezpieczeństwa, ale nie służy do wprowadzania zmian w infrastrukturze sieciowej.