Traceroute - każdy pakiet ma TTL == 1


17

Pracuję nad laboratorium Wireshark IP w sieci komputerowej - podejście odgórne i nie rozumiem, dlaczego każdy pakiet, który normalnie wygasł, ma TTL równy 1.

Oto mój plik przechwytywania Wireshark. https://www.dropbox.com/s/rr5wgze9j20gzvu/traceroute-56.pcapng?dl=0

Przechwyciłem wykonanie tracerouteprogramu w systemie Linux (z opcją 56 bajtów), wykonanego następującą komendą:

traceroute http://gaia.cs.umass.edu 56

Widać, że większość TTL pakietu == 1 i nie wiem dlaczego, ponieważ dowiedziałem się, że każdy kolejny skok ma TTL +1 (lub więcej).

PS:

  • Używam Lubuntu na VMware z połączoną siecią do hosta.
  • Zrobiłem to za pomocą wireshark na maszynie hosta (Windows)
  • Jestem podłączony do bezprzewodowego punktu dostępowego za pomocą własnego serwera DHCP na podstawie protokołu NAT

Odpowiedzi:


14

Pozwól, że spróbuję odpowiedzieć na to pytanie, ponieważ jest to trochę bardziej skomplikowane, że może początkowo wyglądać.

Wygląda na to, że znasz już podstawowe działanie, tracerouteale przede wszystkim tutaj jest bardzo małe podsumowanie:

traceroutepróbuje określić wszystkie pośrednie kroki od hosta do hosta docelowego lub po prostu odległość, tj. liczbę przeskoków, od hosta do hosta docelowego. Aby to zrobić, zaczyna wysyłać pakiety do hosta docelowego z „losowym” numerem portu docelowego i wartością TTL, która zaczyna się od 1 i stale rośnie.
Chodzi o to, że każdy router pomiędzy obniża TTL o 1. Zatem jeśli TTL osiągnie 0 (w rzeczywistości nigdy tak się nie dzieje, ponieważ router, który ma zamiar ją zmniejszyć do 0, powoduje błąd wcześniej), router zwróci ICMP „ Time-to-live przekroczony ” komunikat o błędzie, np pakiet numer 24 w pliku przechwytywania. To, co otrzymujesz, to fakt, że miejsce docelowe jest dalej i dlatego ciągle zwiększasz TTL.
Gdy pakiet ma czas TTL, który jest wystarczająco duży, aby dotrzeć do miejsca docelowego, pojawi się inny komunikat o błędzie ICMP: „ Miejsce docelowe nieosiągalne (nieosiągalny port) ”, np. Pakiet 208 w pliku przechwytywania. Z tego wynika, że ​​ostatnio używany TTL jest rzeczywiście liczbą przeskoków między tobą a węzłem docelowym. Przyczyną tego błędu jest po prostu to, że wysyłasz wiadomość do „losowego” portu, którego węzeł docelowy (mam nadzieję) nie słucha.

Teraz przejdźmy do szczegółów pliku przechwytywania:
Ze strony podręcznika traceroutemożemy zobaczyć, że każdy TTL jest używany 3 razy (opcja „-q”), a domyślnym protokołem jest UDP (opcja „-P”). Analizując pierwsze 3 pakiety UDP, tj. Pakiety 8-9-10 , możemy rzeczywiście stwierdzić, że TTL wynosi 1 . Następne 3, tj. 11-12-13 , mają TTL 2 i tak dalej. Więc z perspektywy źródła wszystko wydaje się dobrze.

Następnie, po pewnym czasie zależnym od opóźnienia sieci, zaczynamy otrzymywać oczekiwane komunikaty o błędach. Widzimy zatem, że pakiety 24–25–26 to pakiety błędówCzas życia przekroczył ”, co oznacza, że ​​miejsce docelowe jest dalej.

To powtarzanie prób i błędów trwa, aż w końcu pakiet 208 i dalej pojawiają się komunikaty o błędach „ Port Unreachable ”, co oznacza, że ​​osiągnięto miejsce docelowe.

Licząc wysłane pakiety i odpowiedzi, możesz dowiedzieć się nawet ze śladu, który TTL faktycznie działał, ale jest to żmudne zadanie :)

Mam nadzieję, że to pomogło


super wyjaśnienie
ksp0422,

14

Twój klient wysyła tylko pierwsze trzy pakiety z TTL równym 1. Następne trzy są wysyłane z TTL równym 2. Kolejne trzy są wysyłane z TTL równym 3. I tak dalej i tak dalej.

Łatwiejszym sposobem na to jest ustawienie pola TTL IP jako własnej kolumny w Wireshark. Po prostu kliknij prawym przyciskiem myszy wartość TTL w dowolnym pakiecie i wybierz „Zastosuj jako kolumnę”: Ustaw TTL jako kolumnę w Wireshark

Stamtąd widać, że pakiety 8,9,10 mają TTL równy 1. A pakiety 11,12,13 mają TTL równy 2. I tak dalej i tak dalej. TTL w Traceroute

Dzieje się tak, ponieważ tak działa Traceroute. Wykorzystuje to, co robi router, gdy zmniejsza TTL do 0. Zamiast kontynuować przesyłanie pakietu, wysyła z powrotem do oryginalnego klienta komunikat ICMP TTL wygasł w transporcie (patrz pakiet nr 24 w twoim przechwytywaniu) .

Zatem jako klient, gdy wysyłasz pierwszy zestaw pakietów z TTL równym 1, pierwszy router na ścieżce odpowiada komunikatem o wygasłym TTL. Następnie mierzysz, ile czasu upłynęło, zanim otrzymałeś wiadomość TTL Expired, kiedy wysłałeś początkowe wiadomości, i to daje ci pierwsze trzy wartości w danych wyjściowych Traceroute.

Następnie wysyłasz kolejny zestaw trzech pakietów o TTL równym 2. Pierwszy router na ścieżce zmniejsza to do 1, a następnie przekazuje go do następnego routera na ścieżce. Po otrzymaniu, gdy ten drugi router go otrzyma, zmniejsza TTL do 0, co powoduje, że upuszcza on pakiet i wysyła TTL Upłynął w drodze.

Proces ten trwa, dopóki klient nie otrzyma (dobrze, trzech) komunikatu o wygasłym TTL z każdego routera w drodze między tobą a ostatecznym miejscem docelowym, z którym uruchamiasz traceroute.


najlepiej wyjaśnione wizualnie
ksp0422,

@Eddie, To może nie mieć związku z tym pytaniem, ale jest to bardzo mało szczegółów, o których pomyślałem pytając w komentarzu. Czy możesz określić, co się stanie, jeśli host (nie router) odbierze datagram z polem 1 TTL?
Vimal Patel,

1
@VimalPatel Jeśli pakiet był przeznaczony dla hosta, host po prostu akceptuje pakiet. Usuwanie pakietów, jeśli TTL osiągnie 0, jest funkcją routera.
Eddie,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.