Prawidłowo wskazane narzędzie to „tracert” (w systemach Windows) albo jego odpowiednik „traceroute” w systemach Linux/Unix. To polecenie służy dokładnie do tego, o co chodzi w pytaniu: do prześledzenia trasy, jaką pakiety IP pokonują od Twojego komputera do wskazanego hosta w sieci. Działa to tak, że narzędzie wysyła pakiety z rosnącą wartością pola TTL (Time To Live) w nagłówku IP. Każdy router po drodze zmniejsza TTL o 1, a gdy TTL spadnie do zera, urządzenie odsyła komunikat ICMP „Time Exceeded”. Dzięki temu „tracert” jest w stanie wypisać listę kolejnych routerów (skoków, tzw. hopów), przez które przechodzi ruch. W praktyce używa się tego narzędzia do diagnostyki problemów z łącznością: można zobaczyć, na którym etapie trasy pojawiają się opóźnienia, utrata pakietów albo całkowity brak odpowiedzi. Administratorzy sieci, zgodnie z dobrymi praktykami, często łączą wyniki „tracert” z „ping” i „netstat”, żeby mieć pełniejszy obraz sytuacji – ale to właśnie „tracert” pokazuje fizyczną/logiczna ścieżkę przez poszczególne routery. Moim zdaniem warto pamiętać też o ograniczeniach: niektóre routery nie odpowiadają na ICMP albo są filtrowane przez firewalle, więc nie każda trasa będzie pokazana w 100%. Mimo to, w diagnozowaniu problemów z routingiem, przeciążeniami łączy międzymiastowych czy międzynarodowych, „tracert” jest jednym z podstawowych, klasycznych narzędzi, które nadal są standardem w pracy administratora i serwisanta sieci.
W tym pytaniu łatwo się pomylić, bo wszystkie wymienione polecenia są narzędziami sieciowymi i często używa się ich razem przy diagnostyce. Kluczowe jest jednak zrozumienie, co dokładnie robi każde z nich. Wiele osób myli „ping” z narzędziem do śledzenia trasy, bo faktycznie wysyła on pakiety ICMP do zdalnego hosta i mierzy czas odpowiedzi. Ping sprawdza, czy host jest osiągalny i jakie są opóźnienia, ale nie pokazuje, przez jakie routery i jakie dokładnie etapy przechodzi ruch. W praktyce ping odpowiada na pytanie „czy tam w ogóle dochodzę?” i „jak szybko?”, ale nie na pytanie „którędy tam idę?”. To jest typowy błąd myślowy: skoro coś testuje sieć, to wydaje się, że „na pewno też pokaże trasę”. Netstat z kolei służy do wyświetlania aktualnych połączeń sieciowych, nasłuchujących portów, tabeli routingu w systemie oraz statystyk protokołów. Świetnie nadaje się do sprawdzania, jakie usługi są otwarte na danym komputerze, czy aplikacja nasłuchuje na właściwym porcie, albo jakie są stany sesji TCP (ESTABLISHED, LISTENING, TIME_WAIT itd.). Jednak netstat nie wysyła pakietów w sieć, nie bada ścieżki, tylko pokazuje, co dzieje się lokalnie w systemie operacyjnym. Tu znowu pojawia się naturalne przekonanie, że „skoro widzę routing, to może też pokaże trasę w Internecie”, ale to nie to samo – to tylko widok lokalnej konfiguracji. Nslookup natomiast to narzędzie do diagnostyki DNS. Służy do sprawdzania, jak nazwy domenowe są tłumaczone na adresy IP i odwrotnie, do testowania serwerów DNS, rekordów typu A, MX, CNAME itd. Przydaje się, gdy domena nie działa, e-mail nie dochodzi, albo podejrzewamy problem z konfiguracją stref DNS. Nie ma jednak żadnego związku z pokazywaniem kolejnych routerów na trasie. Podsumowując, tylko „tracert” (lub „traceroute”) implementuje mechanizm stopniowego zwiększania TTL i analizowania odpowiedzi ICMP, co pozwala prześledzić rzeczywistą ścieżkę pakietów w sieci. Pozostałe narzędzia są użyteczne, ale rozwiązują zupełnie inne problemy diagnostyczne.