Traceroute - кожен пакет має TTL == 1


17

Я працюю над лабораторією Wireshark в галузі комп'ютерних мереж - підхід зверху вниз, і я не розумію, чому кожен пакет, який зазвичай закінчився, має TTL 1.

Ось мій файл захоплення Wireshark. https://www.dropbox.com/s/rr5wgze9j20gzvu/traceroute-56.pcapng?dl=0

Я зафіксував виконання tracerouteпрограми в Linux (з опцією 56 байт), як виконано за допомогою наступної команди:

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

Ви можете бачити, що більша частина TTL == 1 пакету, і я не знаю чому, оскільки я дізнався, що кожен наступний стрибок має TTL +1 (або більше).

PS:

  • Я використовую Lubuntu на VMware з мостовою мережею для хоста.
  • Я захопив його за допомогою проводки на хост-машині (Windows)
  • Я підключений до бездротової AP за допомогою власного сервера DHCP поверх протоколу NAT

Відповіді:


14

Дозвольте спробувати відповісти на це, адже це трохи складніше, що може виглядати спочатку.

Здається, ви вже знаєте основну операцію, tracerouteале перед усім іншим тут дуже невеликий резюме:

tracerouteнамагається визначити всі кроки між проміжком від вашого хоста до хоста призначення або просто відстань, тобто кількість переходів, від вашого хоста до хоста призначення. Для цього він починає надсилати пакети до цільового вузла з "випадковим" номером порту призначення та TTL, який починається з 1 і постійно збільшується.
Ідея полягає в тому, що кожен маршрутизатор між ними знижує TTL на 1. Таким чином, якщо TTL досягає 0 (насправді це ніколи не відбувається, оскільки маршрутизатор, який збирається зменшити його до 0, створює помилку до цього), маршрутизатор поверне ICMP Повідомлення про помилку " Час до проживання перевищено ", наприклад номер пакету 24 у вашому файлі захоплення. Що ви отримуєте від цього, це те, що ваш пункт призначення знаходиться далі, і саме тому ви постійно збільшуєте TTL.
Якщо у вашому пакеті є TTL, достатньо великий, щоб досягти пункту призначення, ви отримаєте інше повідомлення про помилку ICMP: " Destination Unreachable (Port Unreachable) ", наприклад номер пакета 208 у вашому файлі захоплення. Від цього ви отримуєте те, що останній використаний TTL - це дійсно кількість переходів між вами та вузлом призначення. Причина, що ви отримуєте помилку, полягає лише в тому, що ви надсилаєте повідомлення до "випадкового" порту, який вузол призначення (сподіваємось) не слухає.

Тепер перейдемо до специфіки вашого файлу захоплення:
З сторінки керівництва tracerouteми бачимо, що кожен TTL використовується 3 рази (опція '-q'), а протокол за замовчуванням використовується UDP (опція '-P'). Розглядаючи перші 3 пакети UDP, тобто пакети 8-9-10 , ми можемо побачити, що TTL дорівнює 1 . Наступні 3, тобто 11-12-13 , мають TTL 2 тощо. Тож з точки зору джерела все, здається, йде нормально.

Потім, через деякий час, залежний від затримки мережі, ми починаємо отримувати очікувані повідомлення про помилки. Таким чином, ми можемо бачити, що пакети помилок " 24-25-26" є пакетами помилок " Перевищено час ", і, таким чином, означає, що пункт призначення знаходиться далі.

Це повернення спроб та помилок триває, поки, нарешті, пакет 208 і на ньому ви не побачите повідомлення про помилки " Порт недоступний ", що означає, що ваше призначення було досягнуто.

Підрахувавши надіслані вами пакети та відповіді, ви зможете дізнатися навіть з того, який TTL насправді працював, але його копітка задача :)

Сподіваюся, що це допомогло


супер пояснення
ksp0422

14

Ваш клієнт надсилає лише перші три пакети з TTL 1. Наступні три надсилаються з TTL 2. Наступні три надсилаються з TTL 3. І так далі, і так далі.

Простіший спосіб переглянути це - встановити поле IP TTL як власний стовпець у Wireshark. Просто клацніть правою кнопкою миші значення TTL у будь-якому пакеті та виберіть "Застосувати як стовпець": Встановіть TTL як стовпець у Wireshark

Звідти ви бачите, що пакети 8,9,10 мають TTL 1. І пакети 11,12,13 мають TTL 2. І так далі і так далі. TTL у Сліду

Це відбувається тому, що так працює Traceroute. Він використовує переваги того, що робить маршрутизатор, коли він зменшує TTL до 0. Замість того, щоб продовжувати пересилати пакет, він відправляє назад вихідному клієнту "ICMP TTL, минувший у транзитному повідомленні" (див. Пакет №24 у захопленні) .

Отже, як клієнт, коли ви надсилаєте перший набір пакетів з TTL 1, перший маршрутизатор у шляху відповідає на повідомлення TTL Expired. Потім ви вимірюєте, скільки часу знадобилося для отримання повідомлення про втрату TTL, коли ви надіслали початкові повідомлення, і це дає ваші перші три значення у висновку Traceroute.

Потім ви надсилаєте ще один набір з трьох пакетів з TTL 2. Перший маршрутизатор у шляху зменшує значення до 1, а потім пересилає його до наступного маршрутизатора в шляху. Після отримання, коли той другий маршрутизатор отримує його, він зменшує TTL до 0, що спонукає його скинути пакет і надіслати вам TTL, що закінчився в дорозі.

Процес триває доти, поки ваш клієнт не отримає (ну, три) повідомлення з терміном дії TTL від кожного маршрутизатора, який перебуває в дорозі між вами та кінцевим пунктом призначення, проти якого ви запускаєте трассеру.


найкраще пояснюється візуально
ksp0422

@ Eddie, це може не стосуватися цього питання, але це дуже мало деталей, які я думав, запитуючи в коментарях. Чи можете ви вказати, що станеться, якщо хост (не маршрутизатор) отримає дейтаграму з полем 1 TTL?
Vimal Patel

1
@VimalPatel Якщо пакет призначений для хоста, хост просто приймає пакет. Відкидання пакетів, якщо TTL потрапляє на 0, є функцією маршрутизатора.
Едді
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.