ICMP, ping и traceroute: TTL, Hop Limit, Path MTU и диагностика сети

Что такое ICMP и почему это не «порт для ping»

ICMP - служебный протокол интернет-уровня. Он используется для передачи диагностических сообщений и сообщений об ошибках, связанных с обработкой IP-пакетов. Для IPv4 базовая спецификация ICMP описана в RFC 792. Для IPv6 используется ICMPv6, определённый в RFC 4443.

ICMP не работает поверх TCP или UDP и не использует номера портов TCP/UDP. В IPv4 ICMP имеет номер IP-протокола 1. В IPv6 ICMPv6 обозначается значением Next Header 58.

В гайде про OSI и TCP/IP разобрано место ICMP в сетевом стеке. А отличие портов TCP и UDP от IP-адресов подробно рассмотрено в материале про TCP, UDP, порты и сокеты.

ICMP - это не только Echo Request и Echo Reply

Ping использует Echo Request и Echo Reply, но ICMP нужен не только для проверки доступности. Он также сообщает о недостижимости, истечении TTL, слишком большом пакете и других сетевых ситуациях.

Тип и код важны при анализе захвата трафика. Сообщение «Destination Unreachable» само по себе ещё не говорит, что именно недоступно: сеть, узел, порт, маршрут или другой элемент. Нужно смотреть конкретный тип, код и исходный пакет, к которому относится ошибка.

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

Обычный ping отправляет ICMP Echo Request и ждёт соответствующий Echo Reply. В ответе можно измерить round-trip time, то есть время прохождения от отправителя до назначения и обратно.

Microsoft описывает Windows ping именно как проверку IP-связности с помощью ICMP Echo Request/Echo Reply. Это хороший инструмент первого уровня диагностики, но его результат нужно правильно интерпретировать.

Что обычно показывает ping

• разрешилось ли имя в IP-адрес, если указано доменное имя;
• получен ли ICMP Echo Reply;
• round-trip time для каждого ответа;
• сколько запросов отправлено, получено и потеряно;
• TTL или Hop Limit, оставшийся в пришедшем ответе.

Что ping действительно доказывает, а что нет

И наоборот, успешный ping не означает, что нужный сервис доступен. Для проверки TCP-порта в Windows полезнее Test-NetConnection host -Port 443, а работу конкретного приложения нужно проверять его собственным протоколом.

Что такое TTL в IPv4 и Hop Limit в IPv6

Поле TTL в IPv4 исторически называется Time To Live. На практике при маршрутизации оно работает прежде всего как ограничитель количества переходов: маршрутизатор уменьшает значение перед пересылкой пакета. Когда значение исчерпано, пакет отбрасывается и обычно формируется ICMP Time Exceeded.

В IPv6 это поле называется точнее: Hop Limit. RFC 8200 определяет его как 8-битное значение, уменьшаемое на единицу каждым узлом, который пересылает пакет.

Зачем TTL вообще нужен

Без ограничения пакет при ошибке маршрутизации мог бы ходить по петле очень долго. TTL/Hop Limit даёт пакету конечный «запас переходов» и позволяет остановить такой трафик.

Как tracert и traceroute строят маршрут

Traceroute использует TTL/Hop Limit специально. Первая проба отправляется с ограничением 1, следующая с 2, затем 3 и так далее. Каждый промежуточный маршрутизатор, на котором лимит исчерпывается, может вернуть сообщение Time Exceeded. По этим ответам инструмент собирает последовательность hops.

Windows tracert использует ICMP Echo Request/ICMPv6-пробы с увеличивающимся TTL/Hop Limit. В Linux классический traceroute по умолчанию обычно использует UDP-пробы на высокие порты, но может работать также через ICMP или TCP. Поэтому трассы с разных ОС могут отличаться даже до одного и того же сервера.

Почему в traceroute появляются * * *

Звёздочка означает только одно: в отведённое время не получен ожидаемый ответ на конкретную пробу. Это не автоматическое доказательство потери пользовательского трафика на этом маршрутизаторе.

Как читать трассу правильно

Если один промежуточный hop показывает * * *, но следующие hops и конечный сервер отвечают нормально, этот промежуточный узел очевидно продолжает пересылать трафик. Сам по себе его пропущенный ICMP-ответ не является местом обрыва.

Серьёзнее выглядит ситуация, когда после определённого hop ответы прекращаются полностью и конечный адрес тоже недоступен. Но даже тогда нужно сравнивать несколько направлений и типов трафика, а не выносить диагноз по одной трассе.

RTT, packet loss и jitter: что можно увидеть по ping

RTT - время туда и обратно. Оно включает оба направления и обработку конечными узлами. Из одного значения RTT нельзя определить, на каком именно направлении возникла задержка.

Обычный ping даёт полезную картину стабильности, но короткой серии из четырёх пакетов мало для периодической проблемы. Для вечерних лагов, Wi-Fi-помех или bufferbloat нужно тестировать в проблемное время и сравнивать состояние без нагрузки и под нагрузкой.

Если интернет «тормозит», а локальный ping до роутера уже скачет, сначала ищут проблему внутри дома: Wi-Fi, кабель, перегрузку клиента или LAN. Если до роутера стабильно, а до внешнего адреса задержка резко растёт, круг поиска сдвигается к WAN, провайдеру, VPN или внешнему маршруту. Подробная последовательность есть в диагностике Keenetic и домашней сети.

Почему ping до соседа в LAN связан с ARP или NDP

Перед отправкой IPv4-пакета устройству в той же локальной сети узлу обычно нужно узнать MAC-адрес получателя через ARP. Поэтому неудачный ping внутри одного VLAN может быть следствием не ICMP, а проблемы уровнем ниже: неправильной маски, VLAN, ARP, Wi-Fi client isolation, кабеля или выключенного устройства.

Для IPv6 похожую роль выполняет Neighbor Discovery, который сам использует ICMPv6. Это ещё одна причина, почему в IPv6 нельзя относиться ко всему ICMPv6 как к необязательному «пингу».

Подробнее механика IPv4 разобрана в статье ARP, IP и MAC: ARP-кэш, конфликты IP и Gratuitous ARP.

MTU и Path MTU: в чём разница

Link MTU - максимальный IP-пакет, который конкретный канал способен передать в рамках своих правил. Для обычного Ethernet часто встречается MTU 1500 байт, но это не универсальная гарантия для всего пути.

Path MTU, или PMTU - минимальный MTU среди всех участков маршрута между источником и назначением. Если где-то по пути есть PPPoE, VPN, туннель или другой участок с дополнительной инкапсуляцией, доступный PMTU может оказаться меньше локальных 1500 байт.

Если подозрение связано именно с VPN, сначала стоит отделить физический предел роутера, загрузку CPU и маршрут от MTU. Это разобрано в материале почему Keenetic может снижать скорость через WireGuard.

Как Path MTU Discovery связан с ICMP

Path MTU Discovery нужен, чтобы отправитель определил размер пакетов, которые проходят весь маршрут без проблем.

IPv4

Классический механизм RFC 1191 использует IPv4-пакеты с флагом Don't Fragment. Если маршрутизатор не может передать такой пакет через следующий участок из-за меньшего MTU, он отбрасывает пакет и возвращает ICMP Destination Unreachable с кодом «fragmentation needed». Современная форма сообщения может указывать допустимый Next-Hop MTU.

IPv6

В IPv6 маршрутизаторы не выполняют фрагментацию транзитного пакета вместо источника. Если пакет слишком велик для следующего канала, маршрутизатор возвращает ICMPv6 Packet Too Big. Источник уменьшает размер последующих пакетов. RFC 8201 прямо указывает, что PMTUD для IPv6 зависит от таких сообщений.

IPv6 требует минимальный link MTU 1280 байт. RFC 8200 рекомендует использовать PMTUD, чтобы при возможности передавать пакеты крупнее этого минимума.

Почему блокировка ICMP может сломать большие передачи

Один из самых неприятных сценариев - PMTU black hole. Маленькие пакеты проходят, TCP handshake может завершиться, но когда начинается передача более крупных пакетов, они теряются на участке с меньшим MTU. Если нужное ICMP-сообщение о размере тоже блокируется, отправитель не получает нормальной обратной связи.

RFC 8201 прямо описывает типичный IPv6-симптом: соединение может успешно пройти TCP three-way handshake, а затем зависнуть при передаче данных, если сообщения Packet Too Big не доходят до источника.

Почему «просто разрешить фрагментацию» - плохая стратегия

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

Для IPv6 промежуточный маршрутизатор не фрагментирует пакет. Источник должен адаптировать размер на основании PMTU или, если это действительно требуется, сформировать IPv6-фрагменты сам.

Поэтому при проблемах VPN, PPPoE и туннелей правильный путь - понять реальный MTU/PMTU и настройку MSS, а не бессистемно уменьшать MTU на всех устройствах.

Практическая диагностика ping и маршрута в Windows

1. Проверить локальный стек

Проверяет работу локального IPv4 TCP/IP-стека. Успешный ответ не доказывает исправность Ethernet, Wi-Fi, кабеля или роутера.

2. Проверить свой шлюз

Если шлюз не отвечает, сначала проверяют локальную сеть: адрес и маску, ARP, VLAN, Wi-Fi, кабель и firewall. Адрес шлюза нужно брать из своей конфигурации, а не копировать этот пример.

3. Проверить внешний IP

Если внешний IP отвечает, но доменные имена не работают, это аргумент в пользу проверки DNS. Но недоступность именно этого адреса ещё не доказывает общий обрыв интернета.

4. Сравнить имя и IP

При указании имени Windows сначала должен получить IP через механизм разрешения имён. Если IP работает, а имя нет, проверяют DNS.

5. Построить трассу

Ключ -d отключает обратное DNS-разрешение адресов hops и часто делает трассу быстрее и чище для диагностики.

6. Проверить TCP-порт отдельно

Это уже не ICMP-проверка сервиса, а попытка проверить TCP-доступность указанного порта. Она полезна, когда ping работает, но приложение не подключается.

Как проверить размер пакета через Windows ping

В Windows для IPv4 можно запретить фрагментацию ключом -f и задать размер данных ICMP ключом -l.

Число 1472 здесь не является «правильным MTU для интернета». Это тестовый ICMP payload. При стандартном IPv4-заголовке 20 байт и ICMP-заголовке 8 байт такой пакет даёт 1500 байт на IP-уровне: 1472 + 20 + 8.

Для PPPoE, VPN, мобильной сети, двойных туннелей и других схем рабочее значение может быть ниже. Проверять нужно именно проблемный маршрут и желательно сопоставлять результат с захватом пакетов, а не применять найденное число ко всей сети.

Traceroute, tracepath и разные методы проб

В Linux стандартный набор инструментов шире. Классический traceroute может использовать UDP, ICMP или TCP. Опция -I выбирает ICMP Echo, -T - TCP SYN. Это полезно, если обычные UDP-пробы фильтруются.

tracepath интересен тем, что одновременно трассирует путь и пытается обнаруживать MTU по маршруту. Конкретный набор ключей зависит от установленной реализации, поэтому перед использованием на сервере или NAS лучше проверить локальную справку man traceroute или man tracepath.

Когда одного tracert недостаточно

Windows также содержит pathping. Он сочетает построение маршрута с более длительным сбором статистики. Инструмент может быть полезен, когда нужно сравнить задержку и ответы по нескольким hops.

Но и здесь действует важное ограничение: промежуточный маршрутизатор может ограничивать ответы самому диагностическому инструменту, продолжая нормально пересылать пользовательский трафик. Высокая «потеря» на одном hop не считается реальной потерей транзита, если следующие узлы не наследуют эту потерю.

Что смотреть в Wireshark

Когда ping и traceroute дают неоднозначную картину, захват трафика показывает сами сообщения.

Для диагностики PMTU особенно важны

• исходный размер IP-пакета;
• флаг DF в IPv4, если он используется;
• ICMP «fragmentation needed» для IPv4;
• ICMPv6 Packet Too Big и сообщаемый MTU;
• повторные TCP-передачи после пропажи крупных сегментов;
• разница между захватом до и после VPN/роутера.

Почему ICMPv6 особенно важен

ICMPv6 является обязательной частью IPv6. Он используется не только для Echo Request/Echo Reply. RFC 4861 определяет через ICMPv6 Neighbor Discovery: Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement и Redirect.

Подробно SLAAC, Router Advertisement, DHCPv6 и Prefix Delegation разобраны в отдельном материале IPv6 дома: SLAAC, DHCPv6, Router Advertisement и Prefix Delegation.

Нужно ли разрешать весь ICMP

Нет необходимости бездумно разрешать любой ICMP с любого направления, но столь же плохая идея - блокировать весь протокол одной кнопкой только потому, что «ping не нужен».

Правила для домашнего роутера, корпоративного firewall и публичного сервера будут разными. Нельзя копировать универсальный список «разрешить типы X, Y, Z» без понимания роли интерфейса и используемого стека.

Ping между VLAN: где искать проблему

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

Сначала проверяют:

• правильные IP, маски и шлюзы обоих устройств;
• маршруты между подсетями;
• правило firewall из исходной VLAN в целевую;
• локальный firewall самого конечного устройства;
• не разрешено ли приложение при запрещённом Echo или наоборот.

Само разделение VLAN и логика правил подробно разобраны в статье VLAN простыми словами для дома и малого офиса.

Почему ping не измеряет скорость сети

Ping измеряет задержку ICMP-проб, а не пропускную способность канала. Гигабитная локальная сеть и 100-мегабитная сеть могут показывать почти одинаковый ping до соседнего устройства. И наоборот, высокая скорость загрузки не исключает проблем с latency под нагрузкой.

Для локальной пропускной способности нужен отдельный тест, например iperf3 между ПК и NAS. Правильная диагностика разделяет минимум три величины: Link speed, throughput и latency.

Порядок диагностики, если «интернет странно работает»

Типичные ошибки при диагностике ping и traceroute

• Считать любой timeout доказательством выключенного устройства.
• Считать успешный ping доказательством работоспособности HTTPS, SMB, камеры или NAS.
• Путать RTT с односторонней задержкой.
• Считать звёздочку в traceroute местом физической потери трафика.
• Сравнивать трассы, полученные разными методами проб, как идентичные тесты.
• Определять ОС только по оставшемуся TTL.
• Сразу уменьшать MTU до случайного «советованного» значения.
• Блокировать весь ICMP/ICMPv6 на firewall.
• Измерять интернет только по ping и называть это тестом скорости.
• Менять одновременно MTU, DNS, VPN и firewall, после чего невозможно понять настоящую причину.

Как интерпретировать распространённые ситуации

На какие документы опирается этот материал

Синтаксис команд Windows сверялся с актуальной документацией Microsoft Learn для ping и tracert. Поведение Linux traceroute - с документацией traceroute(8). Конкретные ключи могут отличаться в других реализациях и операционных системах.

Частые вопросы про ICMP, ping, traceroute и MTU