Трассировка tracert. TRACERT – трассировка маршрута к заданному узлу в командной строке Windows

    Утилита трассировки маршрута до заданного узла TRACERT.EXE является одним из наиболее часто используемых инструментов сетевой диагностики. Основное ее назначение - получить цепочку узлов, через которые проходит IP-пакет, адресованный конечному узлу, имя или IP-адрес которого задается параметром командной строки.

Формат командной строки:

tracert [-d] [-h максЧисло] [-j списокУзлов] [-w таймаут] [-R] [-S адресИсточника] [-4] [-6] конечноеИмя

Параметры командной строки:

-d - не использовать разрешение в имена узлов.

-h максЧисло - максимальное число прыжков при поиске узла.

-j списокУзлов - свободный выбор маршрута по списку узлов (только IPv4).

-w таймаут - таймаут каждого ответа в миллисекундах.

-R - трассировка пути (только IPv6).

-S адресИсточника - использовать указанный адрес источника (только IPv6).

-4 - принудительное использование IPv4.

-6 - принудительное использование IPv6.

В основе трассировки заложен метод анализа ответов при последовательной отправке ICMP-пакетов на указанный адрес с увеличивающимся на 1 полем TTL. ("Время жизни" - Time To Live). На самом деле это поле не имеет отношения к времени, а является счетчиком числа возможных переходов при передаче маршрутизируемого пакета. Каждый маршрутизатор, получив пакет, вычитает из этого поля, сохраняемого в заголовке пакета, единицу и проверяет полученное значение счетчика TTL. Если значение стало равным нулю, такой пакет отбрасывается и отправителю посылается ICMP-сообщение о превышении времени жизни (сообщение "Time Exceeded", значение 0x11 в заголовке ICMP).

Если бы не было предусмотрено включение поля TTL в IP пакетах, то при ошибках в маршрутах, могла бы возникнуть ситуация, когда пакет будет вечно циркулировать в сети, пересылаемый маршрутизаторами по кругу.

    При выполнении команды tracert.exe сначала выполняется отправка ICMP пакета с полем TTL в заголовке равным 1 и первый в цепочке маршрутизатор (обычно это основной шлюз из настроек сетевого подключения) вычтя единицу из TTL получает его нулевое значение и сообщает о превышении времени жизни. Таким образом, утилита TRACERT.EXE получает IP-адрес первого маршрутизатора, участвующего в доставке пакетов конечному узлу. Эта последовательность повторяется трижды, поэтому в строке результата, формируемой tracert.exe, после номера перехода отображаются три значения времени отклика:
1     1 ms     1 - номер перехода (1 - первый маршрутизатор)
1 ms 192.168.1.1 - его адрес (или имя)

    Затем процедура повторяется, но TTL устанавливается равным 2 - первый маршрутизатор его уменьшит до 1 и отправит следующему в цепочке, который после вычитания 1 обнулит TTL и сообщит о превышении времени жизни. Утилита TRACERT.EXE получит второй IP-адрес узла, участвующего в доставке пакета получателю и его время ответа. Процесс трассировки будет продолжаться до тех пор, пока не будет достигнут конечный узел, имя или адрес которого заданы в качестве параметра командной строки, например, tracert yandex.ru , или до обнаружения неисправности, не позволяющей доставить пакет. По умолчанию, утилита TRACERT.EXE использует счетчик максимального числа переходов равный 30, что должно быть достаточно для достижения любого узла на планете. При необходимости, иное значение счетчика можно задать с помощью параметра -h

Пример результатов выполнения tracert google.com

tracert google.com - трассировка маршрута к узлу google.com

Результат:


Трассировка маршрута к google.com с максимальным числом прыжков 30:
1 1 ms 2 498 ms 444 ms 302 ms ppp83-237-220-1.pppoe.mtu-net.ru
3 * * * .
4 282 ms * * a197-crs-1-be1-53.msk.stream-internet.net
5 518 ms 344 ms 382 ms ss-crs-1-be5.msk.stream-internet.net
6 462 ms 440 ms 335 ms m9-cr01-po3.msk.stream-internet.net
7 323 ms 389 ms 339 ms bor-cr01-po4.spb.stream-internet.net
8 475 ms 302 ms 420 ms anc-cr01-po3.ff.stream-internet.net
9 334 ms 408 ms 348 ms 74.125.50.57
10 451 ms 368 ms 524 ms 209.85.255.178
11 329 ms 542 ms 451 ms 209.85.250.140
12 616 ms 480 ms 645 ms 209.85.248.81
13 656 ms 549 ms 422 ms 216.239.43.192
14 378 ms 560 ms 534 ms 216.239.43.113
15 511 ms 566 ms 546 ms 209.85.251.9
16 543 ms 682 ms 523 ms 72.14.232.213
17 468 ms 557 ms 486 ms 209.85.253.141
18 593 ms 589 ms 575 ms yx-in-f100.google.com

Трассировка завершена.

    В результатах трассировки могут присутствовать строки, где вместо адреса узла отображается звездочка (узел номер 3 в примере). Это не обязательно является признаком неисправности маршрутизатора, и чаще всего, говорит о том, что настройки данного узла запрещают отправку ICMP-сообщений по соображениям безопасности и уменьшения нагрузки на канал при в случае некоторых разновидностей DDoS-атак. Например, подобные настройки используются в сетях Microsoft . Серверы корпорации не отвечают на ping и не позволяют выполнить трассировку маршрута к ним.

Примеры использования TRACERT

tracert google.com - выполнить трассировку маршрута к узлу google.com .

tracert 8.8.8.8 - выполнить трассировку маршрута к узлу с IP-адресом 8.8.8.8

tracert -d yandex.ru - выполнить трассировку маршрута к узла yandex.ru без разрешения IP-адресов в имена узлов. Трассировка в таком режиме выполняется быстрее.

tracert -d -6 ipv6.google.com - выполнить трассировку с использованием протокола IPv6.

Пример результатов трассировки с использованием протокола IPv6:

trace to ipv6.google.com (2a00:1450:4013:c00::71), 30 hops max, 40 byte packets 1 2a02:348:82::1 (2a02:348:82::1) 8.087 ms 8.063 ms 8.086 ms 2 te0-22.cr1.nkf.as49685.net (2001:4cb8:40b:1::1d01) 2.143 ms 2.129 ms 2.103 ms 3 amsix-router.google.com (2001:7f8:1::a501:5169:1) 1.379 ms 1.415 ms 1.422 ms 4 (2001:4860::1:0:87ab) 1.437 ms (2001:4860::1:0:87aa) 2.157 ms (2001:4860::1:0:87ab) 1.408 ms 5 (2001:4860::8:0:87b0) 1.494 ms 1.469 ms (2001:4860::8:0:87b2) 8.350 ms 6 (2001:4860::8:0:b1b7) 5.364 ms 5.321 ms 4.748 ms 7 (2001:4860::2:0:8651) 4.653 ms 6.994 ms (2001:4860::2:0:8652) 13.926 ms 8 ee-in-x71.1e100.net (2a00:1450:4013:c00::71) 4.732 ms 4.733 ms 4.783 ms

Бывают в сетевой жизни (особенно у dial-up юзеров 😉 моменты, когда невозможно достучаться до какого-нибудь хоста (у меня это часто www.microsoft.com ;-|) - здесь то на помощь и придет эта утилита (в Windows - tracert.exe). С ее помощью можно попытаться определить на каком участке IP-сети произошел сбой - то ли хост упал, то ли у провайдер тормоза, или у тебя с IP-соединением хреново:).

Но за что я по-настоящему люблю tracert - так это за те возможности исследования IP-сетей, которые он дает - а они бывают разные, по масштабам и по целенаправленности;). Первым шагом может стать исследование подсети своего провайдера. С помощью traceroute ты можешь исследовать саму сети, применяя на практике полученные теоретические знания - о маршрутизации, серверах DNS, бэкбонах, системах подсетей, да мало ли о чем еще;).

Как это работает?

Для начала нужно вспомнить формат заголовка IP-пакета, точнее одно из его полей - TTL (Time To Live). Это восьмибитное поле задает максимальное число хопов (hop - "прыжок" - прохождение дейтаграммы от одного маршрутизатора к другому) в течение которого пакет может находиться в сети. Каждый маршрутизатор,
обрабатывающий эту дейтаграмму, выполняет операцию TTL=TTL-1. Когда TTL становится равным нулю, маршрутизатор уничтожает пакет,
отправителю высылается ICMP-сообщение Time
Exceeded.

Утилита посылает в направлении заданного хоста пакет с TTL=1, и ждет, от кого вернется ответ time exceeded. Отвечающий записывается как первый хоп (результат первого шага на пути к цели). Затем посылаются последовательно пакеты с TTL=2, 3, 4 и т.д. по порядку, пока при некотором значении TTL пакет не достигнет цели и не получит от нее ответ.

*nix traceroute посылает в сторону заданного хоста UDP-пакеты на произвольный порт - скорее всего не занятый другим сервисом (например 28942, 30471) или на зарезервированный, например 0, умолчанию - 33434. Сначала посылается серия из 3-х таких пакетов с TTL=1, по приходу ответов замеряется время прохождения и определяется доменное имя транзитного узла (хотя это зависит от заданных опций). Затем, посылаются очередные серии пакетов с одинаковым TTL, предназначенных для выявления одного и того же хопа. В конце мы получаем от конечного хоста отклик port unreachable (порт недоступен), что означает завершение трассировки.
Стандартный консольный Windows tracert работает точно также, но посылает только ICMP echo request пакеты.

Сам я охотно пользуюсь как стандартным tracert, так и вшитым в CyberKit (достаточно неплохой утилитой
еще является Necrosoft Quick Traceroute). Под Линукс ничего дополнительного посоветовать не могу - юзал только стандартный Debian"овский traceroute:).

В заключение скажу, не бойся экспериментировать - только так можно по настоящему "понять" сеть. Ищи информацию и пользуйся ею. Удачи.

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

Утилита ping позволяет только определить наличие проблемы, что узел не отвечает, но как узнать где обрывается соединение? Для этого применяется утилита traceroure. В этой небольшой инструкции мы рассмотрим как пользоваться traceroute linux, как понимать ее вывод и определить где же все-таки проблема. Но сначала рассмотрим, как работает traceroute.

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

Каждый пакет проходит на своем пути определенное количество узлов, пока достигнет своей цели. Причем, каждый пакет имеет свое время жизни. Это количество узлов, которые может пройти пакет перед тем, как он будет уничтожен. Этот параметр записывается в заголовке TTL, каждый маршрутизатор, через который будет проходить пакет уменьшает его на единицу. При TTL=0 пакет уничтожается, а отправителю отсылается сообщение Time Exceeded.

Команда traceroute linux использует UDP пакеты. Она отправляет пакет с TTL=1 и смотрит адрес ответившего узла, дальше TTL=2, TTL=3 и так пока не достигнет цели. Каждый раз отправляется по три пакета и для каждого из них измеряется время прохождения. Пакет отправляется на случайный порт, который, скорее всего, не занят. Когда утилита traceroute получает сообщение от целевого узла о том, что порт недоступен трассировка считается завершенной.

Утилита Traceroute

Перед тем как перейти к примерам работы с утилитой давайте рассмотрим ее синтаксис и основные опции. Синтаксис вызова очень прост:

$ traceroute опции адрес_узла

В качестве адреса может использоваться ip адрес или доменное имя. Рассмотрим основные опции:

  • -4 или -6 - использовать ipv4 или ipv6 протокол;
  • -I - использовать ICMP пакеты вместо UDP;
  • -T - использовать TCP пакеты вместо UDP;
  • -F - не фрагментировать пакеты;
  • -f - указать TTL с которого нужно начать;
  • -g - передавать пакет через указанный шлюз;
  • -i - передавать пакет через указанный интерфейс;
  • -m - максимальное количество узлов, через которые пройдет пакет;
  • -q - количество пакетов, отправляемых за раз, по умолчанию три;
  • -n - не узнавать доменные имена;
  • -p - указать порт вместо порта по умолчанию;
  • -w - установить время ожидания ответа от узла, по умолчанию полсекунды;
  • -r - использовать другой роутер вместо того, что указанный в таблице маршрутизации;
  • -z - минимальный интервал между пакетами;
  • -U - использовать UDP с увеличением номера порта;
  • -UL - использовать протокол UDPLITE;
  • -D - использовать протокол DCCP;
  • --mtu - указать размер пакета;
  • -P - протокол, доступны такие значения: raw, dccp, udplite, udp, tcpconn, tcp, icmp.

Это не все опции утилиты, но все основные, которыми вы будете пользоваться. Дальше перейдем практике того, как выполняется трассировка сети Linux.

Примеры трассировки сети в Linux

Например, выполним трассировку до сервера сайт:

sudo traceroute сайт

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

У вас, наверное, возник вопрос, почему время прохождения для некоторых узлов такое долгое? Ведь если выполнить ping, то общее время будет намного меньше. Дело в том, что время засекается для пути пакета туда и обратно. От запроса до ответа. Это раз, но еще нужно учитывать что маршрутизаторы дают высший приоритет для приходящих пакетов, когда для сервисных задержки могут быть более длинными.

Еще, вместо одного узла вы можете видеть звездочки traceroute. Это еще не значит, что он не работает. Это означает что всего лишь он не захотел нам отвечать. Давайте проверим еще что-нибудь, например, публичный DNS google:

sudo traceroute 8.8.8.8

Здесь уже больше узлов, и такая же ситуация со звездочками. Если бы на пути к серверу возникла ошибка, мы бы это увидели. Например, узел 195.153.14.1 нам не ответил и мы смогли отследить запрос только до 212.162.26.169.

sudo traceroute 195.153.14.1

Иногда трассировка с помощью UDP не работает, это может произойти потому, что фаервол блокирует все лишние пакеты. Мы можем воспользоваться ICMP с помощью опции -I.

sudo traceroute history.pl

sudo traceroute -I history.pl

Но трассировка может использоваться не только для обнаружения обрыва в цепочке маршрутизаторов. У нее еще есть достаточно интересное применение по исследованию сети. Например, вы можете попытаться определить использование подсетей провайдером. Отправим три запроса на разные адреса:

sudo traceroute сайт
$ sudo traceroute history.pl
$ sudo traceroute habrahabr.ru


Затем сравните выводы этих команд. Вы увидите, что начальные IP адреса одинаковые. Мы можем сделать вывод, что наш роутер 192.168.1.1 подключен к локальной сети провайдера 195.5.8.0/24, которая, в свою очередь, подключена к сети 10.50.50.0/24 откуда уже получает доступ к внешней сети.

Применение данных утил позволяет проследить маршрут до удаленного хоста, определить время круговой задержки (RTT-round-trip delay time), IP-адрес и в некоторых случаях доменное имя промежуточного маршрутизатора. В основе их работы лежат ICMP-сообщения об ошибках.

Как работает Tracert.

Значение времени жизни (TTL) первого отправляемого пакета устанавливается равным 1. Когда протокол IP первого маршрутизатора принимает этот пакет, то он в соответствии со своим алгоритмом уменьшает TTL на единицу и получает 0. Маршрутизатор отбрасывает пакет с нулевым временем жизни и возвращает узлу-источнику ICMP-сообщение об ошибке истечения времени дейтаграммы (ICMP-сообщение тип 11 код 0). Это сообщение содержит имя маршрутизатора и его IP-адрес. Когда это ICMP-сообщение прибывает к отправителю, тот по значению таймера узнает время оборота пакета(RTT), а также (из ICMP-сообщения) имя и IP-адрес промежуточного маршрутизатора. Затем посылается следующий IP-пакет, но теперь со значением TTL равным 2. Этот пакет уже доходит до второго маршрутизатора, но опять там «умирает» о чем аналогичным, же образом сообщается узлу отправителю. И так до тех пор, пока не достигнет конечного узла. На основании данных ответов строится трассировка. Например:

Трассировка маршрута к rt.ru с максимальным числом прыжков 30: 1 3 ms 1 ms 2 ms net235-72.ufa.ertelecom.ru 2 2 ms 2 ms 1 ms bb2.bsr02.ufa.ertelecom.ru 3 2 ms 1 ms 1 ms lag-10-438.bbr01.samara.ertelecom.ru 4 18 ms 18 ms 18 ms 46.61.227.202 5 19 ms 19 ms 18 ms 46.61.227.201 6 19 ms 19 ms 19 ms so-0-0-0.m10-ar2.msk.ip.rostelecom.ru 7 19 ms 19 ms 19 ms 109.207.0.226 8 19 ms 19 ms 19 ms www.rt.ru Трассировка завершена.

Из данной трассы мы видим, что хост www.rt.ru доступен с числом прыжков(хопов) — 8, его ip 109.207.14.4, и время круговой задержки до данного ресурса составляет 19ms.

Как работает Traсeroute.

Принцип идентичный, за одним исключением. Утила по умолчанию, посылает в сторону заданного хоста UDP-датаграммы на какой-то произвольный порт, обычно — на «высокий», скорее всего не занятый другим сервисом (например 12500, 30678) или на зарезервированный (например 0), в свежих версиях порт по умолчанию — 33434. Сначала посылается серия из 3-х таких пакетов с TTL=1, по приходу ответов замеряется время прохождения и определяется доменное имя транзитного узла. Затем, как сказано выше, посылаются очередные серии пакетов с TTL=2 и т.д. В конце мы получаем от конечного хоста отклик «Порт недоступен» (PORT_UNREACHABLE), что означает завершение трассировки.

Пример трассировки до того же ресурса:

Traceroute to rt.ru (109.207.14.4), 30 hops max, 40 byte packets 1 * * * 2 bb1.bsr02.ufa.ertelecom.ru (212.33.234.101) 13.059 ms 13.222 ms 13.597 ms 3 lag-10-438.bbr01.samara.ertelecom.ru (212.33.233.111) 0.360 ms 0.382 ms 0.612 ms 4 46.61.227.202 (46.61.227.202) 17.484 ms 17.511 ms 17.512 ms 5 46.61.227.201 (46.61.227.201) 17.803 ms 17.791 ms 17.778 ms 6 so-0-0-0.m10-ar2.msk.ip.rostelecom.ru (87.226.139.74) 18.179 ms 18.211 ms 17.988 ms 7 109.207.0.226 (109.207.0.226) 18.213 ms 18.697 ms 18.288 ms 8 * * * ^C

Из результата вывода возникает вопрос, почему в этом случае трассировка не дошла до конца, и появились в выводе так называемые звездочки (* * *), а ответ как раз и заключается в различие (в данном примере). Очень часто, маршрутизаторы/хосты настраиваются таким образом, чтобы они не отвечали на подобного рода запросы, в таком случае и появляются звездочки. Это совершенно не значит, что имеются какие-то проблемы. Делается это для того, чтобы разгрузить оборудование. В данном примере 1 и 8 хоп не отвечает на UDP-датаграммы, однако если запустить утилу traceroute c ключиком -I, то трассировка дойдет, т.к. данный ключ заставляет посылаю уже ICMP-датаграммы.

$ traceroute -I rt.ru traceroute to rt.ru (109.207.14.4), 30 hops max, 40 byte packets 1 net233-86.ufa.ertelecom.ru (212.33.233.86) 162.924 ms 163.654 ms 163.666 ms 2 bb1.bsr02.ufa.ertelecom.ru (212.33.234.101) 8.095 ms 38.117 ms 50.262 ms 3 lag-10-438.bbr01.samara.ertelecom.ru (212.33.233.111) 0.382 ms 0.407 ms 0.417 ms 4 46.61.227.202 (46.61.227.202) 17.592 ms 17.623 ms 17.613 ms 5 46.61.227.201 (46.61.227.201) 17.597 ms 17.609 ms 17.613 ms 6 so-0-0-0.m10-ar2.msk.ip.rostelecom.ru (87.226.139.74) 17.943 ms 17.924 ms 18.001 ms 7 109.207.0.226 (109.207.0.226) 18.092 ms 18.026 ms 18.010 ms 8 www.rt.ru (109.207.14.4) 18.205 ms 18.301 ms 18.308 ms

Заключение.

Следует отметить, что звездочки могут возникать и при трассировке ICMP-пакетами, это также не значит, что существует проблема. Все зависит от того, как настроил оборудование администратор. Это его железо и настраивается оно с его потребностями. Данное явление вполне нормально. Также не следует паниковать, если конечный хост не пингуется. Вполне возможно, что ресурс просто от них закрылся.

Рекомендуем почитать