Komenda tcpdump w systemach z rodziny UNIX służy właśnie do analizy ruchu w sieci i to w dość niskim, pakietowym ujęciu. Narzędzie nasłuchuje interfejs sieciowy (np. eth0, wlan0) i przechwytuje ramki/ pakiety, które przez niego przechodzą. Dzięki temu administrator widzi dokładnie, jakie protokoły są używane (TCP, UDP, ICMP, ARP itd.), na jakie porty idzie ruch, z jakich i do jakich adresów IP, a nawet może podejrzeć nagłówki i części danych. Moim zdaniem to jest jedno z podstawowych narzędzi diagnostycznych w linuksowym świecie, obok ping, traceroute czy netstat/ss. W praktyce tcpdump wykorzystuje się np. do diagnozowania problemów z połączeniem (czy pakiety w ogóle dochodzą do serwera), do analizy opóźnień, sprawdzania, czy działa handshake TCP (SYN, SYN/ACK, ACK), do weryfikacji, czy pakiety nie są blokowane przez firewall, albo do analizy dziwnego ruchu, który może sugerować skanowanie portów lub atak. Typowe użycie to np.: tcpdump -i eth0 port 80, żeby zobaczyć tylko ruch HTTP na danym interfejsie, albo tcpdump -n host 8.8.8.8, żeby podglądnąć ruch do konkretnego hosta bez rozwiązywania nazw. W dobrych praktykach administracji sieciowej tcpdump traktuje się jako narzędzie pierwszej linii – szybkie, tekstowe, działające nawet na serwerach bez środowiska graficznego. Bardziej rozbudowaną analizę robi się potem np. w Wiresharku, ale bardzo często to właśnie tcpdump generuje plik pcap, który potem się analizuje szczegółowo. Warto też pamiętać, że tcpdump korzysta z biblioteki libpcap, co jest takim branżowym standardem przechwytywania pakietów w systemach UNIX/Linux.
Wokół narzędzi sieciowych w systemach UNIX bardzo łatwo o pomyłkę, bo nazwy komend są krótkie, a funkcje często się w głowie mieszają. Tcpdump nie służy jednak ani do zmiany konfiguracji sieci, ani do aktywnego wysyłania zapytań, tylko do pasywnej obserwacji ruchu. To jest sniffer pakietów, a nie narzędzie konfiguracyjne. Modyfikacja tablicy routingu w typowych systemach uniksowych odbywa się za pomocą innych poleceń, takich jak route (starsze podejście) albo ip route w ramach narzędzia ip z pakietu iproute2. Tam definiuje się trasy, bramy domyślne, metryki, polityki routingu. Tcpdump tych wpisów nie zmienia, ono może co najwyżej pokazać, czy ruch faktycznie trafia tam, gdzie według tablicy routingu powinien trafić. To jest zupełnie inna warstwa – analiza zamiast konfiguracji. Podobnie jest z wysyłaniem zapytań DNS. Do tego używa się programów typu dig, nslookup albo host. One generują konkretne zapytania DNS, na przykład typu A, AAAA, MX, NS, i pokazują odpowiedź serwera. Tcpdump może taki ruch DNS podsłuchać i zapisać, dzięki czemu da się sprawdzić, czy zapytanie w ogóle wychodzi z hosta i jak wygląda odpowiedź, ale sam go nie generuje w sensie logiki zapytania. To jest ważne rozróżnienie: narzędzie klienckie DNS kontra sniffer, który tylko obserwuje pakiety UDP/TCP na porcie 53. Kolejna rzecz to zmiana ustawień protokołu TCP/IP. Takie operacje wykonuje się przez ip addr, ip link, ifconfig (w starszych systemach), sysctl dla parametrów jądra (np. tcp_syncookies, ip_forward) albo edycję plików konfiguracyjnych. Tcpdump nie dotyka stosu TCP/IP w sensie jego parametrów – nie zmienia MTU, nie włącza ani nie wyłącza forwarding’u, nie ustawia masek sieci. Typowy błąd myślowy polega na wrzuceniu wszystkich „sieciowych” komend do jednego worka i założeniu, że skoro coś ma w nazwie „tcp”, to na pewno konfiguruje TCP. W rzeczywistości w dobrej praktyce administracyjnej rozdziela się narzędzia na te od konfiguracji (ip, ifconfig, route, sysctl), testowania łączności (ping, traceroute, nmap, dig) oraz analizy ruchu (tcpdump, Wireshark). Tcpdump jest zdecydowanie w tej trzeciej grupie – to analizator pakietów, który ma pomagać w diagnozie, a nie zmieniać zachowanie sieci.