Poprawna odpowiedź odnosi się do głównego przeznaczenia narzędzia tcpdump. Ta komenda w systemach z rodziny UNIX służy do analizy ruchu w sieci, czyli do przechwytywania i podglądania pakietów, które przechodzą przez interfejsy sieciowe komputera. W praktyce tcpdump „podsłuchuje” interfejs, np. eth0, i wyświetla nagłówki pakietów zgodnie z zadanym filtrem. Można zobaczyć adresy IP źródłowe i docelowe, porty TCP/UDP, typ protokołu (ICMP, DNS, HTTP, HTTPS itd.), flagi w nagłówkach TCP, a nawet fragmenty danych, jeśli pozwoli na to konfiguracja. Moim zdaniem tcpdump to jedno z podstawowych narzędzi administratora sieci i bezpieczeństwa, bo pozwala bardzo szybko stwierdzić, czy pakiety w ogóle dochodzą do hosta, czy jest odpowiedź z serwera, czy np. firewall coś blokuje. W dobrych praktykach administracji sieci (np. przy troubleshooting zgodnym z ITIL czy po prostu z zasadą „najpierw sprawdź warstwę sieciową”) tcpdump jest wykorzystywany do diagnozowania problemów z połączeniami, opóźnieniami, działaniem usług takich jak DNS, HTTP czy SSH. Narzędzie obsługuje filtry w składni BPF (Berkeley Packet Filter), co pozwala zawęzić analizę np. do konkretnego hosta, portu lub protokołu: „tcpdump -i eth0 port 80” pokaże ruch HTTP, a „tcpdump host 8.8.8.8” ruch do konkretnego serwera. Dodatkowo wyjście tcpdump można zapisać do pliku w formacie pcap i potem otworzyć w Wiresharku, co jest standardową praktyką w forensyce i analizie incydentów bezpieczeństwa. Warto też pamiętać, że tcpdump działa na niskim poziomie (warstwa 2–4 modelu OSI), więc pokazuje to, czego nie widać z poziomu zwykłych aplikacji. Daje to bardzo szczegółowy wgląd w to, co naprawdę dzieje się w sieci, a nie tylko w to, co „mówi” system czy przeglądarka.
Tcpdump bywa często mylony z innymi narzędziami sieciowymi, bo wszystkie działają mniej więcej w tym samym obszarze – sieć, protokoły, pakiety – ale ich rola jest zupełnie inna. Warto to sobie poukładać, bo z mojego doświadczenia takie pomyłki potem skutkują złym doborem narzędzia do problemu i niepotrzebną frustracją. Komenda tcpdump nie służy do modyfikacji tablicy routingu. Do zarządzania trasami sieciowymi w systemach UNIX/Linux używa się narzędzi takich jak „route” (bardziej stare podejście) albo nowocześniejszego „ip route” z pakietu iproute2. To nimi dodajemy, usuwamy albo zmieniamy trasy, definiujemy bramę domyślną itd. Tcpdump jedynie obserwuje skutki działania routingu, czyli to, jakie pakiety przechodzą przez dany interfejs. Nie ingeruje w konfigurację jądra systemu w zakresie trasowania. Podobnie błędne jest łączenie tcpdump z wysyłaniem zapytań do DNS. Do tego służą wyspecjalizowane narzędzia takie jak „dig”, „nslookup” czy „host”. One generują zapytania DNS i pokazują odpowiedzi serwera nazw. Tcpdump może te zapytania i odpowiedzi podejrzeć na poziomie pakietów, ale sam ich nie tworzy. W praktyce często używa się kombinacji: np. „dig example.com” plus równocześnie „tcpdump port 53”, żeby zobaczyć, jak wygląda ruch DNS „od środka”. To dość typowa dobra praktyka przy diagnozowaniu dziwnych problemów z nazwami domen. Jeśli chodzi o wprowadzanie zmian w ustawieniach protokołu TCP/IP, tym też nie zajmuje się tcpdump. Konfiguracja adresów IP, masek, bram, parametrów stosu TCP (np. okno, MSS, sysctl-e typu net.ipv4.*) odbywa się przez narzędzia konfiguracyjne systemu, takie jak „ip addr”, „ip link”, pliki konfiguracyjne sieci, ewentualnie edycja parametrów jądra przez „sysctl”. Tcpdump nie zmienia tych ustawień, nie ustawia adresów, nie modyfikuje zachowania stosu TCP/IP, on tylko podgląda to, co przez ten stos przechodzi. Typowy błąd myślowy polega na wrzucaniu wszystkich „sieciowych” komend do jednego worka: skoro coś ma w nazwie „tcp”, to pewnie konfiguruje TCP, skoro „dump”, to może coś „wyrzuca” albo zmienia. W rzeczywistości tcpdump jest pasywnym analizatorem pakietów, zgodnym z ideą sniffera, używanym głównie do diagnostyki i analizy, a nie do konfiguracji czy zarządzania siecią. Dobrą praktyką jest rozróżnienie narzędzi: tcpdump i Wireshark – do analizy ruchu, ip/route – do konfiguracji tras i interfejsów, dig/nslookup – do testowania DNS, a sysctl i pliki konfiguracyjne – do ustawień stosu TCP/IP. To porządkuje podejście i ułatwia pracę w realnym środowisku.