Позвольте мне попытаться ответить на этот вопрос , потому что это немного более сложным , что это может выглядеть на начальном этапе.
Кажется, что вы уже знаете основные операции, 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 на самом деле работал, но это утомительная задача :)
Надеюсь, что помог
Ваш клиент отправляет только первые три пакета с TTL, равным 1. Следующие три отправляются с TTL, равным 2. Следующие три отправляются с TTL, равным 3. И так далее, и так далее.
Более простой способ увидеть это - установить поле IP TTL в качестве собственного столбца в Wireshark. Просто щелкните правой кнопкой мыши значение TTL в любом пакете и выберите «Применить как столбец»:
Оттуда вы можете видеть, что пакеты 8,9,10 имеют TTL 1. И пакеты 11,12,13 имеют TTL 2. И так далее, и тому подобное.
Это происходит потому, что так работает Traceroute. Он использует то, что делает Маршрутизатор, когда он уменьшает TTL до 0. Вместо того, чтобы продолжать пересылку пакета, он отправляет обратно исходному клиенту «ICMP TTL Expired in Transit message» (см. Пакет № 24 в перехвате) .
Таким образом, как клиент, когда вы отправляете первый набор пакетов с TTL, равным 1, первый маршрутизатор в пути отвечает сообщением об истечении срока действия TTL. Затем вы измеряете, сколько времени потребовалось для получения сообщения об истечении срока действия TTL при отправке начальных сообщений, и это дает вам первые три значения в выходных данных Traceroute.
Затем вы отправляете другой набор из трех пакетов с TTL, равным 2. Первый маршрутизатор в пути уменьшает это значение до 1, а затем пересылает его следующему маршрутизатору в пути. При получении, когда тот второй маршрутизатор получает его, он уменьшает TTL до 0, что побуждает его отбросить пакет и отправить вам истекший TTL в пути.
Процесс продолжается до тех пор, пока ваш клиент не получит (ну, три) сообщение об истечении срока действия TTL от каждого маршрутизатора, находящегося в пути между вами и конечным пунктом назначения, с которым вы выполняете трассировку.
источник