благодаря какому полю в хедере ip пакета работает traceroute
Как работает tracert и traceroute
Применение данных утил позволяет проследить маршрут до удаленного хоста, определить время круговой задержки (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. Этот пакет уже доходит до второго маршрутизатора, но опять там «умирает» о чем аналогичным, же образом сообщается узлу отправителю. И так до тех пор, пока не достигнет конечного узла. На основании данных ответов строится трассировка. Например:
Из данной трассы мы видим, что хост www.rt.ru доступен с числом прыжков(хопов) — 8, его ip 109.207.14.4, и время круговой задержки до данного ресурса составляет 19ms.
Как работает Traсeroute.
Принцип идентичный, за одним исключением. Утила по умолчанию, посылает в сторону заданного хоста UDP-датаграммы на какой-то произвольный порт, обычно — на «высокий», скорее всего не занятый другим сервисом (например 12500, 30678) или на зарезервированный (например 0), в свежих версиях порт по умолчанию — 33434. Сначала посылается серия из 3-х таких пакетов с TTL=1, по приходу ответов замеряется время прохождения и определяется доменное имя транзитного узла. Затем, как сказано выше, посылаются очередные серии пакетов с TTL=2 и т.д. В конце мы получаем от конечного хоста отклик «Порт недоступен» (PORT_UNREACHABLE), что означает завершение трассировки.
Пример трассировки до того же ресурса:
Заключение.
Следует отметить, что звездочки могут возникать и при трассировке ICMP-пакетами, это также не значит, что существует проблема. Все зависит от того, как настроил оборудование администратор. Это его железо и настраивается оно с его потребностями. Данное явление вполне нормально. Также не следует паниковать, если конечный хост не пингуется. Вполне возможно, что ресурс просто от них закрылся.
Tracert vs Traceroute
В чем отличие маршрута пакета от его пути?
Стандартный механизм маршрутизации пакетов в интернете — per hop behavior — то есть каждый узел в сети принимает решение куда ему отправить пакет на основе информации, полученной от протоколов динамической маршрутизации и статически указанных администраторами маршрутов.
Маршрут — это интерфейс, в который нам надо послать пакет для достижения какого то узла назначения и адрес следующего маршрутизатора (next-hop):
Что такое путь? Путь — это список узлов, через которые прошел (пройдет) пакет:
Путь пакета можно посмотреть с помощью утилит tracert в OC Windows и traceroute в GNU/Linux и Unix-подобных системах. (другие команды, типа tracepath мы не рассматриваем).
Многие считают что этих утилит один и тот же принцип работы, но это не так. Давайте разберемся.
Итак, утилита tracert.
В основе работы данной утилиты лежит протокол icmp. Рассмотрим вот такую схему: 
Host отправляет по указанному в его таблице маршрутизации маршруту ICMP Echo-Request с ttl 1. Router1, получив такой пакет, проверит адрес назначения — может быть пакет ему. Так как данный пакет адресован другому хосту, то Router1 считает себя транзитным узлом, декрементирует ttl пакета и отбрасывает его, так как время жизни пакета становится равным 0. Так как пакет был дропнут, Router1 отправляет источнику пакета icmp сообщение с указанием причины дропа — Time Exceeded. Утилита tracert, получив данное icmp сообщение, указывает Router1 как первый хоп (информация об адресе указана в icmp сообщении). Далее процесс повторяется с инкрементированием ttl, пока ttl icmp запроса не будет равен количеству хопов между узлом-отправителем и узлом получателем. В данном примере Server1 является узлом назначения. Получив пакет, он проверит адрес назначения, увидит, что запрос адресован ему и отправит ICMP Echo-Reply, что и будет являться для утилиты tracert триггером к окончанию трассировки.
Traceroute — данная утилита работает по иному принципу, хоть и вывод команды похож на вывод предыдущей.
Traceroute основана не на ICMP Echo-Request, а на отправке udp фрагментов и получения сообщения о доступности/недостижимости порта. Вернемся к прошлой схеме. Host генерирует udp фрагмент, инкапсулирует его в IP пакет и выставляет ttl=1. Router1, являясь транзитным узлом, ответит на данный пакет icmp сообщением об окончании времени жизни пакета. Утилита traceroute, получив данное сообщение, указывает адрес источника icmp пакета (Router1) как адрес первого хопа. Далее процесс повторяется с инкрементированием ttl пакета. Всё практически так же, как и в tracert. Но ведь мы не отправляем ICMP Echo-Request, как утилита traceroute поймет, что трассировка закончена? Все просто — в udp заголовке есть поля source и destination порт. Логично, что source порт будет любым портом выше 1023. А каким указать destination порт? Как было сказано выше, работа утилиты traceroute основана на получении сообщения о недостижимости или доступности порта назначения. То есть мы отправляем udp фрагмент с порта 45000 ( к примеру) на порт 33434 (именно этот порт используется по умолчанию). Как и в предыдущем случае, Server1 является узлом назначения. Получив пакет, он распаковывает его и должен передать его протоколам высшего уровня. Но так как порт 33434 по умолочанию будет закрыт на сервере, то Server1 формирует icmp сообщение о недостижимости порта назначения (ICMP Type 3 «Destination Unreachable» Code 3 «Port Unreachable»). Получив данное сообщение, утилита traceroute считает трассировку законченной. В процессе трассировки номер порта назначения будет инкрементироваться при каждой попытке ( 33434, 33435 и т д). Может получится так, что порт назначения будет открыт. В данном случае сервер отправит на хост-инициатор например TCP ACK если для трассировки используются TCP SYN пакеты, что тоже будет являться триггером к окончанию трассировки.
Вывод:
Утилита traceroute позволяет сделать трассировку с указанием порта назначения.
Для этого разберем пример ниже:
Возьмем предыдущую схему и сделаем трассировку:
С использованием TCP SYN пакетов:
C использованием UDP пакетов:
Как видите трассировка прошла успешно. Мы видим путь до указанного хоста.
А теперь повесим на интерфейс Router4 фильтр на in (как указано на рисунке): 
Снова сделаем трассировку:
Примечание: Возможен случай, когда пакеты будут дропаться без отправки ICMP сообщений ( отправка в Null-интерфейс в Cisco/Huawei или discard в Juniper). В данном случае трассировка будет идти пока не кончится максимальное TTL, указанное в утилите traceroute (по умолчанию максимум 30 хопов, но можно задать вручную до 255, правда обычно достаточно 15-18 хопов) или ее не прервет администратор, а в выводе будут звездочки.
Примечание: Появление звездочек вместо адресов хостов может быть обусловлено различными причинами и хорошо описано тут
Надеюсь мы разобрались в основных принципах работы данных утилит. Если надо сделать трассировку по какому то порту в Windows системах, можно использовать сторонние утилиты, к примеру tcptrace.
Traceroute, как использовать в Linux
Команда traceroute используется в Linux для отображения пути прохождения пакета информации от его источника к месту назначения. Одним из способов использования traceroute является обнаружение случаев потери данных по всей сети, что может указывать на то, что узел не работает.
Поскольку каждый переход в записи отражает новый сервер или маршрутизатор между исходным ПК и предполагаемой целью, анализ результатов сканирования трассировки также позволяет выявлять медленные точки, которые могут отрицательно повлиять на сетевой трафик.
Синтаксис traceroute и другая информация, описанная ниже, применима только к машинам Linux.
Как работает Traceroute
Оценка конкретного маршрута, по которому следует сетевой трафик (или нахождение неверного шлюза, отбрасывающего ваши пакеты), представляет несколько проблем с устранением неполадок. Traceroute использует поле протокола IP, времени жизни для запроса ответа ICMP TIME_EXCEEDED от каждого шлюза по пути к хосту назначения.
Единственный параметр, который необходимо указать при выполнении команды traceroute, — это имя хоста или IP-адрес места назначения.
Синтаксис traceroute и ключи
traceroute [ -dFInrvx ] [ -f first_ttl ] [ -g gateway ] [ -i iface ] [ -m max_ttl ] [ -p port ] [ -q nqueries ] [ -s src_addr ] [ -t tos ] [ -w waittime ] [ -z pausemsecs ] host [ packetlen ]
Хотя вышеизложенное показывает, как команда traceroute должна быть записана для работы в командной строке, производительность или выходные данные команды можно изменить, указав один или несколько необязательных ключей.
Интерпретация результатов
Когда traceroute выполняется, он отправляет три сигнала с каждой настройкой TTL, а затем выводит на консоль строку, показывающую TTL, адрес шлюза и время прохождения сигнала в обоих направлениях. Если ответы зондирования поступают из разных шлюзов, печатается адрес каждой отвечающей системы. Если в течение пятисекундного интервала ожидания ответа нет (изменяется с помощью ключа -w ), для этого сигнала печатается звездочка.
Пример использования и вывода результатов:
Traceroute предназначен для использования в тестировании, измерении и управлении сетью. Его следует использовать главным образом для ручной локализации неисправностей. Из-за нагрузки, которая может быть наложена на сеть, неразумно использовать traceroute во время обычных операций или из автоматических сценариев.
Благодаря какому полю в хедере ip пакета работает traceroute
Войти
Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal
Как работает traceroute
Если вы работаете сетевым администратором, системным администратором или в какой-либо эксплуатационной группе, вы, возможно, слышали об инструменте с названием TRACEROUTE. Это очень удобный инструнт, доступный по умолчанию во многих операционных системах.
Сетевые и системные администраторы используют этот инструмент в ежедневной работе. Это, в сущности, удобное средство диагностики сети. Существуют три основных задачи инструмента traceroute. Эти задачи, выполняемые traceroute’ом, дают понимание ошибки вашей сети.
Это инструмент, который используется, чтобы проверить путь, который проходят ваши данные, чтобы достичь цели, без действительной отправки данных
В этой статье я объясню работу Traceroute и типы инструментов Traceroute и их различия. Мы также рассмотрим разные параметры, доступные для команды traceroute в Linux
Сначала основное
Каждый пакет, который вы отправляете в интернет, имеет поле, названное TTL. TTL означает время жизни (time to live). Хотя оно и называется временем жизни, в действительности это не время в секундах, а совсем другая история.
TTL не изменяется ни количеством секунд, ни количеством хопов. Это максимальное количество хопов, которое пакет может пройти по сети до того, как будет уничтожен.
Что бы произошло, если бы вообще не было TTL? Если бы не было TTL, IP-пакет перетекал бы бесконечно от одного маршрутизатора к другому и дальше, и дальше, бесконечно ища назначение. Значение TTL устанавливается отправителем внутри IP-пакета (человек, использующий систему или отправляющий пакет, не замечает этих вещей, происходящих “за кулисами”, но это автоматически обрабатывается операционной системой)
Если назначение не найдено после прохождения слишком большого количества промежуточных маршрутизаторов (хопов), и значение TTL становится равным нулю (что означает, что нет дальнейшего прохождения) получающий маршрутизатор уничтожает пакет и информирует первоначального отправителя.
Первоначального отправителя информируют, что TTL истекло, и он не может передать пакет дальше.
Но как маршрутизаторы по пути определяют, что достигнут лимит 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” чтобы узнать, какие маршрутизаторы/хопы между ними?
Но вы можете использовать поведение сообщений TTL exceeded маршрутизаторов/хопов по пути, целенаправленно отправляя пакеты с 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 показывает эти три значения. Давайте рассмотрим поближе вывод 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, то вы можете использовать другую трассировку для этой цели. Различные типы приведены ниже.
ICMP для traceroute работает точно так же, как UDP traceroute. Программа traceroute будет отправлять ICMP Echo-запросы и хопы между ними будут отвечать ICMP-сообщениями «ICMP Time exceeded» (время истекло). Но конечный пункт назначения будет отправлять ICMP echo-ответ. Команда tracert, доступная в операционной системе Windows, по умолчанию использует ICMP метод трассировки маршрута.
И последний является самым интересным. Его называют TCPtraceroute. Он используется, потому что почти все файрволлы и промежуточные маршрутизаторы позволяют передавать TCP трафик. И если пакет на порт 80, который является веб-трафиком, то большинство маршрутизаторов пропускают этот пакет. TCPTRACEROUTE по умолчанию отправляет TCP SYN запросы на порт 80.
Теперь главный вопрос в том, какую из трассировок я должен использовать: ICMP, UDP или TCP?
Всё зависит от окружения. Если предположить, что промежуточные маршрутизаторы блокируют конкретный протокол, вы должны попробовать использовать другой.
IT-блог о веб-технологиях, серверах, протоколах, базах данных, СУБД, SQL, компьютерных сетях, языках программирования и создание сайтов.
Команда tracert в Windows. Зачем нужна и как пользоваться сетевой утилитой tracert?
Привет, посетитель сайта ZametkiNaPolyah.ru! Продолжим разбираться с полезными командами и утилитами командной строки Windows, на этот раз давайте разберемся с сетевой утилитой tracert, мы поговорим зачем нужна команда tracert и как ею пользоваться для диагностики компьютерной сети и устранению неполадок. Как мы увидим, утилиту tracert используют сетевые инженеры и системные администраторы для определения маршрута прохождения IP-пакета по сети, вы убедитесь, что этой утилитой довольно легко пользоваться, но не все умеют правильно оценивать результаты работы этой команды, о некоторых сложностях, которые могут возникнуть при интерпретации трассировка маршрута мы поговорим в самом конце этой публикации.
Если вам интересна тема компьютерных сетей, то в блоге уже практически закончена первая часть курса по основам компьютерных сетей, можете ознакомиться с ее содержимым. И вот здесь можно получить немного информации о самом курсе основанном на Cisco ICND1.
Назначение команды tracert или как определить маршрут прохождения пакета до узла
Tracert – это небольшая системная утилита вашей операционной системы, которая позволяет сделать трассировку маршрута до заданного узла в локальной сети или сети Интернет. В операционных системах Windows tracert – это стандартная утилита, которая устанавливается вместе с операционной системой, то есть вам не нужно ничего устанавливать, чтобы воспользоваться командной tracert. Исполняемый файл tracert.exe в Windows 10 находится по следующему пути: C:\Windows\System32.
Команда tracert – это один из самых часто используемых инструментов для траблшутинга и сетевой диагностики, эта утилита дает нам возможность определить маршрут, по которому проходит пакет до заданного узла. Tracert может работать как с доменными имена или именами хостов, так и с IP-адресами (как с IPv4, так и с IPv6). Кроме того что tracert показывает маршрут от вашего компьютера до удаленного узла в сети, она еще и отображает время прохождения пакетов как до конечного узла, так и до транзитных или промежуточных узлов (время является одной из самых важных единиц измерения в компьютерных сетях). Давайте лучше посмотрим, как работает утилита tracert на простом примере без дополнительных параметров.
Трассировка маршрута при помощи команды Tracert до IP-адреса Яндекс
В данном случаем мы видим путь прохождения IP-пакета от моего ПК до сервера Яндекс, чтобы указать утилите tracert удаленный узел, мы воспользовались IP-адресом. Но эта команда может работать и с доменными именами, давайте посмотрим, сделав трассировку маршрута до сервера Google.
Трассировка маршрута при помощи утилиты tracert до сервера Google по доменному имени
Стоит сказать пару слов о выводе, который мы получили. Каждая строка вывода команды tracert пронумерована, каждая такая строка называется шагом, хопом или прыжком. По умолчанию tracert в Windows отправляет три запроса на каждый хоп и получает от этого хопа ответы, если ответ не получен, то в первых трех столбцах мы видим символ «*», если ответ получен, то в первых трех столбцах указывается время прохождения пакета, а в четвертом столбце Windows дает нам подсказку о причинах, по которым удаленный узел нам не ответил или его адрес, если узел ответил.
Хопы, которые мы видим в трассировке – это маршрутизаторы, серверы или L3 коммутаторы, на интерфейсах которых прописан IP-адрес (то есть устройства, которые определяют путь, по которому пойдет IP-пакет, другими словами – это устройства сетевого уровня моделей OSI 7 и TCP/IP), это важное уточнение для интернет-пользователей, всё дело в том, что витая пара или другой тип кабеля (про минусы использования коаксиального кабеля в Ethernet сетях можете почитать здесь), который приходит к вам в квартиру, подключен в L2 коммутатор, который никак не влияет на маршрут прохождения пакета, на нем нет IP-адресов (вернее есть один адрес, который использует тех. поддержка провайдера для управления этим коммутатором) и он не принимает решений по маршрутизации пакетов, таких коммутаторов между хопами может быть несколько десятков и мы их никак не увидим, так как для утилиты tracert они представляют собой что-то вроде кабеля, собственно как и для других утилит сетевой диагностики.
Для диагностики сетевых ресурсов утилита tracert использует специальный протокол, который называется ICMP (Internet Control Message Protocol — протокол межсетевых управляющих сообщений), есть еще команда traceroute (эта утилита обычно входит в стандартные дистрибутивы Linux, например, эта утилита присутствует в Linux Mint), которая по умолчанию использует протокол UDP, для ее использвания вам точно также потребуется эмулятор терминала. ICMP-сообщение, которое посылает наш компьютер, запаковывается в IP-пакет (здесь вы можете прочитать более подробно про инкапсуляцию данных в компьютерных сетях), у которого есть специальное значение TTL (time to live или время жизни), для понимания работы tracert это важно, поскольку эта команда при каждой отправке пакета увеличивает TTL на единицу, а первый отправленный пакет в сеть имеет значение, равное единице, при этом по умолчанию tracert отправляет три пакета с одним и тем же TTL, то есть в ответ мы должны получить три пакета от удаленного узла (самые основы взаимодействия двух узлов в компьютерной сети описаны здесь, для реализации схемы использовалась Cisco Packet Tracer).
Вернемся к примеру с трассировкой Яндекса, чтобы это лучше понять. Когда мы написали tracert 77.88.55.88, tracert сформировала IP-пакет, в котором в качестве узла назначения указала IP-адрес Яндекса и отправила его в сеть, а в качестве TTL этот пакет получил значение равное единице, далее tracert, не изменяя TTL отправила еще два пакета и получила три ответа от узла 192.168.0.1. После значение TTL было увеличено на единицу (значение стало равным двойке) и в сеть было отправлено еще три пакета (IP-адрес в этих пакетах не изменялся), следующий хоп отказался отвечать на ICMP-запросы и мы увидели три звездочки, после этого TTL был снова увеличен и мы увидели третий хоп, таким образом tracert будет увеличивать TTL до тех пор, пока не доберется до сервера Яндекс. С Гуглом ситуация аналогичная, только там мы использовали доменное имя, поэтому tracert пришлось выполнять дополнительные операции по выяснению IP-адреса, на котором этот домен висит.
При использовании утилиты tracert не стоит паниковать в тех ситуациях, когда вы видите звездочки вместо времени ответа удаленного узла, дело в том, что ICMP-протокол иногда используется для сетевых атак (например, DDoS) и некоторые сетевые инженеры и системные администраторы предпочитают настраивать свои устройства таким образом, чтобы они не отвечали на ICMP-запросы. Иногда бывает так, что конечный узел не отвечает на ICMP-запросы, но на самом деле он корректно работает и выполняет свои функции, для проверки доступности таких узлов вам не поможет команда Ping, так как она тоже использует ICMP, но может помочь команда traceroute или онлайн сервисы по проверки доступно сайтов и серверов в Интернете.
В качестве примера давайте сделаем трассировку до сайта microsoft.com, сервера этой компании не отвечают на ICMP-запросы. Трассировка показана на рисунке ниже.
Трассировка до сервера Microsoft, который не отвечает на ICMP-запросы
На момент проверки этого ресурса он был доступен, но результаты работы tracert нас немного обманывают, по ним видно, что мы якобы не можем добраться до сервера Майкрософт, поэтому для корректной диагностики удаленных ресурсов нужно иметь целый арсенал сетевых утилит, ну или как минимум браузер и умение гуглить. Еще по трассировки видно, что tracert в Windows по умолчанию использует максимальное значение TTL равное 30, протокол IPv4 позволяет задавать максимальное значение TTL 255, но на самом деле это очень много, чтобы остановить выполнение команды tracert воспользуйтесь сочетание клавиш ctrl+c.
Параметры команды tracert в Windows
Любая команда в командной строке Windows имеет небольшой справочник (команда help — справочник командной строки Windows), в котором указаны допустимые параметры, в том числе и команда tracert, чтобы увидеть эти параметры, в командной строке нужно написать: tracert /? или tracert /h.