23.06.2025

Traceroute — трассировка сети в Linux

Представим ситуацию: установлено и настроено нужное ПО для работы, которое взаимодействует с другими серверами в сети (любое web-приложение, использующее БД на удаленном сервере, резервное копирование по сети и др.). До какого-то момента все работает корректно и без задержек, но внезапно либо ПО начинает работать заметно медленнее, либо перестает работать полностью. Как понять на каком сервере возникла проблема? На каком этапе передачи трафика возникает задержка или ограничение? Каким образом провести диагностику сетевого подключения?

Установка traceroute

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

Утилита часто уже предустановлена в ОС, и сразу доступна для использования. Если все же она отсутствует, то установить ее можно из стандартного репозитория дистрибутива с помощью менеджера пакетов:

sudo apt install traceroute
sudo yum install traceroute

Как работает traceroute

Утилита отслеживает, на какие узлы попадает сетевой пакет в процессе его передачи на целевой хост. По умолчанию используется UDP протокол – формируется UDP датаграмма, которая упаковывается в IP пакет. В одном из заголовков этого пакета утилита устанавливает значение параметра TTL (Time To Live) равным 1. Этот параметр используется для ограничения количества переходов от одного маршрутизатора к другому, т.е. позволяет избежать бесконечной передачи пакета между маршрутизаторами (например, в случае некорректно настроенного протокола динамической маршрутизации, или при ошибках в статических маршрутах). Каждый маршрутизатор, получив пакет, уменьшает значение TTL на 1 перед отправкой далее в сеть. В ситуации, когда после очередного уменьшения TTL становится равным 0 пакет считается недоставленным и отбрасывается, при этом маршрутизатор отвечает отправителю сообщением об ошибке.

При TTL = 1 traceroute, получая ответ от первого маршрутизатора, определяет его IP адрес и время, затраченное на обработку пакета. После этого TTL увеличивается на единицу для определения следующего маршрутизатора, и так далее до момента попадания пакета на целевой хост. Утилита использует указанный ей IP-адрес, и порт 34434 по умолчанию. Целевой хост принимает пакет, и отправляет сообщение о недоступности порта 34434 (так как в большинстве случаев он не используется каким-либо сервисом и закрыт). В итоге отслеживается вся цепочка следования пакета, которая завершается ответом от целевого хоста.

Маршрутизатором является любое устройство, передающее пакет из одной подсети в другую — это может быть какой-либо сервер, а не специализированное сетевое устройство. Это особенно актуально для микросервисной архитектуры приложений, использующей технологии контейнеризации. Анализируя время, затраченное на переход от одного маршрутизатора к другому, можно определить на каком из них возникает задержка – возможно из-за нехватки ресурсов на одном из серверов, или из-за неисправности дисковой системы, и др. Если один из серверов недоступен, то пакет не дойдет до целевого хоста, и утилита определит на каком этапе передачи это происходит. Также, пакет не дойдет если действует фильтрация трафика, мешающая передачи пакета.

Запуск traceroute

Обязательным для утилиты является имя целевого хоста или IP адрес:

traceroute linux.org

Вывод команды:

Какие данные получены этой командой и отображены в выводе в виде таблицы:

По умолчанию traceroute отправляет три UDP пакета, поэтому в выводе отображены три значения RTT. Для первой строки это 3.034 ms, 5.349 ms, 5.325 ms. Другим значением по умолчанию является количество хопов, которые может пройти пакет, т.е. TTL = 30. Произвольное значение, например 35, можно указать в строке запуска с опцией « -m 35 ».
На некоторых хопах может быть определено более одного маршрутизатора – это происходит из-за наличия нескольких маршрутов на этом этапе. Отправляя сразу три UDP пакета ответ может приходить от трех разных маршрутизаторов, и для каждого также указано RTT. Пример такого ответа на четвертом хопе: определены IP 172.71.180.2 и 172.71.100.2, через которые возможна доставка пакетов на целевой хост.

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

Стоит отметить, что ответ может приходить отправителю альтернативным маршрутом, либо использования технологий балансировки нагрузки. Если на каком-то хопе имеется высокий RTT, то стоит запустить утилиту еще раз и проверить результат. Также, на одном из маршрутизаторов могут быть в действии фильтры пакетов, либо это может быть специализированный Firewall. В таком случае возможны ограничения для порта или UDP протокола, и в выводе traceroute будут отображены три звездочки (т.е. превышен таймаут получения ответа):

traceroute mongodb.org

Ресурс mongodb.com доступен, но UDP пакеты фильтруются.

Traceroute может использовать ICMP протокол вместо UDP – отправляется один запрос «Echo Request», в ответ также приходят ICMP сообщения, порт не используется. В остальном – схема работы не отличается. Опция « -I » в строке запуска для ICMP трассировки:

traceroute mongodb.org -I

Видно, что ответ получен от целевого хоста, хотя с 5 по 21 хопы ответы не приходят.

TCP протокол также может быть использован (опция « -T ») – в этом случае отправляются SYN запросы на 80 порт.

Полезные опции traceroute

Трассировка в ОС Windows

Утилита tracert доступна в ОС Windows для трассировки сети аналогично traceroute в ОС Linux. Эта утилита использует только ICMP протокол, имеет меньшее количество опций, в остальном процесс не отличается от traceroute.

Заключение

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