Трассировка маршрута сети с помощью traceroute и mtr — практическое руководство

Если ты когда-нибудь сталкивался с тем, что сервер «лагает», сайт не открывается или пинг до нужного ресурса скачет как бешеный — скорее всего, ты уже слышал про traceroute и mtr. Эти инструменты — настоящие швейцарские ножи для диагностики сетевых маршрутов. Сегодня разберёмся, что это такое, как работает, зачем нужно, как быстро всё настроить и что делать, если трассировка показывает странные или пугающие результаты. А ещё — как это может помочь тебе автоматизировать мониторинг и решить проблемы с сетью до того, как клиенты начнут бомбить саппорт.

О чём эта статья и зачем она нужна?

Пост написан для тех, кто хоть раз арендовал VPS, выделенный сервер или настраивал облачный хостинг, и хочет быстро понять — где именно в интернете теряются пакеты, почему соединение притормаживает и как это чинить. Трассировка маршрута нужна не только для поиска «узких мест» — это ещё и способ показать хостеру или провайдеру, что проблема не у тебя, а где-то в их магистральных сетях.

Почему это важно?

• Экономия времени на диагностику проблем с сетью.
• Возможность доказать провайдеру, что проблема не на твоём сервере.
• Быстрая локализация «бутылочных горлышек» и DDoS-атак.
• Автоматизация мониторинга и алерты по нестабильным маршрутам.

Проблема: сеть тормозит, но где именно?

Представь: ты арендовал сервер, развернул сайт, всё летает. Через пару недель пользователи жалуются на задержки. Пингуешь сервер — вроде нормально. Но сайт всё равно «тормозит». Классика жанра — проблема где-то между тобой и сервером, но где именно? Провайдеры кивают друг на друга, саппорт хостинга просит «трассировку». Вот тут и приходят на помощь traceroute и mtr — они показывают, по каким маршрутам идут пакеты, и где именно начинаются потери или задержки.

Как это работает? Алгоритмы и структура

Итак, начнём с матчасти. traceroute и mtr используют хитрость: они отправляют пакеты с постепенно увеличивающимся временем жизни (TTL — Time To Live). Каждый роутер по пути уменьшает TTL на 1. Когда TTL становится равен 0, роутер отбрасывает пакет и отправляет ICMP-ответ — мол, «я тут, пакет умер». Так, отправляя пачку пакетов с TTL=1,2,3 и т.д., мы получаем список всех промежуточных узлов между тобой и целью (например, сервером).

• traceroute — классика, работает почти везде, но просто показывает список хопов и задержки.
• mtr — комбо traceroute и ping, показывает маршруты и статистику потерь/задержек в реальном времени.

Оба инструмента используют либо ICMP (ping-подобные пакеты), либо UDP/TCP (зависит от опций и ОС).

Схема работы:

1. Отправляем пакет с TTL=1 — получаем ответ от первого роутера.
2. TTL=2 — ответ от второго, и так далее, пока не дойдём до цели или не упрёмся в «чёрную дыру».
3. Фиксируем задержку (RTT) и потери пакетов на каждом хопе.

Как быстро и просто всё настроить?

Погнали по шагам — всё максимально просто, без лишней теории. Предполагается, что у тебя есть доступ к серверу по SSH (или локальный терминал), права root или sudo.

Установка traceroute и mtr

• На Debian/Ubuntu:


sudo apt update
sudo apt install traceroute mtr -y


• На CentOS/RHEL:


sudo yum install traceroute mtr -y


• На AlmaLinux/RockyLinux:


sudo dnf install traceroute mtr -y


• На MacOS (через Homebrew):


brew install mtr


Базовое использование traceroute


traceroute ya.ru


или для TCP (например, если ICMP заблокирован):


traceroute -T ya.ru


Базовое использование mtr


mtr ya.ru


Для запуска в режиме отчёта (например, для отправки саппорту):


mtr -r -c 100 ya.ru


• -r — режим отчёта (report mode)
• -c 100 — 100 пакетов на каждый хоп

Примеры, кейсы и сравнение

Сравним оба инструмента и разберём типовые ситуации.

Положительный кейс:

Симптом: Сайт на сервере в Германии стал медленно открываться из России.

Действие: Запускаем mtr -r -c 100 yourdomain.com с домашнего ПК и с сервера.

Результат: Видим, что на одном из промежуточных хопов в Европе появляется задержка 300+ мс и потери 10%. Сохраняем отчёт, отправляем провайдеру — они подтверждают, что у магистрального оператора авария, и обещают починить.

Отрицательный кейс:

Симптом: Потери на первом хопе (192.168.1.1) — 50%.

Объяснение: Это твой локальный роутер. Часто он ограничивает ICMP-ответы, чтобы не нагружать процессор. Если дальше по маршруту всё ок — не парься, это не твоя проблема.

Ещё один кейс:

Симптом: Начиная с определённого хопа, все адреса показывают звёздочки (* * *).

Объяснение: На этом участке ICMP/UDP пакеты блокируются фаерволом. Если до цели доходит — всё ок, иначе ищи проблему на этом участке.

Ошибки новичков и мифы

• Потери на первом хопе — это плохо? Нет, если дальше всё ок. Роутеры часто игнорируют часть ICMP.
• Звёздочки — всегда критично? Нет, это может быть просто фильтрация пакетов.
• Потери на последнем хопе — всегда проблема сервера? Не обязательно. Иногда сервер ограничивает ответы на ICMP, чтобы не стать жертвой DDoS.
• traceroute и mtr показывают реальный путь для всех протоколов? Не всегда. Маршруты для ICMP и TCP/UDP могут отличаться (особенно при балансировке нагрузки).

Похожие утилиты и альтернативы

• tcping — трассировка и пинг по TCP-портам (актуально, если ICMP заблокирован)
• masscan — не для трассировки, но полезно для сканирования маршрутов
• nmap — может делать traceroute в составе сканирования

Статистика и сравнение с другими решениями

В 99% случаев достаточно mtr или traceroute. Для сложных сетей (например, с MPLS, GRE-туннелями, балансировкой L3/L4) — могут понадобиться специализированные трассировщики (например, scamper или tracepath).

Сравнение по скорости и информативности:

Интересные факты и лайфхаки

• Можно запускать mtr в режиме TCP, чтобы обойти блокировку ICMP:


sudo mtr --tcp ya.ru


• Если нужно трассировать маршрут до определённого порта (например, 443):


sudo mtr --tcp -P 443 ya.ru


• У mtr есть web-интерфейсы, например, mtr-web — удобно для быстрой диагностики с браузера.
• Можно автоматизировать трассировки с помощью cron и отправлять отчёты на почту — пригодится для мониторинга нестабильных каналов.
• Многие хостинги предоставляют Looking Glass — публичный mtr/traceroute из своей сети (ищи на сайте провайдера).

Автоматизация и новые возможности

Трассировка маршрута — это не только ручная диагностика. Вот несколько идей для автоматизации:

• Писать скрипты, которые раз в час прогоняют mtr до важных узлов и сравнивают результаты с эталонными. Если потери или задержка — присылать алерт в Telegram/Slack.
• Интегрировать mtr в систему мониторинга (например, Zabbix, Nagios, Prometheus) через внешние скрипты.
• Использовать результаты трассировки для динамического выбора маршрута (например, в сложных сетях с несколькими провайдерами).
• Генерировать красивые графики на базе mtr-отчётов (например, с помощью pymtr).

Заключение и рекомендации

Трассировка маршрута — это must-have навык для любого, кто работает с серверами, облаками и хостингом. traceroute и mtr — простые, но невероятно мощные инструменты: они позволяют быстро понять, где именно проблема в сети, и доказать это провайдеру или хостеру. Не забывай, что потери на отдельных хопах — не всегда критично, а звёздочки в выводе — не всегда признак беды.

Рекомендации:

• Всегда имей под рукой mtr и traceroute на сервере и локальной машине.
• Автоматизируй трассировки для критичных направлений.
• Для сложных случаев используй tcping или mtr с TCP-пакетами.
• Не стесняйся отправлять трассировку в саппорт — это ускоряет решение проблем.
• Если часто работаешь с разными дата-центрами — ищи Looking Glass у провайдеров.

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

Официальные ресурсы:
man traceroute
mtr на GitHub
Wikipedia: Traceroute