traceroute
traceroute – program służący do badania trasy pakietów w sieci IP.
Program traceroute jest szeroko dostępny we wszystkich uniksowych systemach operacyjnych; jest także dostępny program mtr, który łączy funkcjonalność traceroute z narzędziem ping. Istnieje również program tracert o podobnej funkcjonalności, zawarty w systemach z rodziny Microsoft Windows.
Zasada działania
edytujDziałanie traceroute opiera się na protokołach komunikacyjnych 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
edytujPrzykład działania w systemie GNU/Linux – szukanie trasy z jednego z polskich SDI do pl.wiki.x.io:
$ traceroute pl.wiki.x.io traceroute to pl.wiki.x.io (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 ms 10 kbn-bb1-pos2-0-0.telia.net (213.248.64.29) 60.254 ms 48.805 ms 50.920 ms 11 adm-bb1-pos0-1-0.telia.net (213.248.64.18) 72.432 ms 68.934 ms 70.613 ms 12 adm-b1-pos2-0.telia.net (213.248.72.138) 69.353 ms 64.607 ms 69.942 ms 13 p4-1-2-0.r00.amstnl02.nl.bb.verio.net (129.250.9.1) 69.952 ms 70.791 ms 69.018 ms 14 p4-0-3-0.r01.amstnl02.nl.bb.verio.net (129.250.2.133) 81.510 ms 77.132 ms 80.041 ms 15 p4-0-1-0.r80.nwrknj01.us.bb.verio.net (129.250.2.222) 162.401 ms 161.178 ms 159.993 ms 16 p4-0-3-0.r00.nwrknj01.us.bb.verio.net (129.250.5.39) 158.481 ms 158.957 ms 159.038 ms 17 p16-0-1-1.r20.mlpsca01.us.bb.verio.net (129.250.5.112) 229.876 ms 238.945 ms 239.979 ms 18 xe-1-2-0.r21.mlpsca01.us.bb.verio.net (129.250.3.187) 240.390 ms 230.817 ms 239.929 ms 19 p16-1-1-1.r20.lsanca01.us.bb.verio.net (129.250.5.96) 229.004 ms 228.556 ms 229.946 ms 20 p16-1-1-1.r21.lsanca01.us.bb.verio.net (129.250.2.186) 229.919 ms 230.001 ms 229.761 ms 21 p16-3-0-0.r01.sndgca01.us.bb.verio.net (129.250.2.159) 250.958 ms 239.954 ms 239.534 ms 22 ge-1-2.a03.sndgca01.us.da.verio.net (129.250.27.100) 239.401 ms 239.831 ms 240.834 ms 23 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-3 Wrocław Polska 4-6 Katowice Polska 7 Kraków Polska 8 Warszawa Polska 9 Hamburg Niemcy 10 Kopenhaga Dania 11-14 Amsterdam Holandia 15-16 Newark USA, New Jersey 17-18 Milpitas USA, Kalifornia 19-20 Los Angeles USA, Kalifornia 21-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 kapsułkowany w tunelu lub sieci MPLS.