traceroute - program służący do badania
trasy pakietów
w sieci
IP
.
Program traceroute jest szeroko dostępny we wszystkich
uniksowych
systemach operacyjnych. Istnieje również program tracert o podobnej funkcjonalności, zawarty w systemach z rodziny
Microsoft Windows
, jest także dostępny program mtr, który łączy funkcjonalność traceroute z narzędziem
ping
.
Zasada działania
Działanie traceroute opiera się o protokoły komunikacyjne
UDP
oraz
ICMP
.
- Na początku wysyłany jest pakiet z polem
TTL
(Time To Live) ustawionym na 1. Wartość ta jest zmniejszana przy przechodzeniu przez kolejne
routery
na trasie. Jeżeli pole TTL osiągnie wartość 0 to pakiet jest odrzucany przez
router
, który wysyła wtedy informację zwrotną w postaci komunikatu
ICMP
typu "Time Exceeded". W ten sposób komputer źródłowy uzyskuje
adres IP
pierwszego
routera
na trasie.
- W następnym wysyłanym pakiecie z komputera źródłowego pole TTL ma wartość 2. Pierwszy
router
zmniejszy tę wartość do 1 i przekaże do drugiego
routera
na trasie. Drugi
router
zachowa się podobnie jak ten pierwszy poprzednio, czyli zmniejszy TTL do 0 i odrzuci pakiet wysyłając komunikat "Time Exceeded" do komputera źródłowego.
- Informacje o kolejnych
routerach
na trasie uzyskuje się w sposób analogiczny jak w dwóch powyższych punktach. Po prostu zwiększa się wartość pola TTL stopniowo o 1 w wysyłanych pakietach.
- Jeżeli pakiet dotrze w końcu do
hosta
docelowego, to najprawdopodobniej zostanie odesłany komunikat
ICMP
"Port Unreachable". Dzieje się tak dlatego, że uniksowe implementacje programu traceroute świadomie wysyłają pakiety
UDP
z numerem portu powyżej 30000. Zazwyczaj na porcie o tak wysokim numerze nie działają żadne usługi, więc żaden proces w komputerze docelowym nie będzie chciał obsłużyć nadchodzącego pakietu. W tej sytuacji badanie trasy zostaje zakończone.
Podobne narzędzia jak mtr oraz w systemach z rodziny
Microsoft Windows
program tracert są zaimplementowane nieco inaczej. Główna zasada działania polegająca na stopniowym zwiększaniu pola TTL w wysyłanych pakietach pozostaje taka sama. Różnica polega na tym, że wysyłane pakiety to nie datagramy UDP, lecz komunikaty ICMP typu "Echo Request". Jeżeli taki komunikat osiągnie swoje przeznaczenie, to zawsze zostanie odesłana odpowiedź "Echo Reply". Dzięki temu nie trzeba polegać na założeniu związanym z wysokimi numerami portów dla datagramów UDP oraz można ominąć niektóre
firewalle
.
Przykład użycia
Przykład działania w systemie Linux - szukanie trasy z jednego z polskich
SDI
do pl.wikipedia.org:
$ traceroute pl.wikipedia.orgtraceroute to pl.wikipedia.org (130.94.122.197), 30 hops max, 38 byte packets 1 80.50.212.174 (80.50.212.174) 27.925 ms 21.351 ms 21.806 ms 2 80.50.212.173 (80.50.212.173) 25.908 ms 30.111 ms 34.078 ms 3 do.wro-ar3.z.wro-r1.tpnet.pl (213.25.5.153) 26.904 ms 27.311 ms 27.473 ms 4 z.kat-r2.do.wro-r1.tpnet.pl (194.204.175.177) 29.976 ms 29.846 ms 33.366 ms 5 z.kat-r1.do.kat-r2.tpnet.pl (194.204.175.187) 26.626 ms 25.030 ms 29.527 ms 6 z.kra-r1.do.kat-r1.tpnet.pl (194.204.175.132) 39.916 ms 35.171 ms 33.626 ms 7 z.war-r1.do.kra-r1.tpnet.pl (194.204.175.169) 45.120 ms 38.519 ms 39.890 ms 8 war-b2-pos5-0.telia.net (213.248.79.233) 31.025 ms 31.040 ms 38.829 ms 9 hbg-bb1-pos1-2-0.telia.net (213.248.64.201) 49.928 ms 49.095 ms 52.451 ms10 kbn-bb1-pos2-0-0.telia.net (213.248.64.29) 60.254 ms 48.805 ms 50.920 ms11 adm-bb1-pos0-1-0.telia.net (213.248.64.18) 72.432 ms 68.934 ms 70.613 ms12 adm-b1-pos2-0.telia.net (213.248.72.138) 69.353 ms 64.607 ms 69.942 ms13 p4-1-2-0.r00.amstnl02.nl.bb.verio.net (129.250.9.1) 69.952 ms 70.791 ms 69.018 ms14 p4-0-3-0.r01.amstnl02.nl.bb.verio.net (129.250.2.133) 81.510 ms 77.132 ms 80.041 ms15 p4-0-1-0.r80.nwrknj01.us.bb.verio.net (129.250.2.222) 162.401 ms 161.178 ms 159.993 ms16 p4-0-3-0.r00.nwrknj01.us.bb.verio.net (129.250.5.39) 158.481 ms 158.957 ms 159.038 ms17 p16-0-1-1.r20.mlpsca01.us.bb.verio.net (129.250.5.112) 229.876 ms 238.945 ms 239.979 ms18 xe-1-2-0.r21.mlpsca01.us.bb.verio.net (129.250.3.187) 240.390 ms 230.817 ms 239.929 ms19 p16-1-1-1.r20.lsanca01.us.bb.verio.net (129.250.5.96) 229.004 ms 228.556 ms 229.946 ms20 p16-1-1-1.r21.lsanca01.us.bb.verio.net (129.250.2.186) 229.919 ms 230.001 ms 229.761 ms21 p16-3-0-0.r01.sndgca01.us.bb.verio.net (129.250.2.159) 250.958 ms 239.954 ms 239.534 ms22 ge-1-2.a03.sndgca01.us.da.verio.net (129.250.27.100) 239.401 ms 239.831 ms 240.834 ms23 130.94.122.197 (130.94.122.197) 240.006 ms 239.888 ms 240.033 ms
Z powyższego przykładu na podstawie rekordów
reverse DNS
można orientacyjnie wyznaczyć przez jakie miasta i kraje przechodziły pakiety:
1-4 Wrocław Polska4-6 Katowice Polska6-7 Kraków Polska7-8 Warszawa Polska9 Hamburg Niemcy10 Kopenhaga Dania11-14 Amsterdam Holandia15-16 Newark USA, New Jersey17-18 Milpitas USA, Kalifornia19-20 Los Angeles USA, Kalifornia21-23 San Diego USA, Kalifornia
Brak odpowiedzi na zadany pakiet sygnalizowany jest znakiem gwiazdki "*" i może wynikać z przeciążenia sieci, routera bądź z celowej konfiguracji urządzeń (ustawienia
firewalla
).
W niektórych sieciach nazwy ruterów mogą być nieskonfigurowane albo nieaktualne, ale mimo to na podstawie różnicy w czasie odpowiedzi pomiędzy kolejnymi krokami, można wyznaczyć ważniejsze miejsca na trasie. W powyższym przykładzie między krokami numer 14 i 15 widać wzrost czasów odpowiedzi o około 80 ms, co wskazuje na pokonanie dużej przeszkody geograficznej, w tym przypadku
Ocean Atlantycki
. Podobnie pomiędzy krokami 16 i 17 zwiększenie czasu odpowiedzi wynika z pokonania przez pakiet całego
kontynentu
amerykańskiego.
Jeżeli router zostanie skonfigurowany w taki sposób, że nie zmniejsza wartości pola
TTL
przetwarzanych pakietów, nie będzie uwidoczniony przez traceroute, podobnie się także stanie, jeśli pakiet pokona część trasy
enkapsulowany
w
tunelu
lub sieci
MPLS
.
Zobacz też
Linki zewnętrzne
