Skip to main content

Как использовать команду «traceroute» в Linux

Протокол ICMP, утилита traceroute | Практика по курсу "Компьютерные сети" (Май 2024)

Протокол ICMP, утилита traceroute | Практика по курсу "Компьютерные сети" (Май 2024)
Anonim

Команда traceroute используется в Linux, чтобы сопоставить путешествие, которое пакет информации берет на себя от источника до места назначения. Одним из способов использования traceroute является обнаружение, когда потеря данных происходит по всей сети, что может означать узел, который не работает.

Поскольку каждый прыжок в записи отражает новый сервер или маршрутизатор между исходным ПК и предполагаемой целью, просмотр результатов сканирования traceroute также позволяет определить медленные точки, которые могут негативно повлиять на ваш сетевой трафик.

Как это устроено

Оценивая конкретный маршрут, за которым следует сетевой трафик (или обнаружение злоумышленника, который отбрасывает ваши пакеты), возникает несколько проблем, связанных с устранением неполадок. Traceroute использует протокол IP время жить чтобы запросить ответ ICMP TIME_EXCEEDED от каждого шлюза по пути к целевому узлу.

Единственным параметром, который вы должны включить при выполнении команды traceroute, является имя хоста или IP-адрес получателя.

Синтаксис и переключатели Traceroute

трассировка -dFInrvx -f first_ttl шлюз я лицо -m max_ttl -п порт -q nqueries -s src_addr -t тос -w время ожидания -z pausemsecs хозяин packetlen

Хотя выше описано, как команда traceroute должна быть выписана для работы в командной строке, производительность или выход команды можно изменить, указав один или несколько дополнительных ключей.

  • -f: Установите начальное время жизни, используемое в первом пакете исходящих зондов.
  • -F: Установите бит «не фрагментировать».
  • -d: Включить отладку уровня сокета.
  • -г: Укажите свободный шлюз маршрута источника (максимум 8).
  • -я: Укажите сетевой интерфейс для получения исходного IP-адреса для исходящих пробных пакетов. Обычно это полезно только для многоуровневого хоста. (См.-s флаг для другого способа сделать это.)
  • -Я: Используйте ICMP ECHO вместо дейтаграмм UDP.
  • -m: Установите максимальное время ожидания (максимальное количество переходов), используемое в исходящих пробных пакетах. По умолчанию используется 30 переходов (это же значение по умолчанию используется для TCP-соединений).
  • -n: Вычислять адреса точек печати численно, а не символически и численно (сохраняет имя сервера имен имен для каждого найденного на пути шлюза).
  • -п: Установите базовый номер порта UDP, используемый в пробниках (по умолчанию - 33434). Traceroute надеется, что ничто не слушает порты UDP база в base + nhops - 1 на целевом хосте (так что сообщение ICMP PORT_UNREACHABLE будет возвращено для завершения трассировки маршрута). Если что-то прослушивает порт в диапазоне по умолчанию, этот параметр можно использовать для выбора неиспользуемого диапазона портов.
  • -р: Обход обычных таблиц маршрутизации и отправка непосредственно на хост в подключенной сети. Если хост не подключен к сети напрямую, возвращается ошибка. Эта опция может использоваться для ping локального хоста через интерфейс, который не имеет маршрута через него (например, после того, как интерфейс был сброшен на маршрутизация (8C)).
  • -s: Используйте следующий IP-адрес (который обычно указывается как IP-номер, а не имя хоста) в качестве исходного адреса в исходящих пробных пакетах. На многодомных хостах (с несколькими IP-адресами) эта опция может использоваться, чтобы заставить исходный адрес быть чем-то иным, чем IP-адрес интерфейса, на который отправлен пробный пакет. Если IP-адрес не является одним из адресов интерфейса этого аппарата, возвращается ошибка и ничего не отправляется. (См. флаг для другого способа сделать это.)
  • -t: Установить тип обслуживания в пробных пакетах до следующего значения (по умолчанию - 0). Значение должно быть десятичным целым числом в диапазоне от 0 до 255. Эта опция может использоваться, чтобы увидеть, будут ли разные типы услуг приводить к различным путям. (Если вы не используете 4.4bsd, это может быть академическим, поскольку обычные сетевые службы, такие как telnet и ftp, не позволяют вам контролировать TOS.) Не все значения TOS являются законными или значимыми - см. Спецификацию IP для определений. Полезные значения, вероятно,-t 16 '(низкая задержка) и `-t 8 '(высокая пропускная способность).
  • -v: Подробный вывод. Получены ICMP-пакеты, отличные от TIME_EXCEEDED и UNREACHABLE.
  • -w: Установите время (в секундах), чтобы ждать ответа на зонд (по умолчанию 5 секунд).
  • -Икс: Переключить контрольные суммы IP. Как правило, это предотвращает вычисление контрольных сумм IP контрольных сумм. В некоторых случаях операционная система может перезаписывать части исходящего пакета, но не пересчитывать контрольную сумму; таким образом, в некоторых случаях по умолчанию необходимо не вычислять контрольные суммы и использовать-Икс заставляет их рассчитываться. Обратите внимание, что контрольные суммы обычно требуются для последнего прыжка при использовании ICMP-зондов ECHO (), поэтому они всегда вычисляются при использовании ICMP.
  • -z: Установите время (в миллисекундах) для паузы между зондами (по умолчанию 0). Некоторые системы, такие как Solaris и маршрутизаторы Cisco, сообщают об ограничении скорости ICMP-сообщений. Хорошее значение для использования - 500 (например, 1/2 секунды).

Интерпретация результатов

Traceroute описывает путь, по которому IP-пакет следует интернет-хосту, запустив пакеты зонда UDP с небольшим TTL (время для жизни), а затем прослушивание ICMP «превышенного времени» ответа от шлюза. Мы начинаем наши пробники с TTL одного и увеличиваем на единицу, пока не получим ICMP «порт недоступен» (что означает, что пакет прибыл в пункт назначения) или достиг максимального значения попыток, которое по умолчанию составляет 30 переходов и может быть изменено с помощью-m флаг.

Когда traceroute выполняется, он отправляет три зонда при каждой настройке TTL, а затем печатает строку на консоли, показывающую TTL, адрес шлюза и время прохождения в оба конца каждого зонда. Если ответы зонда поступают из разных шлюзов, адрес каждой системы ответа печатается. Если в течение пятисекундного интервала времени нет ответа (изменено с помощью-w флаг), для этого зонда печатается звездочка.

Чтобы не допустить, чтобы хост-получатель был перегружен обработкой пробного пакета UDP, порт назначения установлен в значение, маловероятное для использования этим устройством. Если сеть или служба в пункте назначения использует этот порт, измените значение, используя-п флаг.

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

yak 71% traceroute nis.nsf.net. traceroute to nis.nsf.net (35.1.1.48), 30 прыжков max, 38 байт-пакет 1 helios.ee.lbl.gov (128.3.112.1) 19 мс 19 мс 0 мс 2 lilac-dmc.Berkeley.EDU (128.32. 216,1) 39 мс 39 мс 19 мс 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 мс 39 мс 19 мс 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 мс 40 мс 39 мс 5 кcн -nerif22.Berkeley.EDU (128.32.168.22) 39 ms 39 ms 39 ms 6 128.32.197.4 (128.32.197.4) 40 ms 59 ms 59 ms 7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 59 ms 8 129.140. 70.13 (129.140.70.13) 99 мс 99 мс 80 мс 9 129.140.71.6 (129.140.71.6) 139 мс 239 мс 319 мс 10 129.140.81.7 (129.140.81.7) 220 мс 199 мс 199 мс 11 nic.merit.edu (35.1 .1.48) 239 мс 239 мс 239 мс

Обратите внимание, что вторая и третья строки одинаковы. Этот результат относится к багги-ядру на второй системе hop-lbl-csam.arpa, которая пересылает пакеты с нулевым TTL (ошибка в распределенной версии 4.3 BSD). Вы должны угадать, какой путь пакеты принимают в кросс-кантри, поскольку NSFNet (129.140) не предоставляет переводы по адресам для своих NSS.

Более интересным примером является:

yak 72% traceroute allspice.lcs.mit.edu. traceroute to allspice.lcs.mit.edu (18.26.0.115), 30 переходов max 1 helios.ee.lbl.gov (128.3.112.1) 0 мс 0 мс 0 мс 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 мс 19 мс 19 мс 3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 мс 19 мс 19 мс 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 19 мс 39 мс 39 мс 5 ccn-nerif22 .Berkeley.EDU (128.32.168.22) 20 мс 39 мс 39 мс 6 128.32.197.4 (128.32.197.4) 59 мс 119 мс 39 мс 7 131.119.2.5 (131.119.2.5) 59 мс 59 мс 39 мс 8 129.140.70.13 ( 129.140.70.13) 80 мс 79 мс 99 мс 9 129.140.71.6 (129.140.71.6) 139 мс 139 мс 159 мс 10 129.140.81.7 (129.140.81.7) 199 мс 180 мс 300 мс 11 129.140.72.17 (129.140.72.17) 300 мс 239 мс 239 мс 12 * * * 13 128.121.54.72 (128.121.54.72) 259 мс 499 мс 279 мс 14 * * * 15 * * * 16 * * * 17 * * * 18 ALLSPICE.LCS.MIT.EDU (18.26) .0.115) 339 мс 279 мс 279 мс

Обратите внимание, что шлюзы на 12, 14, 15, 16 и 17 ударах либо не отправляют ICMP «превышенное время», либо посылают их с TTL, слишком малым, чтобы связаться с нами. Строки с 14 по 17 запускают код шлюза MIT C, который не отправляет сообщения с превышением времени.

Тихий шлюз 12 в приведенном выше примере может быть результатом ошибки в сетевом коде BSD 4. 23 BSD и его производных: машины, работающие с кодом 4.3 и ранее, отправляют недостижимое сообщение, используя любой TTL, который остается в исходной датаграмме. Поскольку для шлюзов оставшийся TTL равен нулю, ICMP «превышенное время» гарантированно не возвращает его нам. Поведение этой ошибки немного интереснее, когда она появляется в целевой системе:

1 helios.ee.lbl.gov (128.3.112.1) 0 мс 0 мс 0 мс 2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 мс 19 мс 39 мс 3 lilac-dmc.Berkeley.EDU (128.32.216.1 ) 19 мс 39 мс 19 мс 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 мс 40 мс 19 мс 5 ccn-nerif35.Berkeley.EDU (128.32.168.35) 39 мс 39 мс 39 мс 6 csgw. Berkeley.EDU (128.32.133.254) 39 мс 59 мс 39 мс 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 rip.Berkeley.EDU (128.32.131.22) 59 Миз ! 39 мс! 39 мс!

Обратите внимание, что есть 12 «шлюзов» (13 - конечный пункт назначения), а последняя половина из них отсутствует. Что действительно происходит, так это то, что сервер Покойся с миром (Sun-3 под управлением Sun OS 3.5) использует TTL из нашей прибывающей дейтаграммы в качестве TTL в ответе ICMP. Таким образом, ответ будет отсутствовать на пути возврата (без уведомления, отправленного кому-либо, поскольку ICMP не отправляются для ICMP), пока мы не проверим с TTL, который, по крайней мере, вдвое превышает длину пути - другими словами, rip на самом деле всего семь хмель.

Ответ, который возвращается с TTL из 1, является ключом к существованию этой проблемы. Traceroute печатает "!" после того, как TTL меньше или равно 1. Поскольку поставщики поставляют много устаревших (DEC's Ultrix, Sun 3.x) или нестандартных (HPUX) программ, ожидайте часто увидеть эту проблему и заботиться о том, чтобы выбрать целевой хост ваших зондов.

Другие возможные аннотации после времени!ЧАС, N!, или же (хост, сеть или протокол недоступны),S! (маршрут источника не прошел),! F- (требуется фрагментация - отображается значение MTU Discovery пути RFC1191),!ИКС (административное запрещение связи),! V (нарушение приоритета хоста),! C (предел приоритета в действии) или! (ICMP недостижимый код). Эти коды определены RFC1812, который заменяет RFC1716. Если почти все пробники приводят к некоторому недостижимому хосту, traceroute будет сдаваться и выходить.

Эта программа предназначена для использования в сетевых тестах, измерениях и управлении. Он должен использоваться в первую очередь для ручной развязки. Из-за нагрузки, которую он может наложить на сеть, неразумно использовать traceroute во время обычных операций или из автоматизированных сценариев.