Traceroute - каждый пакет имеет TTL == 1


17

Я работаю над Wireshark lab-IP в разделе «Компьютерные сети» - нисходящий подход, и я не понимаю, почему у каждого пакета с истекшим сроком годности 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 с мостовой сетью к хосту.
  • Я захватил это с wireshark на хост-машине (Windows)
  • Я подключен к беспроводной точке доступа, используя собственный DHCP-сервер поверх протокола NAT

Ответы:


14

Позвольте мне попытаться ответить на этот вопрос , потому что это немного более сложным , что это может выглядеть на начальном этапе.

Кажется, что вы уже знаете основные операции, tracerouteно прежде всего здесь приведем очень небольшое резюме:

tracerouteпытается определить все промежуточные шаги от вашего хоста до хоста назначения или просто расстояние, то есть количество прыжков, от вашего хоста до хоста назначения. Для этого он начинает отправку пакетов на хост назначения с «случайным» номером порта назначения и TTL, который начинается с 1 и продолжает увеличиваться.
Идея состоит в том, что каждый промежуточный маршрутизатор уменьшает TTL на 1. Таким образом, если TTL достигает 0 (в действительности это никогда не происходит, так как маршрутизатор, который собирается уменьшить его до 0, выдает ошибку до этого), маршрутизатор возвратит ICMP Сообщение об ошибке « Время жизни истекло », например, номер пакета 24 в файле захвата. Из этого вы получаете то, что ваш пункт назначения находится дальше, и именно поэтому вы продолжаете увеличивать TTL.
Если ваш пакет имеет TTL, который достаточно велик для достижения пункта назначения, вы получите другое сообщение об ошибке ICMP: « Пункт назначения недоступен (порт недоступен) », например, номер пакета 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 Expired in Transit message» (см. Пакет № 24 в перехвате) .

Таким образом, как клиент, когда вы отправляете первый набор пакетов с TTL, равным 1, первый маршрутизатор в пути отвечает сообщением об истечении срока действия TTL. Затем вы измеряете, сколько времени потребовалось для получения сообщения об истечении срока действия TTL при отправке начальных сообщений, и это дает вам первые три значения в выходных данных Traceroute.

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

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


лучше всего объяснить визуально
ksp0422

@ Эдди, это может не относиться к этому вопросу, но это очень маленькая деталь, о которой я подумал, спрашивая в комментарии. Можете ли вы указать, что происходит, если хост (не маршрутизатор) получает дейтаграмму с полем TTL 1?
Вимал Патель

1
@VimalPatel Если пакет был предназначен для хоста, хост просто принимает пакет. Удаление пакетов, если TTL достигает 0, является функцией маршрутизатора.
Эдди
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.