ICMP

Протокол ICMP (Internet Control Message Protocol) -- это служебный протокол, который работает поверх IP и выполняет диагностические функции. Когда с IP-пакетом что-то идет не так, именно ICMP сообщает отправителю о проблеме.

Вот типичные ситуации, когда ICMP вступает в дело:

• MTU слишком мал -- роутер не может пропустить пакет в канальную среду, потому что размер пакета превышает допустимый. Роутер прибивает пакет, а ICMP отправляет сообщение отправителю: "Я убил твой пакет, потому что он слишком большой и не пролезает в среду". Это сообщение Destination Unreachable с указанием, что среда не позволяет пропустить такой пакет.

• Нет маршрута в сеть назначения -- какой-то роутер пытается доставить пакет, но в его таблице маршрутизации нет подходящего маршрута. Пакет прибивается, а ICMP посылает диагностику: "Я твой пакет прибил, потому что нет маршрута в сеть назначения".

У ICMP на самом деле достаточно много сервисных функций. Если посмотреть спецификацию, он умеет очень многое, плюс к нему есть дополнительные расширения для ещё большего объема полезной информации.

Основные сообщения ICMP

Среди часто используемых на практике:

• TTL Expired in Transit -- если вы отправляете пакет с TTL, выставленным в какое-то значение, и слишком много роутеров встречается по цепочке, то вам приходит диагностика: пакет был отправлен со слишком маленьким TTL, и какой-то промежуточный роутер обнулил его. Такой пакет прибивается, а отправителю посылается сообщение: "Я прибил твой пакет, потому что он протух".

• Echo Request / Echo Reply -- это механизм пинга. Echo Request -- это сообщение вида "Я тебе отправляю пакет, ты его как можно быстрее обработай и сразу мне в ответ отправь подтверждение". Вы измеряете время, за которое пакет пробежал туда, был обработан и вернулся обратно. По этому времени можно делать выводы о состоянии сети.

Измерение качества сети с помощью ICMP

Если вы отправили пакет и за 5 секунд не получили ответа -- значит, что-то не работает. Либо пакеты туда не проходят, либо обратно.

Можно отправлять много пакетов и мерить статистику по ответам:

• Стабильная сеть -- все ответы приходят примерно за одно и то же время (например, ~30 мс с расхождением в пару миллисекунд). На такой сети хорошо работают голосовые приложения и вообще всё остальное.

• Нестабильная сеть -- некоторые пакеты проходят быстро, а некоторые с задержкой. Время доставки сильно "гуляет" (jitter). На таких сетях плохо работают приложения с живым потоковым голосом и видео.

Формат ICMP-сообщений

Формат очень простой. Всё выровнено по границе 4 байт:

Поле	Размер	Описание
Type	1 байт (8 бит)	Тип сообщения
Code	1 байт (8 бит)	Код сообщения
Checksum	2 байта	Контрольная сумма
Data	переменный	Зависит от типа/кода

В каждом сообщении есть два числа -- тип и код. Далее идёт контрольная сумма (checksum), которая нужна, чтобы убедиться, что пакет не побился по дороге.

Контрольная сумма ICMP vs IP

В заголовке IP тоже есть checksum, но она считается только от самого заголовка. Данные при этом не закрываются. А checksum в ICMP закрывает и данные тоже.

Используется тот же самый механизм Internet Checksum, что и в протоколе IP:

1. Берём всё содержимое сообщения, делим на 2-байтовые слова
2. Складываем все эти слова
3. Если результат больше 2 байт -- снова делим на куски по 2 байта и снова складываем (до тех пор, пока не получится 2 байта)
4. Вычитаем результат из 0xFFFF

Популярные пары Type/Code

Вот некоторые популярные пары тип и код:

Type	Code	Название	Описание
8	0	Echo Request	Запрос пинга
0	0	Echo Reply	Ответ на пинг
3	0	Network Unreachable	Нет маршрута в сеть назначения
3	1	Host Unreachable	Узел назначения недоступен
3	3	Port Unreachable	Порт недоступен (для UDP)
3	4	Fragmentation Needed	Нужна фрагментация, но стоит флаг DF
3	13	Administratively Filtered	Пакет заблокирован фильтром
11	0	TTL Expired in Transit	Пакет "протух" по дороге

Type 3 (Destination Unreachable) -- все сообщения с этим типом означают, что пакет не удалось доставить по какой-либо причине. Там целая пачка кодов: Network Unreachable, Host Unreachable, слишком маленький MTU и т.д.

Host Unreachable (3, 1) -- это когда вы нашли маршрут connected в сеть назначения, но не можете получить канальный адрес соседа. Например, роутер нашёл, что получатель сидит с ним в одной канальной среде, нашёл connected-сеть, нашёл интерфейс. Дальше в эту сеть кричит ARP: "У кого из вас такой IP, скажите свой MAC?" А узел назначения выключен, никто не ответил. Роутер пакет прибивает и отправляет диагностику: "Сеть назначения есть, а вот узла нет".

TTL Expired in Transit (11, 0) -- пакет протух по дороге. С пакетом всё хорошо само по себе, сеть работает нормально, но TTL был выставлен слишком маленький.

Поле данных

Формат данных зависит от типа и кода сообщения. Например, в случае Echo Request/Echo Reply в поле данных будут:

• Identifier (2 байта) -- идентификатор сообщения
• Sequence Number (2 байта) -- порядковый номер

По этим полям отправитель определяет, что ответ пришёл именно на конкретный запрос. Даже если ответы возвращаются не в том порядке, система сможет правильно сопоставить каждый ответ с соответствующим вопросом и корректно посчитать статистику.

Утилита ping

Наиболее очевидный способ пощупать ICMP вживую -- это пинг соседа.

Термин ping пришел из словаря людей, работающих с радарами. Вы посылаете эхо-сигнал, он отражается и возвращается к вам -- это и есть пинг. Сама утилита расшифровывается как Packet Internet Groper.

Утилита посылает Echo Request и смотрит, когда на эти запросы приходит Echo Reply в ответ.

Что показывает вывод ping

Пример: отправлено 4 пакета, получены ответы. По выводу можно сделать заключения о работе сети.

Время прохождения (RTT):

• В норме время туда-обратно обычно сильно меньше секунды
• Если пакет бегает за секунду с лишним -- сеть сильно тормозит, что-то её нагружает (например, загрузка видео на YouTube)
• Пакеты пинга доходят до получателя, но застревают в очереди и долго ждут своей очереди на отправку

Размер пакетов:

• При отправке Echo Request можно вложить произвольные данные
• В норме получатель должен вернуть вложение без изменений (отправили 32 байта -- вернулось 32 байта)
• Некоторые узлы (например, Google) режут вложение в ответе до 64 байт

TTL в ответах:

• Вы отправляете пакеты со своим системным TTL (например, 128 на Windows)
• Ответы приходят с TTL удалённого узла (например, Google отправляет с TTL 64)
• Если ответ пришёл с TTL 47, значит, между вами 17 роутеров (64 - 47 = 17), каждый "по копеечке вычел"

Статистика ping

• Packets: Sent / Received / Lost -- если вы видите значимый процент потерь, сеть работает плохо. 20-30% потерь -- сеть нестабильна. 1% потерь -- на это можно забить, TCP справится (он контролирует доставку и перезапрашивает потерянное). UDP-приложения (голос) тоже переживут потерю одного пакета из ста.

• Minimum / Maximum / Average -- минимальное, максимальное и среднее время прохождения. Не стоит питать иллюзий: если вы отправляете всего 4 пакета, среднее показывает "погоду на Марсе". Запустите ping -t в Windows (бесконечная отправка) или просто ping в Linux и замерьте статистику хотя бы за минуту -- тогда среднее будет приближено к реальности.

• Один отдельный пакет может вырваться далеко за пределы разумного (все идут за 20 мс, а один -- за 2 секунды). Это нормально для единичного случая. Проблема -- когда половина пакетов идёт за 20 мс, а половина за 200 мс. В этом случае голос и видео будут страдать.

Дополнительные параметры ping

Утилита ping позволяет задать:

• Значение TTL
• Метку Type of Service (он же DSCP)
• Флаг DF (Don't Fragment)

В Windows возможности ограничены, но в Linux утилита более продвинутая и предоставляет больше инструментов для диагностики.

Что означает, если пинг не проходит

Если узел пингается -- он живой, сеть позволяет до него добраться. Если ответы не приходят -- это ещё ни о чём не говорит:

• Узел может просто не позволять себя пинговать (получает запросы, но не отвечает)
• Где-то посередине провайдер может резать ICMP-пакеты
• Есть "одарённые" провайдеры, которые блокируют или видоизменяют ICMP -- вообще говоря, этого быть не должно, но в целях безопасности иногда так делают

Что касается Echo Request и Echo Reply, особых угроз для безопасности тут нет.

ICMP-туннелирование

Внутри каждого Echo Request можно вложить произвольную полезную нагрузку. По умолчанию это случайные данные (32 байта, обычно буквы от A до Z), но никто не мешает вкладывать туда что-то полезное.

В своё время находились люди, которые написали реализацию транспортного протокола поверх ICMP. Они эксплуатировали тот факт, что некоторые провайдеры позволяют бесплатно отправлять пинги, но берут деньги за нормальный трафик. Путём скрытой инъекции полезных данных в пинги можно было бесплатно обмениваться данными с удалённым узлом.

Подобных скрытых техник много -- через DNS, через ICMP, через другие протоколы. Пропускная способность ICMP-туннеля невелика, но если надо скрыть передачу данных -- возможность имеется.

Всё это давно палится:

• Статистический анализ -- доля ICMP-трафика становится аномально большой (ICMP -- служебный протокол, много его в сети не бывает)
• Глубокий анализ пакетов -- вложения расковыриваются без труда
• Системы IDS/IPS отслеживают такие вещи на раз

Но надо, чтобы кто-то озаботился установкой этих систем безопасности. Провайдеры редко проверяют трафик на аномалии.

Утилита traceroute

Traceroute (tracert в Windows) -- утилита трассировки маршрутов. Вы указываете узел, и программа показывает список маршрутизаторов, через которые проходят пакеты.

Утилита не гарантирует, что трасса будет именно такой. Она лишь пытается построить трассу, похожую на правду.

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

1. Отправляет пакет с TTL = 1. Ближайший роутер его убивает и присылает TTL Expired in Transit (код 11, 0). Вы узнаёте IP первого роутера.
2. Отправляет пакет с TTL = 2. Первый роутер уменьшает TTL до 1 и пересылает. Второй роутер обнуляет TTL и присылает ответ. Вы узнаёте IP второго роутера.
3. И так далее, увеличивая TTL на единицу, пока не получите ответ от конечного узла.

На каждом шаге делается 3 попытки, и результаты заносятся в таблицу.

Особенности вывода traceroute

• Звёздочки (*) -- если какой-то один узел закрыл ICMP, вы увидите три звёздочки только для него, а остальные узлы будут нормально отвечать
• Сплошные звёздочки начиная с определённого хопа -- где-то пакеты теряются, проблема с маршрутизацией или доставкой
• Чередование IP-адресов -- если в сети работает балансировка (чётные пакеты налево, нечётные направо), адреса из разных веток будут смешаны

Совет: в Windows используйте ключ -d (tracert -d), чтобы отключить DNS-резолвинг имён и получить результат быстрее.

• Петля маршрутизации -- два узла гоняют пакеты друг другу. На трассировке это хорошо видно: начиная с какого-то момента два IP-адреса зацикленно чередуются. Обычно это косяк провайдера.

Трассировка не только ICMP

Можно трассировать не только ICMP-запросами, но и "боевыми" данными -- UDP-датаграммами. На них тоже будут приходить TTL Expired in Transit.

Важное замечание: ICMP не будет отправлять сообщение об ошибке при доставке другого ICMP-пакета с ошибкой. То есть "сообщение об ошибке о том, что не удалось доставить сообщение об ошибке" -- посылаться не будет. Это сделано, чтобы не плодить лавину ошибок. Но на обычные Echo Request сообщения об ошибках генерируются нормально.

Демонстрация: ping между двумя Cisco

Имеем две Cisco-железки, связанные между собой. Роутер с IP 10.0.0.5 пингует узел 10.0.0.1.

Анализ в Wireshark

Echo Request:

• Тип 8, код 0 -- Echo Request
• Checksum корректная (Wireshark проверил)
• Identifier: 1 (идентификатор сообщения)
• Sequence Number: 0 (порядковый номер)
• Вложение: 72 байта, паттерн ABCD ABCD ABCD... (Cisco отправляет только ABCD, а Windows -- полный алфавит ABCDEFGH...)

Echo Reply:

• Тип 0, код 0 -- Echo Reply
• Identifier и Sequence Number сохранились (по ним Cisco определяет, что это ответ именно на то сообщение, которое она отправила)
• Вложение тоже ABCD (одна Cisco пингает другую)
• Wireshark посчитал время прохождения пакета туда-обратно

При отправке 5 пакетов видим: 5 восклицательных знаков (все успешно), Identifier остаётся тем же, а Sequence Number увеличивается с каждым пакетом.

Расширенный режим ping на Cisco

Если запустить ping без параметров на Cisco, утилита начинает задавать вопросы:

• Протокол (IP / IPv6)
• Адрес назначения
• Количество повторений
• Размер сообщения (по умолчанию 100 байт)
• Таймаут (по умолчанию 2 секунды)
• Extended commands -- расширенные команды

В расширенном режиме можно:

• Выставить Type of Service (DSCP)
• Включить флаг DF (Don't Fragment)
• Задать Data Pattern (например, 0x01020304 вместо стандартного ABCD)
• Запустить sweep -- отправку пакетов с нарастающим размером для определения Path MTU

Демонстрация: определение Path MTU

Sweep-режим

Указываем минимальный размер (1400) и максимальный (1500), шаг 1 байт. Cisco отправляет пинги с нарастающим размером. До 1500 всё проходит (это общий размер IP-пакета, не размер вложения). При 1501 пакет уже не пролезает в канальную среду (обычный Ethernet без Jumbo Frames).

В Wireshark видно: последний успешный пакет содержит 1472 байта вложения (1500 - 20 байт IP-заголовок - 8 байт ICMP-заголовок).

MTU и фрагментация

Добавляем в топологию промежуточный маршрутизатор (multilayer switch) и выставляем на его интерфейсе MTU 1400.

Без флага DF: отправляем пакет 1500 байт. Он доходит до свитча, фрагментируется на два пакета, доставляется получателю. Получатель собирает фрагменты обратно (выполняет пересборку) и отправляет один ответ.

С флагом DF: отправляем пакет 1500 байт. Он доходит до свитча, но фрагментировать нельзя (стоит DF). Получаем ответ:

ICMP Destination Unreachable
Type: 3
Code: 4 (Fragmentation Needed and Don't Fragment was Set)
Next-Hop MTU: 1400

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

Path MTU Discovery

Именно так работает Path MTU Discovery:

1. TCP отправляет пакеты с выставленным флагом DF
2. Если где-то по пути пакет не проходит -- приходит ICMP Fragmentation Needed с указанием MTU
3. TCP запоминает это значение и больше не отправляет сегменты крупнее

UDP тоже может отслеживать подобные вещи (стек UDP + IP делает это совместно). Если приложение попыталось отправить слишком крупную датаграмму, ICMP Fragmentation Needed подскажет правильный размер.

Содержимое ICMP-сообщения об ошибке

Когда приходит сообщение об ошибке, после заголовка ICMP (тип, код, checksum, неиспользуемые 2 байта, MTU) идёт вложение -- начало той датаграммы, которая вызвала проблему, включая IP-заголовок. По этим данным можно понять, какой именно пакет не удалось доставить (IP-адреса, порты TCP/UDP и т.д.).

Демонстрация: Port Unreachable

Пытаемся установить Telnet-сессию (TCP, порт 23) на удалённый узел 192.168.0.1. Сразу получаем Connection Refused -- без таймаутов. В Wireshark видно: SYN-пакет ушёл, в ответ пришёл RST (Reset). TCP сам отработал отказ.

А вот в UDP никакого RST нет. Пробуем TFTP (copy startup-config tftp://192.168.0.1). Датаграмма на UDP-порт 69 уходит, а в ответ приходит:

ICMP Destination Unreachable
Type: 3
Code: 3 (Port Unreachable)

Пакет доставлен до получателя, но на транспортном уровне порт недоступен. Именно ICMP служит диагностическим помощником для UDP -- сообщает, что попытка отправки не удалась.

Демонстрация: Administratively Filtered

Настраиваем access-list на роутере, который разрешает трафик только от IP 1.1.1.1 (а всё остальное запрещено неявным deny в конце):

access-list 1 permit 1.1.1.1
interface GigabitEthernet0/0
  ip access-group 1 in

Пингуем роутер -- на каждый пинг возвращается сообщение Communication Administratively Filtered:

ICMP Destination Unreachable
Type: 3
Code: 13 (Communication Administratively Filtered)

Это как HTTP 451 -- цензура не пропустила. Echo Request прошёл по проводу и воткнулся в роутер, а роутер сказал: "Эта датаграмма не от разрешённого IP, я её баню".

Фильтрация на входе vs на выходе

Если access-list висит на входе (in) и пакет не проходит -- ICMP-сообщение отправляется обратно отправителю.

Если access-list висит на выходе (out) и зарубает, например, Echo Reply -- то сообщение "я убил твой пакет" узнает только сам роутер (он сам пострадавшая сторона). По проводу мы его не увидим. Пакет убит до того, как покинул устройство.

Разница в том, расскажете ли вы отправителю о проблеме или просто молча прибьёте пакет.

Замечание по работе access-list на Cisco

Не все реализации Cisco одинаково хорошо дружат с access-list. Бывает, что вроде бы всё настроено правильно, а фильтрация не работает. Особенно это касается коммутируемых интерфейсов -- access-list нужно вешать на интерфейс VLAN, а не на физический порт.