ping, traceroute, mtr — читаем output до буквы

Когда сеть «не работает», первые три команды, которые набирает любой инженер — это ping, traceroute (или tracert в Windows) и mtr. Они кажутся школьными — что там сложного, отправил пинг? — но за каждой строкой output скрывается ICMP-протокол, TTL, маршрутизация, и куча возможных причин, почему что-то не так.

В этом уроке разберём, что эти три команды делают на самом деле, какой output они дают, как его читать построчно, и какие выводы делать. Это базовый инструментарий troubleshooting — без них вы как электрик без вольтметра.

ping — проверяем достижимость

ping посылает на target ICMP Echo Request пакет, ждёт ICMP Echo Reply, измеряет время round-trip. Если получили ответ — target достижим и сеть до него работает. Если нет — что-то блокирует ICMP или target недоступен.

ping google.com
PING google.com (142.250.74.110): 56 data bytes
64 bytes from 142.250.74.110: icmp_seq=0 ttl=116 time=12.405 ms
64 bytes from 142.250.74.110: icmp_seq=1 ttl=116 time=13.219 ms
64 bytes from 142.250.74.110: icmp_seq=2 ttl=116 time=12.851 ms
64 bytes from 142.250.74.110: icmp_seq=3 ttl=116 time=11.972 ms
^C
--- google.com ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 11.972/12.612/13.219/0.487 ms

Разберём каждую часть:

PING google.com (142.250.74.110) — что DNS зарезолвилось в этот IP. Уже полезно: если эта строка не появляется, проблема в DNS, не в сети.
56 data bytes — размер payload в ICMP-пакете. На уровне Ethernet общий размер 98 байт (56 data + 8 ICMP header + 20 IP header + 14 Ethernet header).
64 bytes from 142.250.74.110 — получили 64-байтовый ответ. 64 = 56 data + 8 ICMP header (IP header в этом подсчёте уже отдельно).
icmp_seq=0 — порядковый номер пакета. Если пропуски (seq=0, seq=2, без seq=1) — значит был packet loss.
ttl=116 — Time To Live в IP-заголовке ответа. Сервер ответил с начальным TTL (обычно 64 для Linux, 128 для Windows), а сетевые узлы декрементировали. 128 - 116 = 12 хопов до сервера и обратно. Часто start TTL — 64 на Linux/macOS.
time=12.405 ms — round-trip time. От нашего ping до его ответа.

В статистике в конце:

4 packets transmitted, 4 packets received — все 4 запроса дошли и вернулись.
0.0% packet loss — ноль потерь. Если >0%, сеть нестабильна где-то.
min/avg/max/stddev = 11.972/12.612/13.219/0.487 — min, среднее, max, стандартное отклонение latency. Большой stddev = jitter, плохо для voice/video.

ICMP Echo Request / Reply -- то, что использует ping

Your host

ICMP Echo Request (type 8)

Target

Your host

ICMP Echo Reply (type 0)

Target

Что значат разные ошибки ping

Если ping не работает, прочитайте сообщение об ошибке — оно само по себе диагностика.

`ping: cannot resolve google.com: Unknown host`

DNS не работает. Проверьте /etc/resolv.conf или попробуйте dig google.com @8.8.8.8. Скорее всего проблема в системном DNS, не в сети.

`Request timeout for icmp_seq 0`

Пакет ушёл, ответа нет. Возможные причины:

Target не существует или выключен. Если ping на нерабочий IP.
Firewall блокирует ICMP. Многие серверы дропают ICMP по умолчанию — например, AWS EC2 без специальной SG-rule. Это не значит, что сервер мёртвый, просто ping не пройдёт.
Маршрутизация сломана. Где-то между вами и target пакет не доходит.
Packet loss. Если редкие timeout-ы в потоке нормальных ответов.

ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=8.4 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=8.2 ms
^C

Первые два пакета потерялись, дальше всё OK — скорее всего jitter в сети, не критично. Если 50% timeout — проблема серьёзная.

`From 192.168.1.1: icmp_seq=0 Destination Host Unreachable`

Ваш роутер пытался отправить пакет, но не смог найти маршрут. Скорее всего проблема в локальном routing-е (нет default gateway) или ARP не нашёл MAC получателя в той же подсети.

`From 10.0.0.1: icmp_seq=0 Destination Net Unreachable`

Промежуточный роутер не имеет маршрута к нужной сети. Это видит ваш узел через ICMP error от роутера.

`ping: sendto: Operation not permitted`

В Linux нужны root-права для ping (raw sockets). Используйте sudo ping. На macOS/Windows — обычно не требуется.

`ping: sendto: No route to host`

Нет маршрута до сети получателя. Часто после VPN-disconnect или сетевого reconfig.

traceroute — путь пакета между вами и target

traceroute показывает, через какие промежуточные роутеры идёт пакет. Это бесценно при диагностике «где-то по дороге ломается».

traceroute google.com
traceroute to google.com (142.250.74.110), 64 hops max, 40 byte packets
 1  router.local (192.168.1.1)  3.012 ms  2.890 ms  2.831 ms
 2  10.50.0.1 (10.50.0.1)  8.123 ms  7.992 ms  8.054 ms
 3  isp-edge.example.net (203.0.113.5)  9.501 ms  9.412 ms  9.554 ms
 4  72.14.196.81 (72.14.196.81)  10.234 ms  10.111 ms  10.090 ms
 5  108.170.246.65 (108.170.246.65)  11.502 ms  11.488 ms  11.601 ms
 6  142.251.49.69 (142.251.49.69)  12.211 ms  12.301 ms  12.198 ms
 7  142.250.74.110 (142.250.74.110)  12.405 ms  12.532 ms  12.401 ms

Каждая строка — один hop (роутер на пути):

Номер хопа (1, 2, 3, …) — порядковый.
Имя/IP — DNS-имя роутера (если резолвится) и его IP.
Три тайминга — traceroute шлёт 3 пробных пакета на каждый хоп, чтобы детектировать flaps. Если разница большая — jitter на этом хопе.

Если в строке * * * — роутер не ответил на 3 пробы. Это часто:

Роутер дропает ICMP Time Exceeded (большие провайдеры так делают для уменьшения нагрузки).
Firewall на пути блокирует ответы.

traceroute slow-server.com
 1  192.168.1.1  2.0 ms
 2  10.50.0.1  8.0 ms
 3  isp.example.net  9.5 ms
 4  * * *
 5  * * *
 6  * * *
 7  slow-server.com  150 ms

Хопы 4-6 «невидимы», но target в итоге достижим. Это не означает поломку — просто промежуточные роутеры не отвечают на traceroute-пробы. Главное — target отвечает.

Как работает traceroute — TTL hack

Магия traceroute — в эксплуатации TTL (Time To Live) поля IP-заголовка. Это начальное число хопов, после которых пакет дропается. Каждый роутер декрементирует TTL на 1; если стало 0 — роутер шлёт назад ICMP Time Exceeded и дропает пакет.

Как traceroute использует TTL для обнаружения hops

Round 1: TTL=1

hop 1 (router.local)

Round 2: TTL=2

hop 2 (isp.net)

...

Target отвечает: ICMP Echo Reply или TCP RST

Какой протокол используют пробы? Зависит от ОС:

Linux default: UDP на высокие порты. Target отвечает ICMP Port Unreachable (никто на этих портах не слушает).
macOS default: UDP, как Linux.
Windows tracert: ICMP Echo Request, как ping.
mtr и Linux с -I: ICMP Echo Request.

Это иногда влияет на результат: если на пути файрвол блокирует UDP, но не ICMP, разные tools покажут разное. Используйте traceroute -I (ICMP) или traceroute -T -p 443 (TCP на порт 443 — маскируется под обычный HTTPS) для обхода фильтров.

Латентность и distance — читаем по hops

Анализ latency между hops показывает, где задержка возникает:

traceroute slow-target.example.com
 1  router.local         1.5 ms
 2  isp.example.net      5.2 ms     # +3.7ms (нормальный inter-DC link)
 3  isp-core.example.net 6.0 ms     # +0.8ms (мало -- скорее всего тот же DC)
 4  transit.tier1.net    8.5 ms     # +2.5ms (cross-country backbone)
 5  remote-isp.com       45.0 ms    # +36.5ms (long-distance, например, через Атлантику)
 6  target.com           45.5 ms    # +0.5ms (last mile)

Hop 4 -> 5 — скачок 36ms, скорее всего пересечение океана или длинный backbone-link. Это нормально для трансатлантического trip.

Если бы был скачок в +200ms между близкими hops без длинного линка — это плохо. Возможно перегружен какой-то роутер или плохой провайдер.

TIP

Latency на промежуточном роутере (показанная в traceroute) — НЕ задержка только на этом хопе. Это round-trip от вас до этого роутера. Сравните разницу между hops для оценки latency сегмента: hop_N RTT минус hop_(N-1) RTT.

mtr — traceroute + ping одновременно

mtr (My Traceroute) объединяет ping и traceroute: непрерывно отправляет пакеты на каждый хоп и показывает статистику в реальном времени. Это позволяет видеть флуктуации и packet loss на каждом хопе.

mtr google.com
                                  My traceroute  [v0.95]
host (192.168.1.10)              Sent: 100   Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. router.local                    0.0%   100    1.2   1.4   1.0   3.5   0.5
 2. 10.50.0.1                       0.0%   100    8.1   8.3   7.9   9.5   0.4
 3. isp-edge.example.net            1.0%   100    9.5   9.7   9.3  10.5   0.3
 4. 72.14.196.81                    0.0%   100   10.2  10.4  10.0  11.0   0.3
 5. 108.170.246.65                  0.0%   100   11.5  11.6  11.3  12.5   0.3
 6. 142.250.74.110                  0.0%   100   12.5  12.6  12.3  13.5   0.4

Колонки:

Loss% — процент потерь на этом хопе. Если 50% потерь на 4-м хопе и 0% на 5-м — значит на 4-м роутер просто дропает ICMP, реальной потери нет (трафик прошёл дальше).
Snt — сколько пакетов отправлено.
Last/Avg/Best/Wrst — последний/средний/лучший/худший RTT.
StDev — стандартное отклонение, показывает jitter.

mtr запускается интерактивно и обновляется. Часто запускают «в фоне» при стресс-тестах, чтобы поймать момент сбоя:

# Запустить mtr на 5 минут, в текстовом режиме (для логирования):
mtr -r -c 100 google.com > /tmp/mtr-google.log

# Это особенно полезно при репорте сетевых проблем провайдеру -- даёт точную картинку

Типичные patterns в выводе

Все хопы быстро, потом резкий jump

 1  router.local         1.5 ms
 2  isp.net              5.0 ms
 3  transit.com          7.0 ms
 4  remote-isp.com     180.0 ms  # резкий скачок
 5  target.com         185.0 ms

Скорее всего трансокеанский или длинный международный link. Сам по себе не проблема, если ожидаемо (вы в Москве, target в Сан-Франциско — ~150-200 ms норма).

Один хоп с высокой потерей, дальше нормально

 3  bad-router.isp.net   5.0 ms  Loss 80%
 4  next-hop.net         9.0 ms  Loss 0%
 5  target.com          12.0 ms  Loss 0%

Хоп 3 просто rate-limit ICMP-ответы (не отвечает на 80% проб). Реальной потери трафика нет, потому что hop 4 и 5 имеют 0% loss. Это типично для backbone-роутеров.

Loss на всех hops от какого-то номера

 1  router.local         1.5 ms   Loss 0%
 2  isp.net              5.0 ms   Loss 0%
 3  problem.isp.net      7.0 ms   Loss 30%
 4  next.net             9.0 ms   Loss 30%
 5  target.com          12.0 ms   Loss 30%

Loss начался с hop 3 и держится дальше — проблема в hop 3. Это где реально дропаются пакеты. Эскалируйте провайдеру/owner-у hop 3.

Маршрут зацикливается (loop)

 5  router-a.com         10 ms
 6  router-b.com         12 ms
 7  router-a.com         14 ms
 8  router-b.com         16 ms
...

Routing loop. Серьёзная проблема — неправильно сконфигурированы routing таблицы. Эскалация немедленная провайдеру.

Звёздочки до конца

 5  * * *
 6  * * *
 7  * * *
...
 30 * * *

Все хопы после 5 не отвечают. Возможные причины:

Где-то на пути firewall блокирует traceroute-пробы. Попробуйте -T -p 443 (TCP-режим).
Реально проблема с маршрутизацией — пакеты не доходят. Проверьте ping target (если ICMP проходит, скорее всего просто блокируют traceroute).

Когда ping/traceroute не помогают

Эти инструменты диагностируют L3-сеть: IP-маршрутизация, базовая reachability. Они не покажут:

TCP-проблемы. SYN отбрасывается, retransmits. Нужен tcpdump, ss.
DNS-проблемы. Нужен dig (отдельный урок).
Application-проблемы. HTTP 500, медленный response. Нужен curl -v.
TLS-проблемы. Сертификат истёк, неверный handshake. Нужен openssl s_client.

Также: ICMP может быть полностью отключён на target (например, AWS NLB не отвечает на ping по умолчанию), но HTTPS работает идеально. Не делайте вывод «сервер мёртв» только из ping fail.

Полный арсенал сетевой диагностики на Linux

Попробуй сам

Сделайте traceroute до нескольких разных целей и посмотрите, как меняется путь:

# До серверов разных континентов:
traceroute google.com       # обычно близко -- 5-10 хопов
traceroute baidu.com        # Китай -- может быть 20+ хопов, через Азию
traceroute za.gov.za        # ЮАР -- долго через Европу/Африку

# Сравните latency profile:
mtr -c 20 -r google.com > /tmp/google.txt
mtr -c 20 -r baidu.com > /tmp/baidu.txt
cat /tmp/google.txt
cat /tmp/baidu.txt

Найдите свой ISP в hops (обычно 2-3 hop) — увидите имя провайдера в hostname. Найдите Tier-1 transit (level3, cogent, gtt, ntt) — эти crossing-points есть в почти любом international trace.

Попробуйте TCP-traceroute на порт 443 (HTTPS):

# Linux:
sudo traceroute -T -p 443 google.com

# macOS:
sudo traceroute -P TCP -p 443 google.com

# Часто работает там, где обычный traceroute (UDP) блокируется

Включите ping -s (большой пакет) — иногда small ping проходит, а большой нет (MTU issues):

# 1500-byte payload (с заголовками ~1518, на грани стандартного Ethernet MTU):
ping -s 1472 google.com

# 1300-byte (нормальный для большинства Wi-Fi сред):
ping -s 1300 google.com

# Если ping с -s 1472 не проходит, а с -s 1000 проходит -- проблема MTU где-то на пути

Проверка знанийKnowledge check

Junior спрашивает: 'У меня traceroute показывает * * * на пятом хопе и всех последующих, до самого target. Получается, проблема на пятом хопе и сервер недостижим. Так ли это?'

ОтветAnswer

Этот вывод не обязательно означает проблему! Звёздочки в traceroute означают, что роутер не ответил на probe в течение timeout-а. У этого две принципиально разные причины. Первая -- проблема с маршрутизацией. Реально пакеты не доходят до этого хопа и дальше. В этом случае ping на target тоже будет failure (no replies). Вторая -- блокировка traceroute-проб. Роутер получает пакеты, пересылает дальше, но не отвечает Time Exceeded по политике (rate limit, security policy, или просто экономия). При этом трафик через него ОК! Часто так настраивают backbone-роутеры крупных провайдеров (Cogent, Level3, Hurricane Electric). Как различить? Проверьте reachability target напрямую: `ping target` (если ICMP не блокируется на target), `curl -v https://target/`, или `nc -zv target 443`. Если ping/curl работают -- traceroute врёт по поводу 'mertвости' пятого хопа. Если ничего не работает -- да, реальная проблема. Дальше: попробуйте другой тип проб. `traceroute -I` (ICMP вместо UDP) или `traceroute -T -p 443` (TCP-режим). Иногда UDP блокируется, ICMP/TCP проходит -- и вы увидите остальные хопы. В целом: traceroute -- approximate-инструмент, не absolute truth. Используйте его как одну из подсказок, и подтверждайте выводы другими методами (ping, curl, mtr).