Отследите, куда пакет данных идет с traceroute
Команда traceroute используется в Linux для отображения пути прохождения пакета информации от его источника к месту назначения. Одним из способов использования traceroute является обнаружение случаев потери данных по всей сети, что может указывать на то, что узел не работает.
Поскольку каждый переход в записи отражает новый сервер или маршрутизатор между исходным ПК и предполагаемой целью, просмотр результатов сканирования трассировки также позволяет выявлять медленные точки, которые могут отрицательно повлиять на сетевой трафик.
Синтаксис traceroute и другая информация, описанная ниже, применима только к машинам Linux. Traceroute по-разному используется в Windows.
Как работает Traceroute
Оценка конкретного маршрута, по которому следует сетевой трафик (или нахождение неверного шлюза, отбрасывающего ваши пакеты), представляет несколько проблем, связанных с устранением неполадок. Traceroute использует поле time to live протокола IP для запроса ответа ICMP TIME_EXCEEDED от каждого шлюза по пути к хосту назначения.
Единственный параметр, который необходимо указать при выполнении команды traceroute, – это имя хоста или IP-адрес места назначения.
Синтаксис трассировки и переключатели
traceroute [ -dFInrvx ] [ -f first_ttl ] [ -g шлюз ] [ -i iface ] [ -m max_ttl] [ -p порт ] [ -q nqueries ] [ -s src_addr ] [ – t tos ] [ -w время ожидания ] [ -z pausemsecs ] хоста [ packetlen ]
Хотя вышеизложенное показывает, как команда traceroute должна быть записана для работы в командной строке, производительность или выходные данные команды можно изменить, указав один или несколько необязательных переключателей.
| Переключатель | Объяснение |
| -f | Установите начальное время жизни, используемое в первом исходящем тестовом пакете. |
| -F | Установите бит “не фрагментировать”. |
| -d | Включить отладку на уровне сокетов. |
| -g | Укажите свободный исходный шлюз (максимум 8). |
| -i | Укажите сетевой интерфейс для получения исходного IP-адреса для исходящих тестовых пакетов. Обычно это полезно только на многосетевом хосте. (См. Флаг -s для другого способа сделать это.) |
| -I | Используйте ICMP ECHO вместо UDP-дейтаграмм. |
| -m | Установите максимальное время жизни (максимальное количество прыжков), используемое в исходящих тестовых пакетах. По умолчанию используется 30 переходов (то же самое, что используется по умолчанию для соединений TCP). |
| -n | Печатать адреса прыжка численно, а не символически и численно (сохраняет поиск адреса к имени на сервере имен для каждого шлюза, найденного в пути). |
| -p | Установите базовый номер порта UDP, используемый в пробах (по умолчанию 33434). Traceroute надеется, что ничего не прослушивает порты UDP от base до base + nhops – 1 на хосте назначения (поэтому будет возвращено сообщение ICMP PORT_UNREACHABLE для завершения трассировки маршрута). Если что-то прослушивает порт в диапазоне по умолчанию, этот параметр можно использовать для выбора неиспользуемого диапазона портов. |
| -r | Обход таблиц обычной маршрутизации и отправка непосредственно на хост в подключенной сети. Если хост не находится в сети с прямым подключением, возвращается ошибка. Эту опцию можно использовать для проверки связи с локальным хостом через интерфейс, у которого нет маршрута через него (например, после того, как интерфейс был отброшен routed (8C)). |
| -s | Используйте следующий IP-адрес (который обычно задается как IP-адрес, а не имя хоста) в качестве адреса источника в исходящих тестовых пакетах. На многодомных хостах (с более чем одним IP-адресом) этот параметр можно использовать, чтобы заставить исходный адрес отличаться от IP-адреса интерфейса, на который отправляется тестовый пакет. Если IP-адрес не является одним из адресов интерфейса данного аппарата, возвращается ошибка и ничего не отправляется. (См. Флаг -i для другого способа сделать это.) |
| -t | Установите для типа обслуживания в тестовых пакетах следующее значение (по умолчанию ноль). Значение должно быть десятичным целым числом в диапазоне от 0 до 255. Этот параметр можно использовать, чтобы увидеть, приводят ли разные типы обслуживания к разным путям.(Если вы не используете 4.4bsd, это может быть академическим, так как обычные сетевые сервисы, такие как telnet и ftp, не позволяют вам контролировать TOS.) Не все значения TOS являются законными или значимыми – см. Определения IP-спецификации. Полезные значения: ` -t 16 ‘(низкая задержка) и` -t 8 ‘ (высокая пропускная способность). ). |
| -v | Подробный вывод. Полученные ICMP-пакеты, кроме TIME_EXCEEDED и UNREACHABLE, перечислены в списке. |
| -w | Установите время (в секундах) ожидания ответа на запрос (по умолчанию 5 секунд). |
| -x | Переключение контрольных сумм IP. Обычно это не позволяет traceroute вычислять контрольные суммы IP. В некоторых случаях операционная система может перезаписывать части исходящего пакета, но не пересчитывать контрольную сумму; таким образом, в некоторых случаях по умолчанию не рассчитываются контрольные суммы, а использование -x приводит к их вычислению. Обратите внимание, что контрольные суммы обычно требуются для последнего прыжка при использовании зондов ICMP ECHO ( -I ), поэтому они всегда рассчитываются при использовании ICMP. |
| -z | Установите время (в миллисекундах) для паузы между пробами (по умолчанию 0). Некоторые системы, такие как Solaris и маршрутизаторы от Cisco, ограничивают скорость передачи сообщений icmp. Хорошее значение для этого – 500 (например, 1/2 секунды). |
Интерпретация результатов
Traceroute обрисовывает путь, по которому IP-пакет следует к Интернет-хосту, запуская тестовые пакеты UDP с небольшим TTL (время жизни), а затем прослушивая ICMP-ответ «превышено время» от шлюза. Мы запускаем наши тесты с TTL, равным единице, и увеличиваем его на единицу, пока не получим ICMP «порт недоступен» (что означает, что пакет прибыл в пункт назначения) или не достигнем максимального значения попыток, которое по умолчанию составляет 30 прыжков и может быть изменено с помощью клавиши -m флаг.
Когда traceroute выполняется, он отправляет три зонда с каждой настройкой TTL, а затем выводит на консоль строку, показывающую TTL, адрес шлюза и время прохождения сигнала в обоих направлениях. Если ответы зондирования поступают из разных шлюзов, печатается адрес каждой отвечающей системы. Если в течение пятисекундного интервала ожидания ответа нет (изменяется с помощью флага -w ), для этого зонда печатается звездочка.
Чтобы предотвратить перегрузку хоста назначения при обработке зондирующего пакета UDP, для порта назначения установлено значение, которое вряд ли будет использоваться этим устройством. Если сеть или служба в пункте назначения использует этот порт, измените значение с помощью флага -p .
Образец использования и вывода вернет результаты, подобные этому примеру:
[yak 71]% traceroute nis.nsf.net.
traceroute to nis.nsf.net (35.1.1.48), максимум 30 прыжков, пакет 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 ccn-nerif22.Berkeley.EDU (128.32.168.22) 39 мс 39 мс 39 мс
6 128.32.197.4 (128.32.197.4) 40 мс 59 мс 59 мс
7 131.119.2.5 (131.119.2.5) 59 мс 59 мс 59 мс
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 мс
Вторая и третья строки одинаковы. Этот результат связан с ошибочным ядром в системе второго перехода – 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 прыжков
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] и его производных: машины, использующие код 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 – конечный пункт назначения), и последняя половина из них отсутствует. На самом деле происходит то, что сервер с именем rip (Sun-3 под управлением Sun OS 3.5) использует TTL из нашей поступающей дейтаграммы в качестве TTL в своем ответе ICMP. Таким образом, ответ будет задерживаться на обратном пути (без уведомления, отправленного никому, поскольку ICMP не отправляются для ICMP), пока мы не проверим TTL, который по крайней мере вдвое больше длины пути – другими словами, rip на самом деле только семь прыгает прочь
Ответ, который возвращается с TTL, равным 1, является подсказкой, что эта проблема существует. Traceroute печатает! через некоторое время, если TTL меньше или равен 1. Поскольку поставщики поставляют много устаревшего (DEC Ultrix, Sun 3.x) или нестандартного (HPUX) программного обеспечения, ожидайте частого появления этой проблемы и постарайтесь выбрать целевой хост ваших зондов.
Другие возможные аннотации по истечении этого времени: ! H , ! N или ! P (хост, сеть или протокол недоступны), ! S (исходный маршрут не пройден), ! F – (требуется фрагментация – отображается значение обнаружения MTU пути RFC1191), ! X (связь административно запрещена) , ! V (нарушение приоритета хоста), ! C (ограничение приоритета действует) или ! (недоступный код ICMP). Эти коды определены RFC1812, который заменяет RFC1716. Если почти все зонды приводят к некоторому недоступному хосту, traceroute сдается и завершается.
Эта программа предназначена для использования в тестировании, измерении и управлении сетью. Его следует использовать главным образом для ручной локализации неисправностей. Из-за нагрузки, которая может быть наложена на сеть, неразумно использовать traceroute во время обычных операций или из автоматических сценариев.
