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

Применение данных утил позволяет проследить маршрут до удаленного хоста, определить время круговой задержки (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-пакетами, это также не значит, что существует проблема. Все зависит от того, как настроил оборудование администратор. Это его железо и настраивается оно с его потребностями. Данное явление вполне нормально. Также не следует паниковать, если конечный хост не пингуется. Вполне возможно, что ресурс просто от них закрылся.

Выполняет трассировку до точки назначения с помощью посылки адресату эхо-сообщений. Посылка осуществляется по протоколу Control Message Protocol (ICMP) с постоянным увеличением значений срока жизни пакетов (Time to Live, TTL).

Выведенный путь - это список ближайших интерфейсов маршрутизаторов, находящихся на пути между узлом источника и точкой назначения. Ближний интерфейс представляют собой интерфейс маршрутизатора, который является ближайшим к узлу отправителя на пути. Запущенная без параметров, команда tracert выводит справку.

Для проверки сети также можно воспользоваться командами:

• PING - основная TCP/IP-команда, используемая для устранения неполадки в соединении, проверки возможности доступа и разрешения имен;
• PATHPING - предоставляет информацию о латентности сети и потерях данных на промежуточных узлах.

Параметры и ключи утилиты TRACERT

tracert [-d] [-h максимальное_число_переходов] [-j список_узлов] [-w интервал [имя_конечного_компьютера]

• -d - Предотвращает попытки команды tracert разрешения IP-адресов промежуточных маршрутизаторов в имена. Увеличивает скорость вывода результатов команды tracert.

• -h максимальное_число_переходов - Задает максимальное количество переходов на пути при поиске конечного объекта. Значение по умолчанию равно 30.

• -j список_узов - Указывает для сообщений с эхо-запросом использование параметра свободной маршрутизации в заголовке IP с набором промежуточных мест назначения, указанных в списке_узлов. При свободной маршрутизации успешные промежуточные места назначения могут быть разделены одним или несколькими маршрутизаторами. Максимальное число адресов или имен в списке - 9. Список_адресов представляет набор IP-адресов (в точечно-десятичной нотации), разделенных пробелами.

• -w интервал - Определяет в миллисекундах время ожидания для получения эхо-ответов протокола ICMP или ICMP-сообщений об истечении времени, соответствующих данному сообщению эхо-запроса. Если сообщение не получено в течение заданного времени, выводится звездочка (*). Таймаут по умолчанию 4000 (4 секунды).

• имя_конечного_компьютера - Задает точку назначения, указанную IP-адресом или именем узла.

• -? - Отображает справку в командной строке по утилите tracert.

Примеры команды TRACERT

• Чтобы отобразить справку в командной строке по команде введите: tracert /? ;
• Чтобы выполнить трассировку пути к узлу, введите команду: tracert ya.ru;
• Чтобы выполнить трассировку пути к узлу и предотвратить разрешение каждого IP-адреса в имя, введите: tracert -d ya.ru.

Видео - Работа с утилитой TRACERT

Перевод мой.

Если вы работаете сетевым администратором, системным администратором или в какой-либо эксплуатационной группе, вы, возможно, слышали об инструменте с названием TRACEROUTE. Это очень удобный инструнт, доступный по умолчанию во многих операционных системах.

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

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

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

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

В этой статье я объясню работу Traceroute и типы инструментов Traceroute и их различия. Мы также рассмотрим разные параметры, доступные для команды traceroute в Linux

Сначала основное

Каждый пакет, который вы отправляете в интернет, имеет поле, названное TTL. TTL означает время жизни (time to live). Хотя оно и называется временем жизни, в действительности это не время в секундах, а совсем другая история.

TTL не изменяется ни количеством секунд, ни количеством хопов. Это максимальное количество хопов, которое пакет может пройти по сети до того, как будет уничтожен.

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

Что бы произошло, если бы вообще не было TTL? Если бы не было TTL, IP-пакет перетекал бы бесконечно от одного маршрутизатора к другому и дальше, и дальше, бесконечно ища назначение. Значение TTL устанавливается отправителем внутри IP-пакета (человек, использующий систему или отправляющий пакет, не замечает этих вещей, происходящих “за кулисами”, но это автоматически обрабатывается операционной системой)

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

Первоначального отправителя информируют, что TTL истекло, и он не может передать пакет дальше.

Давайте скажем, что мне нужно достичь адреса 10.1.136.23, и мой TTL - 30 хопов, что значит, что я могу проследовать максимум 30 хопов, чтобы достичь цели, перед тем как пакет будет уничтожен.

Но как маршрутизаторы по пути определяют, что достигнут лимит TTL? Каждый маршрутизатор по пути между источником и назначением продолжает уменьшать значение TTL перед отправкой следующему маршрутизатору. Что означает, что если у меня TTL по умолчанию равен 30, мой первый маршрутизатор уменьшит его до 29 и отправит следующему маршрутизатору по пути.

Получающий маршрутизатор делает его равным 28 и отправляет следующему и т.д. Если маршрутизатор получает пакет с TTL, равным единице (это означает, что уже нет дальнейших перемещений или пересылки), пакет уничтожается. Но маршрутизатор, который уничтожает пакет, информирует первоначального отправителя о том, что TTL value has exceeded! (время жизни пакета истекло)

Информация, отправленная маршрутизатором, получившим пакет с TTL равным единице, называется "ICMP TTL exceeded messages ". Разумеется, в интернете, когда вы отправляете что-либо получателю, получатель узнает адрес отправителя.

Следовательно, когда сообщение ICMP TTL exceeded отправляется маршрутизатором, первоначальный отправитель узнаёт адрес маршрутизатора.

Traceroute использует сообщения TTL exceeded чтобы обнаружить маршрутизаторы, которые встречаются на пути к цели (поскольку эти сообщения, отправляемые маршрутизатором, содержат его адрес). <>/p>

Но как traceroute использует сообщение “TTL exceeded” чтобы узнать, какие маршрутизаторы/хопы между ними?

Вы должно быть думаете, /pчто собщения “TTL exceeded” отправляются только маршрутизатором, который получает пакет с TTL 1. Это верно, каждый маршрутизатор между вами и получателем не станет высылать сообщения TTL exceeded. Тогда как вы найдете адреса всех маршрутизаторов/хопов между вами и назначением? Так ведь основная цель traceroute - идентифицировать хопы между вами и назначением.

Но вы можете использовать поведение сообщений TTL exceeded маршрутизаторов/хопов по пути, целенаправленно отправляя пакеты с TTL, равным 1

См. примерную схему всего процесса на схеме, где отправитель использует traceroute к одному из серверов в удалённом месте

Давайте посмотрим на то, что просходит за кулисами. Когда я запускаю команду traceroute -n 8.8.8.8, что делает мой компьютер? - отправляет UDP-пакет. (Да, UDP. Не волнуйтесь, мы обсудим это подробно). UDP-пакет содержит следующее:

• Мой адрес отправителя
• Адрес назначения (8.8.8.8)
• И номер порта назначения, который неверен. Это разумеет, что traceroute отправляет пакет в UDP-порт, в диапазоне от 33434 до 33534, который обычно не используется.

Давайте посмотрим, как это работает

Шаг 1. Мой адрес отправителя создает пакет с адресом назначения 8.8.8.8 и портом назачения между 33434 и 33534. И главное, что он делает - это делает значение TTL равным 1

Шаг 2. Конечно, мой пакет достигает шлюзового сервера. Получая мой пакет, шлюз уменьшает TTL на единицу (все маршрутизаторы/хопы между уменьшают TTL на 1). Когда TTL уменьшается до 1 (1-1=0), значение TTL становится нулевым. Поэтому мой шлюзовый сервер шлёт мне обратно сообщение TTL time exceeded. Прошу запомнить, что когда мой шлюзовый сервер отправляет TTL exceeded мне, он отправляет мне первые 28 байтов того пакета, что я высылал.

Шаг 3 : Получив это сообщение “TTL Time exceeded”, моя программа traceroute сможет узнать адрес и другие сведения о первом хопе, который является моим шлюзовым сервером.

Шаг 4 : Теперь программа трассировки снова отправит тот же UDP пакет с назначением 8.8.8.8 и случайным UDP портом назначения от 33434 до 33534. Но на этот раз я сделаю первоначальный TTL =2. В результате, мой шлюз или маршрутизатор снизит его на 1, а затем передаст этот пакет, следующему хопу/маршрутизатору (пакет, отправленный моим шлюзом к следующему узлу будет иметь значение TTL 1).

Шаг 5 : При получении UDP пакета следующий переход к моему шлюзовому серверу снова уменьшит его до 1, что означает, что теперь TTL вновь стал равен 0. Следовательно, он пошлет мне оттуда сообщение ICMP Time exceeded с адресом источника а также первые 28 байт заголовка пакета, который я отправил.

Шаг 6 . При получении TTL Time exceeded, моя программа traceroute узнаёт IP-адрес маршрутизатора/хопа и показывает мне его на экране.

Шаг 7 . Теперь моя программа traceroute вновь создаст такой же UDP-пакет со случайным UDP-портом и адресом назначения 8.8.8.8. Но в этот раз значение TTL равно трём, таким образом TTL автоматически становится нулевым, когда достигает третьего хопа/маршрутизатора (прошу вспомнить, что мой шлюз и следующий за ним хоп уменьшают его на единицу). Так что он ответит мне сообщением TTL Time exceeded и моя программа taceroute узнает об IP-адресе маршрутизатора/хопа

Шаг 8 : Получив этот ответ, программа traceroute ещё раз создаст UDP-пакет, на этот раз со значением TTL=4. Если я получу TTL Time exceeded и для него также, то моя программа traceroutе будет посылать UDP пакет с TTL=5 и так далее.

Но как моя программа Traceroute узнает, что конечный пункт 8.8.8.8 достигнут? Программа трассировки узнает об этом так: когда первоначальный приёмник пакета 8.8.8.8 (помните, что у всех UDP-пакетов был адрес получателя 8.8.8.8) получает запрос, он пошлёт мне сообщение, которое будет совершенно отличным от всех сообщений "TTL Time exceeded ".

Когда изначальный получатель (8.8.8.8) получает мой UDP-пакет, он отправляет мне сообщение "ICMP Destination/PORT Unreachable ". Это должно произойти, потому что мы всегда отправляем случайный UDP-порт между 33434 до 33534. Поэтому моя программа Traceroute будет знать, что мы достигли конечного пункта назначения и прекратит посылать какие-либо дополнительные пакеты.

Сейчас всё, что описано словами, называется теорией. Нам нужно подтвердить это, запустив Tcpdump во время Traceroute. Давайте посмотрим на вывод tcpdump. Прошу обратить внимание на то, то я не показываю вам полный вывод tcpdump, поскольку он слишком длинный.

Запустите traceroute в одном терминале вашей Linux машины. И в другом терминале запустите tcpdump, чтобы увидеть, что происходит.

Вывод выше показывает только UDP-пакеты, отправленные с моей машины. Я покажу ответные сообщения отдельно, чтобы было яснее

Обратите внимание на TTL в каждой строке. Она начинается с TTL, равного единице, затем 2, и затем 3 до TTL равного 6. Вам может показаться странным, почему мой сервер отправляет 3 UDP-сообщения с TTL=1, а затем 2, а затем 3?

Причина этого заключается в вычислении среднего время прохождения. Программа traceroute отправляет три UDP-пакета для каждого хопа, чтобы измерить точное среднее время прохождения пакета. Среднее время прохождения - ни что иное как время в миллисекундах, которое потребовалось для отправки, а затем получения ответа. Я намеренно не упомянул об этом в самом начале, чтобы избежать путаницы.

Таким образом, нижняя строка моей программы traceroute отправляет три UDP-пакета каждому хопу, чтобы просто вычислить приблизительное время прохождения. Поэтому вывод traceroute показывает эти три значения. Давайте рассмотрим поближе вывод traceroute. Он показывает три значения в милисекундах для каждого хопа, чтобы получить четкое представление о времени прохождения.

Теперь давайте посмотрим, ответ мы получили от всех хопов через TCPDUMP. Обратите внимание, что ответные сообщения, которые привожу ниже, являются частью того же ТСРDUMP, который я запустил ранее, но показываю их вам отдельно, чтобы было яснее.

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

Ответные сообщения выглядят как показано ниже.

Прошу обратить внимание, что сообщения ICMP time exceeded показаны выше (я не показал все ответные сообщения)

Теперь позвольте мне показать последнее послание, которое отличается от ICMP time exceeded. Это сообщение destination port unreachable (порт назначения недостижим), как говорилось ранее. И программа traceroute узнает, что наша цель достигнута.

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

Разные типы программ Traceroute

Существуют различные типы программ traceroute. Каждая из них работает немного по-своему. Но их общая концепция одна и та же. Все они использует значение TTL.

Почему разные реализации? Это потому, что вы можете использовать ту, которая применима к вашей среде. Если предположить, что файрволл блокирует трафик UDP, то вы можете использовать другую трассировку для этой цели. Различные типы приведены ниже.

Та, что мы использовали ранее - UDP трассировка. Это протокол по умолчанию, используемый программой traceroute в Linux. Тем не менее вы можете попросить нашу утилиту traceroute в Linux использовать протокол ICMP вместо UDP с помощью следующей команды.

Root@workstation:~# traceroute -I -n 8.8.8.8

ICMP для traceroute работает точно так же, как UDP traceroute. Программа traceroute будет отправлять ICMP Echo-запросы и хопы между ними будут отвечать ICMP-сообщениями "ICMP Time exceeded " (время истекло). Но конечный пункт назначения будет отправлять ICMP echo-ответ. Команда tracert, доступная в операционной системе Windows, по умолчанию использует ICMP метод трассировки маршрута.

И последний является самым интересным. Его называют TCPtraceroute. Он используется, потому что почти все файрволлы и промежуточные маршрутизаторы позволяют передавать TCP трафик. И если пакет на порт 80, который является веб-трафиком, то большинство маршрутизаторов пропускают этот пакет. TCPTRACEROUTE по умолчанию отправляет TCP SYN запросы на порт 80.

Все маршрутизаторы между источником и пунктом назначения будут посылать сообщение "TTL time exceeded " (время TTL истекло) , а адресат будет посылать либо пакет RST, если порт 80 закрыт, либо пакет SYN / ACK. (Но tcptraceroute не создает соединение TCP. При получении SYN / ACK пакета, программа трассировки пошлет пакет RST, чтобы закрыть соединение). Следовательно, программе трассировки становится известно, что цель достигнута. Обратите внимание на тот факт, что опция -n, которую я использовал в ранее показанной команде traceroute, не будет осуществлять разрешение имен DNS. В противном случае трассировка будет посылать запросы DNS для всех хопов, которые она встретит по пути.

Теперь главный вопрос в том, какую из трассировок я должен использовать: ICMP, UDP или TCP?

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

Практические занятия№ 03-006

Сетевая утилита tracert (traceroute в Linux, Cisco IOS, MAC OS). Принципы работы и использование.

Утилита tracert используется для исследования маршрутов IP пакетов в сетях, работающих с использованием стека протоколов TCP/IP включая глобальную сеть Internet. При использовании этой программы необходимо помнить что при её работе генерируется достаточно большое количество IP пакетов как на вашем хосте, так и на промежуточных маршрутизаторах. Это создает дополнительную нагрузку на сеть.

tracert [- d ] [- h максимальное число ] [- j список узлов ] [-w интервал ] [имя_конечного_компьютера ]

Параметры:

- d отказ от разрешения IP адресов промежуточных узлов в имена

- h максимальное число максимальное число переходов (прыжков) при поиске узла назначении

-j список_узлов задает использование параметра свободной маршрутизации в IP-заголовке с набором промежуточных точек назначения, указанным в списке_узлов (сейчас практически не поддерживается на машрутизаторах)

-w интервал задает в миллисекундах время ожидания каждого ответа

имя_конечного_компьютера задает точку назначения, идентифицированную IP-адресом или именем узла.

Работа утилиты основана на манипулировании содержимым полей стандартного заголовка и опций заголовка IP пакета. Основным инструментом утилиты является содержимое поля «время жизни» (или TTL).

Обязательным элементом является IP адрес или имя узла назначения.

Получив его от пользователя, утилита отправляет в сеть серию (обычно три) пакетов на этот адрес с установленным значением TTL равным 1. Шансов дойти до адресата эти пакеты не имеют, поскольку первый же по пути следования маршрутизатор, вычитая из такого TTL 1 получит 0. А такой пакет он обязан уничтожить по истечению разрешенного времени жизни в сети. Но при этом маршрутизатор обязан отправить отправителю этого пакета-неудачника ICMP сообщение о его трагической участи (тип 11, код 0) .

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

Затем отправляется следующая серия пакетов с TTL равным 2, и так до тех пор, пока пакеты не достигнут пункта назначения.

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

Чтобы узнать, что трассировка успешно завершена, все серии пакетов отправляются с вложенными в них UDP сообщениями, с указанием заведомо не существующего у получателя номера порта. На промежуточных маршрутизаторах это не имеет никакого значения, но получатель, потерпев неудачу воспользоваться вложенной информацией, оказывается вынужден сообщить об этом отправителю с использованием того же протокола ICMP, но с другими значениями типа (3) и кода (3) сообщения.

Такое сообщение интерпретируется отправителем как подтверждение завершения трвссировки.

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

Наименования узлов основывается на системе доменных имён (DNS):

Формально и пользователи, и программы могут обращаться к хостам, почтовым ящикам и другим ресурсам сети интернет по их IP адресам, но если для программы процедура «запоминания» IP адреса ничем не отличается от «запоминания» любых других 4-х байт информации любого типа, то для пользователя запоминание цифросочетаний вида 111.124.133.44 тяжело просто с точки зрения устройства нашей памяти. Кроме того, отождествление каких-либо служб с IP адресами хостов или серверов, на которых они функционируют крайне затрудняет процедуру их переноса в случае необходимости. Для учета «человеческого фактора» и отделения имен машин от их адресов было решено использовать текстовые ASCII-имена. Тем не менее, сеть понимает только численные адреса, поэтому нужен механизм преобразования ASCII-строк в IP адреса.

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

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

Для решения этих проблем была разработана служба имен доменов (DNS, Domain Name System). Эта система используется для преобразования имен хостов и пунктов назначения электронной почты в IP-адреса, но также может использоваться и в других целях. Определение системы DNS было дано в RFC 1034 и 1035.

Доменным именем называется имя, состоящее из слов, разделенных точками. Левое слово имени относится к хосту. Все остальные слова образуют имя домена. Система имен имеет иерархическую, древовидную структуру.

Каждый узел (кружочки на рисунке) имеет метку длиной до 63 символов. Корень дерева это специальный узел без метки. Метки могут содержать заглавные буквы или маленькие. Имя домена (domain name) для любого узла в дереве - это последовательность меток, которая начинается с узла выступающего в роли корня, при этом метки разделяются точками. (Здесь видно отличие от привычной нам файловой системы, где полный путь всегда начинается с вершины (корня) и опускается вниз по дереву.) Каждый узел дерева должен иметь уникальное имя домена, однако одинаковые метки могут быть использованы в различных точках дерева.

Существует корневое имя, обозначаемое символом ".", оно часто не пишется в имени домена. Существуют имена доменов первого уровня. Они разделены на 2 категории - имена доменов территорий и имена доменов предметных областей. Имена доменов второго уровня и последующих могут быть любыми, при этом не может существовать двух одинаковых имен доменов или хостов. Итак, если N i - доменное имя i-го уровня, а T- слово, то доменное имя i+1 уровня образуется по правилу N i +1 =T+N i .. Имя домена, которое заканчивается точкой, называется абсолютным именем домена (absolute domain name) или полным именем домена (FQDN - fully qualified domain name).

Подчеркнем ещё раз, что поскольку IP-адреса уникально идентифицируют хосты в сети, существует взаимно-однозначное отношение между множеством имен хостов и множеством адресов.

Это отношение устанавливается таблицей, в которой столько записей типа «Имя хоста, IP-адрес», сколько существует доменных имен хостов. При наименовании нового хоста запись в таблицу нужно добавить, если переименован существующий, запись нужно изменить. Пользоваться такой системой имен удобно, потому что они легко запоминаются и не привязаны к территориально локализованным IP-сетям. Перенося поименованный ресурс с одного хоста на другой, вам достаточно изменить запись для его имени в таблице имен. На одном сайте сложно содержать такую таблицу для Интернет и невозможно поддерживать в актуальном состоянии.

База данных DNS является распределенной. Иерархической системе имен соответствует иерархическая система серверов DNS, на которых размещены фрагменты таблицы. В идеале для каждого домена должен существовать отдельный сервер имен. В базе данных сервера имен любого уровня должны содержаться записи о всех дочерних доменах следующего уровня. Все домены первого уровня содержаться в базе данных корневых серверов (root name servers). Их обслуживает организация NIC.

В реальности на одном хосте может размещаться база для нескольких доменов, и одинаковые или пересекающиеся базы могут располагаться на нескольких хостах. Ветвь дерева имен, находящаяся под единым управлением вместе с хостами, на которых расположена база данных этой ветви дерева называется зоной DNS. Обычно в зоне имеется один основной сервер DNS (primary name server) и несколько резервных (secondary name servers). Изменения в зоне вносятся в базу данных первичного сервера зоны с последующим дублированием этой информации на вторичные сервера.

Процесс передачи информации от первичного сервера вторичному называется передачей зоны (zone transfer). Когда в зоне появляется новый хост, администратор добавляет соответствующую информацию (минимум, имя и IP адрес) в дисковый файл на первичном сервере. Вторичные сервера регулярно опрашивают первичные (обычно каждые 3 часа), и если первичные содержат новую информацию, вторичный получает ее с использованием передачи зоны.

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

Система разрешения адресов.

Для того, чтобы программное обеспечение стека протоколов TCP/IP могло пользоваться службой имен, в настройках стека должен быть указан IP - адрес сервера имен, в зону которого входит хост или другой сервер, принимающий запросы из сети хоста. Когда прикладной элемент использует для обозначения второй стороны в сеансе доменное имя, инициируется процесс разрешения IP - адреса. Прикладной элемент службы имен хоста отправляет запрос серверу имен. Если сервер имен может разрешить адрес, он отправляет отклик, содержащий этот адрес. Если сервер имен не может разрешить запрос, он может инициировать два сценария разрешения имени

сервер отправляет в составе отклика адрес корневого сервера имен, и хост формирует запрос к этому серверу (итеративный запрос).

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

Отклик сервера, контролирующего домен, называется авторитетным.

Каждый сервер имен в Интернет должен содержать в базе адреса корневых серверов.

Разрешение имен . Кроме основной своей функции разрешения доменного имени хоста в его IP-адрес, протокол DNS обеспечивает и обратное разрешение IP-адреса в доменное имя при помощи подзон реверсивной зоны in_addr.arpa.

Именно возможности этого протокола позволяют утилите tracert не только успешно работать при задании места трассировки в виде DNS имени, но и предоставлять нам информацию о именах промежуточных узлов.

Вопросы для самопроверки

Что такое система доменных имен и для чего он используется.

Каков максимальный размер метки узла домена

Какое имя имеет корневой домен DNS

Какие типы и коды ICMP сообщений использует утилита tracert

Какое поле заголовка IP пакета используется для задания времени жизни пакетов утилитой tracert

Параметры утилиты tracert

Назначение утилиты tracert и варианты её применения

Необходимое оборудование

IBM PC - совместимая ЭВМ с лицензионной операционной системой Windows, подключение к локальной сети, выход в интернет.

Задания

1. Воспользовавшись командой tracert рпределите маршрут распространения IP-пакетов до сайта www.sgu.ru

2. Воспользовавшись командой tracert рпределите маршрут распространения IP-пакетов до одного из приведенных сайтов: www . nla . gov . au , www . ibge . gov . br , www . kunaicho . go . jp (можете выбрать любой сайт за пределами России).

3. Повторите трассировку с опцией –d.

4. Опишите структуру DNS имени трассировавшегося вами сервера.

5. Воспользуйтесь услугами сервиса www . ip 2 location . com / demo . aspx (или аналогичного) и определите примерное местоположение промежуточных точек маршрута.

6. Нарисуйте схему маршрута.

7. Прокомментируйте результаты.

Отчет о выполнении работы представьте в печатной или электронной форме с представлением копий экранов работы утилиты.

Бывают в сетевой жизни (особенно у 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:).

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