Структура протокола ICMP
Internet Control Message Protocol или просто ICMP описан в RFC 792. Данный протокол определяет набор различных сообщений, целью которых является управление сетью.
ICMP сообщения могут классифицироваться как сообщения об ошибках, а также как сообщения типа “запрос — ответ”.
Ниже представлен основной формат пакета ICMP
Пакеты ICMP определяются по их типу (Type), однако, большинство типов могут иметь более специфичные типы, они определяются по полю Code. RFC 1700 определяет все основные типы и коды для протокола ICMP.
В следующей таблице перечислены данные поля с их описанием
| Тип | Код | Название |
|---|---|---|
| 0 | 0 | Echo Reply |
| 3 | DESTINATION UNREACHABLE | |
| 0 | Network Unreachable | |
| 1 | Host Unreachable | |
| 2 | Protocol Unreachable | |
| 3 | Port Unreachable | |
| 4 | Fragmentation Needed and Don’t Fragment Flag Set | |
| 5 | Source Route Failed | |
| 6 | Destination Network Unknown | |
| 7 | Destination Host Unknown | |
| 8 | Source Host Isolated | |
| 9 | Destination Network Administratively Prohibited | |
| 10 | Destination Host Administratively Prohibited | |
| 11 | Destination Network Unreachable for Type of Service | |
| 12 | Destination Host Unreachable for Type of Service | |
| 4 | 0 | SOURCE QUENCH (deprecated) |
| 5 | REDIRECT | |
| 0 | Redirect Datagram for the Network (or Subnet) | |
| 1 | Redirect Datagram for the Host | |
| 2 | Redirect Datagram for the Network and Type of Service | |
| 3 | Redirect Datagram for the Host and Type of Service | |
| 6 | 0 | ALTERNATE HOST ADDRESS |
| 8 | 0 | ECHO |
| 9 | 0 | ROUTER ADVERTISEMENT |
| 10 | 0 | ROUTER SELECTION |
| 11 | TIME EXCEEDED | |
| 0 | Time to Live Exceeded in Transmit | |
| 1 | Fragment Reassembly Time Exceeded | |
| 12 | PARAMETER PROBLEM | |
| 0 | Pointer Indicates the Error | |
| 1 | Missing a Required Option | |
| 2 | Bad Length | |
| 13 | 0 | TIMESTAMP |
| 14 | 0 | TIMESTAMP REPLY |
| 15 | 0 | INFORMATION REQUEST (Obsolete) |
| 16 | 0 | INFORMATION REPLY (Obsolete) |
| 17 | 0 | ADDRESS MASK REQUEST (Near-Obsolete) |
| 18 | 0 | ADDRESS MASK REPLY (Near-Obsolete) |
| 30 | — | Traceroute |
Данную информацию не следует учить, как и другую представленную в статьях, главное научиться понимать что это и для чего используется, остальное приходит с опытом работы. Тем более, что вся представленная информация общедоступна каждому из нас бесплатно.
Одни из наиболее часто встречающихся примеров ICMP сообщений являются Echo и Reply . По ссылке можно скачать дамп, показывающий выполнение команды ping в сторону адреса 8.8.8.8. Ниже будут представлены вырезки Echo и Reply из данных дампов.
Далеко не все типы пакетов ICMP можно встретить сегодня в современных сетях, но некоторые из них имеют важное значение для функционала маршрутизации, например, редирект — ICMP Type 5.
Данный тип используется маршрутизаторами для уведомления других устройств о том, что для данного адреса назначения в текущей канальной среде следует использовать другой маршрутизатор.
Предположим, что в одной канальной среде с конечным устройством есть два маршрутизатора Router-London и Router-Moscow . Маршрутизатор Router-Moscow является шлюзом по умолчанию для конечного устройства. Конечное устройство отправляет пакет на маршрутизатор Router-Moscow , в свою очередь маршрутизатор Router-Moscow имеет достижимость адреса на который отправил конечный хост через маршрутизатор Router-London .
Получается, что маршрутизатор Router-Moscow должен отправить пакет в тот же самый интерфейс на котором он получил изначальный пакет. Маршрутизатор Router-Moscow отправляет пакет маршрутизатору Router-London , а также отправляет сообщение ICMP Redirect конечному устройству, информируя его о том, что все следующие пакеты он должен отправлять непосредственно через маршрутизатор Router-London (имеется в виду только до сети, куда был отправлен первый пакет, все пакеты до других сетей отправляются также на шлюз по умолчанию)
Практика
Рассмотрим пример с ICMP Redirect на практике. Имеется простая схема с двумя маршрутизаторами в одной канальной среде
Вся адресация представлена на схеме. В качестве простоты эксперимента рассмотрим ситуацию когда клиент будет отправлять пинг на адрес внешнего интерфейса маршрутизатора Router-London , маршрутизатор Router-Moscow является шлюзом для клиента.
На маршрутизаторе Router-Moscow дополнительно настроен статический маршрут до сети 172.17.0.0/24 через адрес внутреннего интерфейса маршрутизатора Router-London .
Для того чтобы убедиться в правдивости моих слов предлагаю скачать дампы с двух интерфейсов маршрутизатора Router-London и Router-Moscow и посмотреть весь процесс самим.
Помните: так как все устройства находятся в общей широковещательной среде, то все пакеты отправленные на широковещательный адрес ffff.ffff.ffff будут видны в каждом из дампов.
Дамп с интерфейса gi0/0 маршрутизатора Router-Moscow Дамп с интерфейса gi0/0 маршрутизатора Router-London
По умолчанию редирект включен на устройствах cisco. Данное поведение можно отключить на интерфейсе, выполнив команду no ip redirects
P.S. вся информация представленная здесь используется исключительно в образовательных целях. Все совпадения с реальными объектами, адресами, именами и т.д. случайна и не несёт цели получить от этого выгоду или причинить кому-либо вред.
Updated: October 7, 2021