Icmp протокол порт. Что такое ICMP

ICMP (Internet Control Message Protocol - межсетевой протокол управляющих сообщений). ICMP является протоколом контрольных сообщений Структура межсетевого протокола IPv4 . Протокол ICMP используется устройствами сети для отправки управляющих сообщений и сообщений об ошибках на компьютеры и серверы. Существует несколько областей применения протокола ICMP, например, объявление об ошибках в сети, объявление о перегрузке сети и устранение неполадок.

Каждое сообщение протокола ICMP передается по сети внутри пакета IP. Пакеты IP с сообщениями ICMP маршрутизируются точно так же, как и любые другие пакеты, без приоритетов, поэтому они также могут теряться. Мало того, при большой загруженности сети они могут вызывать дополнительную загрузку маршрутизаторов. Для того, чтобы не вызывать лавины сообщения об ошибках, предусмотрели, что в случае потери пакетов IP, которые сами "несут" сообщения ICMP об ошибках, новые сообщения ICMP об ошибке рождаться не будут.

ICMP только сообщает о возникших ошибках отправителю пакета; отправитель сам должен связать ошибки с конкретными прикладными программами и предпринять действия по исправлению ошибок.

Надо отметить, что большая часть ошибок исходит от отправителя, но другие - нет. Так как ICMP сообщает об ошибках отправителю, он не может использоваться, чтобы информировать промежуточные маршрутизаторы об ошибках. Например, пакет следует по пути через маршрутизаторы М1,М2,…,Мk. Если Мk содержит некорректную информацию о маршрутах и ошибочно отправит пакет на маршрутизатор Ме, то маршрутизатор Мe может лишь сообщить об ошибке отправителю пакета. К сожалению, отправитель не отвечает за эту проблему и не может управлять некорректно ведущим себя маршрутизатором Мk. Фактически, отправитель не сможет даже определить, какой маршрутизатор вызвал эту проблему.

Почему ограничивают протокол ICMP взаимодействием только с отправителем? Потому что IP- пакет содержит поля, которые определяют только отправителя и получателя; он не содержит полного описания своего пути через сеть (кроме необычных случаев, о которых мы скажем позже).

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

Коды ICMP

Расшифровка кодов ICMP сообщений:

echo reply (0) - echo reply (echo-ответ, пинг)

destination unreachable (3) - destination unreachable/destination port unreachable (адресат недосягаем). Код 3/4 уведомляет о необходимости фрагментации сообщения, отправитель получает его, меняет свой MSS на еще более меньший.

source quench (4) - source quench (подавление источника, просьба посылать пакеты медленнее)

redirect (5) - redirect (редирект)

echo request (8) - echo request (echo-запрос, пинг)

router adver-tisement (9) - router advertisement (объявление маршрутизатора)

router solicitation(10) - router solicitation (ходатайство маршрутизатора)

time-to-live exceeded (11) - time-to-live exceeded (истечение срока жизни пакета)

IP header bad (12) - IP header bad (неправильный IP заголовок пакета)

timestamp request (13) - timestamp request (запрос значения счетчика времени)

timestamp reply (14) - timestamp reply (ответ на запрос значения счетчика времени)

information request (15) - information request (запрос информации)

information reply (16) - information reply (ответ на запрос информации)

address mask request (17) - address mask request (запрос маски сети)

address mask reply (18) - address mask reply (ответ на запрос маски сети)

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

Обычно выход во внешний мир разрешают ICMP-сообщениям 3, 8, 12, в то время как на вход принимают только 0, 3, 4, 11, 12.

PF и ICMP

ipfw и ICMP

${fwcmd} add 00300 allow icmp from any to внешний_IP in via внешний_интерфейс icmptype 0 ,3 ,4 ,11 ,12 ${fwcmd} add 00301 allow icmp from внешний_IP to any out via внешний_интерфейс icmptype 3 ,8 ,12 ${fwcmd} add 00304 allow icmp from внешний_IP to any out via внешний_интерфейс frag ${fwcmd} add 00305 deny log icmp from any to any in via внешний_интерфейс

iptables и ICMP

Правила для Правила iptables . Список возможных типов выводится по команде

# iptables -p icmp -h Valid ICMP Types: any echo-reply (pong) destination-unreachable network-unreachable host-unreachable protocol-unreachable port-unreachable fragmentation-needed source-route-failed network-unknown host-unknown network-prohibited host-prohibited TOS-network-unreachable TOS-host-unreachable communication-prohibited host-precedence-violation precedence-cutoff source-quench redirect network-redirect host-redirect TOS-network-redirect TOS-host-redirect echo-request (ping) router-advertisement router-solicitation time-exceeded (ttl-exceeded) ttl-zero-during-transit ttl-zero-during-reassembly parameter-problem ip-header-bad required-option-missing timestamp-request timestamp-reply address-mask-request address-mask-reply

Можно указать стандартный числовой код или сообщение. Пропустить все входящие ICMP-эхо-запросы (пинги).

# iptables -I INPUT -p icmp --icmp-type 8 -j ACCEPT # iptables -I INPUT -p icmp --icmp-type echo-request -j ACCEPT

Блокирует фрагменты ICMP-пакетов

Iptables -I INPUT -p icmp -f -j DROP

#!/bin/sh IPT="/sbin/iptables" $IPT -A INPUT -p icmp --icmp-type 3 -j ACCEPT # destination-unreachable 3/4 $IPT -A INPUT -p icmp --icmp-type 8 -j ACCEPT # echo request $IPT -A INPUT -p icmp --icmp-type 12 -j ACCEPT # IP header bad $IPT -A OUTPUT -p icmp --icmp-type 0 -j ACCEPT # $IPT -A OUTPUT -p icmp --icmp-type 3 -j ACCEPT # $IPT -A OUTPUT -p icmp --icmp-type 4 -j ACCEPT # $IPT -A OUTPUT -p icmp --icmp-type 11 -j ACCEPT # $IPT -A OUTPUT -p icmp --icmp-type 12 -j ACCEPT #

опция –reject-with

В отличие от цели DROP, где пакет просто отбрасывается, в данном случае отправителю будет отправлено IСМР-сообщение «Port unreachable / icmp port unreachable» («Порт недоступен»). С помощью опции –reject-with можно изменить тип ICMP-сообщения:

# iptables -A INPUT -s 1.2.3.4 -j REJECT --reject-with icmp-net-unreachable

У опции –reject-with есть следующие аргументы:

Icmp-net-unreachable - сеть недоступна; icmp-host-unreachable - узел недоступен; icmp-port-unreachable - порт недоступен; icmp-proto-unreahable - неподдерживаемый протокол; icmp-net-prohibited - сеть запрещена; icmp-host-prohibited - узел запрещен.

По умолчанию будет передано сообщение port-unreachable. Вышеперечисленные аргументы являются ICMP error messages.В дополнение к опции –reject-with TCP-пакеты можно отклонить с помощью аргумента tcp-reset, который отправляет RST-сообщения отправителю. Это наилучший с точки зрения безопасности способ, нужно обязательно использовать именно его. TCP RST пакеты используются для закрытия TCP соединений.

Протокол передачи команд и сообщений об ошибках ( ICMP - internet control message protocol, RFC-792, - 1256) выполняет различные и не только диагностические функции. При пересылке пакетов промежуточные узлы не информируются о возникших проблемах, поэтому ошибка в маршрутной таблице может восприниматься как неисправность в узле адресата и достоверно диагностироваться не будет. ICMP-протокол сообщает об ошибках в IP-дейтаграммах, но не дает информации об ошибках в самих ICMP-сообщениях. ICMP использует IP, а IP-протокол должен использовать ICMP. В случае ICMP-фрагментации сообщение об ошибке будет выдано только один раз на дейтаграмму, даже если ошибки были в нескольких фрагментах. Подводя итоги, можно сказать, что ICMP -протокол:

осуществляет передачу запросов и откликов;
контролирует время жизни дейтаграмм в системе;
реализует переадресацию пакета;
выдает сообщения о недостижимости адресата или о некорректности параметров;
формирует и пересылает временные метки;
выдает запросы и отклики для адресных масок и другую информацию.

ICMP -сообщения об ошибках никогда не выдаются:

в ответ на ICMP-сообщение об ошибке;
при мультикастинг-е или широковещательной адресации;
для фрагмента дейтаграммы (кроме первого);
для дейтаграмм, чей адрес отправителя является нулевым, широковещательным или мультикастинговым.

Эти правила призваны блокировать потоки дейтаграмм, посылаемые в отклик на мультикастинг- или широковещательные ICMP -сообщения. Особенности протокола ICMPv6 описаны в документе RFC-2463. В IPv6 на протокол ICMP возложены функции управления группами ( IGMP ).

ICMP -сообщения имеют свой формат, а схема их вложения аналогична UDP или TCP и представлена на рис. 3.1 .

Все ICMP пакеты начинаются с 8-битного поля типа ICMP и его кода (15 значений).

Рис. 3.1.

По существу, значения полей типа и кода выполняют почти ту же функцию, что и порт в ТСР и UDP -протоколах.

Код уточняет функцию ICMP -сообщения. Таблица 3.1 этих кодов приведена ниже (символом * помечены сообщения об ошибках, остальные являются запросами).

Процедура "отключение источника" (quench, поле тип ICMP=4 ) позволяет управлять потоками данных в каналах Интернет . Не справляясь с обработкой дейтаграмм, ЭВМадресат (или транзитное сетевое устройство) может послать запрос "отключить источник" отправителю, который может сократить темп посылки пакетов, например, вдвое, или вовсе прервать их посылку. Специальной команды, отменяющей прежние запреты, не существует. Если сообщения об отключении прекращаются, источник может возобновить посылку пакетов или увеличить частоту их отправки. Ниже (на рис. 3.2) представлен формат эхозапроса ( ping ) и отклика для протокола ICMP .

Поля идентификатор (обычно это идентификатор процесса) и номер по порядку (увеличивается на 1 при посылке каждого пакета) служат для того, чтобы отправитель мог связать в пары запросы и отклики.

Поле тип определяет, является ли этот пакет запросом (8) или откликом (0). Поле контрольная сумма представляет собой 16-разрядное дополнение по модулю 1 контрольной суммы всего ICMP -сообщения, начиная с поля тип . Поле данные служит для записи информации, возвращаемой отправителю. При выполнении процедуры ping эхозапрос с временной меткой в поле данные посылается адресату. Если адресат активен, он принимает IP -пакет, меняет адрес отправителя и получателя местами и посылает его обратно. ЭВМ-отправитель, восприняв этот отклик, может сравнить временную метку, записанную им в пакет, с текущим показанием внутренних часов и определить время распространения пакета ( RTT - round trip time ). Размер поля данные не регламентирован и определяется предельным размером IP -пакета.

Таблица 3.1. Типы и коды ICMP-сообщений

ICMP-сообщение		описание сообщения
Тип	код	описание сообщения
0		Эхо-ответ (ping-отклик)
3		Адресат недостижим
	0	* Сеть недостижима
	1	* ЭВМ недостижима
	2	* Протокол недоступен
	3	* Порт недоступен
	4	* Необходима фрагментация сообщения (установлен флаг DF)
	5	* Маршрутизация отправителя нереализуема
	6	* Сеть места назначения неизвестна
	7	* ЭВМ места назначения неизвестна
	8	* Исходная ЭВМ изолирована (устарело)
	9	* Связь с сетью места назначения административно запрещена
	10	* Связь с ЭВМ места назначения административно запрещена
	11	* Сеть не доступна для данного вида сервиса (TOS)
	12	* ЭВМ не доступна для данного вида сервиса (TOS)
	13	* Связь административно запрещена с помощью фильтра
	14	* Нарушение старшинства ЭВМ
	15	* Дискриминация по старшинству
4	0	* Отключение источника при переполнении очереди (quench)
5		Переадресовать (изменить маршрут)
	0	Переадресовать дейтаграмму в сеть (устарело)
	1	Переадресовать дейтаграмму на ЭВМ
	2	Переадресовать дейтаграмму для типа сервиса (ToS) и сети
	3	Переадресовать дейтаграмму для типа сервиса и ЭВМ
8	0	Эхо запроса (ping-запрос)
9	0	Объявление маршрутизатора
10	0	Запрос маршрутизатора
11		Для дейтаграммы время жизни истекло (ttl=0):
	0	*при передаче
	1	* тайм-аут при сборке (случай фрагментации)
12		* Проблема с параметрами дейтаграммы
	0	* Ошибка в IP-заголовке
	1	* Отсутствует необходимая опция
13		Запрос временной метки
14		Временная метка-отклик
15		Запрос информации (устарел)
16		Информационный отклик (устарел)
17		Запрос адресной маски
18		Отклик на запрос адресной маски

Рис. 3.2.

Рис. 3.2a.

Так как в пакете ICMP нет поля порт , то при запуске нескольких процессов PING одновременно может возникнуть проблема с тем, какому из процессов следует передать тот или иной отклик. Для преодоления этой неопределенности следует использовать уникальные значения полей идентификатор .

Время распространения ICMP -запроса, вообще говоря, не равно времени распространения отклика (ситуация с очередями, например, в маршрутизаторах может быть разной). Это связано не только с возможными изменениями в канале. В общем случае маршруты их движения могут быть различными. Те же запросы используются при выполнении процедуры Traceroute .

Эта процедура позволяет не только диагностировать, но и оптимизировать маршрут . Например, команда traceroute cernvm.cern.ch , выданная в ЭВМ SUN (ИТЭФ), может отобразить на экране (в скобках указаны IP -адреса узлов и значения времени жизни дейтаграмм, значения RTT приводится в миллисекундах) (таблица 3.1.1.):

Таблица 3.1.1.

traceroute to crnvma cern ch		(128 141 2 4) 30 hops max, 40 byte packets
1	itep-fddi-bbone	(193.124.224.50) 3 ms 2 ms 3 ms
2	msu - tower .moscow.ru.radio- msu .net	(193.124.137.13) 3 ms 3 ms 3 ms
3	npi- msu .moscow.ru.radio- msu .net	(193.124.137.9) 27 ms 3 ms 9 ms
4	desy.hamburg.de.radio- msu .net	(193.124.137.6) 556 ms 535 ms 535 ms
5	* 188.1.133.56	(188.1.133.56) 637ms 670ms
6	duesseldorf2.empb.net	(193.172.4.12) 740ms(ttl=59!) 839ms(ttl=59!) 2066ms(ttl=59!)
7	bern3.empb.net	(193.172.4.30) 2135ms (ttl=58!) 1644ms (ttl=58!) 1409ms (ttl=58!)
8	cernh3.euro-hep.net	(193.172.24.10) 1808ms 1508ms 1830ms
9	cgate1.cern.ch	(192.65.185.1) 1116ms 1270ms 1278ms
10	crnvma.cern.ch	(128.141.2.4) 1132ms 1362ms 1524ms

Отсюда видно, что наиболее узкими участками маршрута (на момент выполнения процедуры) являются Гамбург-Дюссельдорф-Берн-CERN. Следует иметь в виду, что канал МГУ-Гамбург был спутниковым и 500мс задержки здесь вносит удвоенное время распространения сигнала до спутника и обратно. Участок Гамбург-Дюссельдорф (X.25, квота 256кбит/с) был общим для потока данных из Германии в США. Передача IP поверх X.25 также снижает эффективную широкополосность канала. Остальные связи обладают недостаточной пропускной способностью. Программа ping показывает для данных участков в часы пик высокую долю потерянных пакетов. Таким образом, имея карту связей и используя указанные процедуры, вы можете успешно диагностировать ситуацию в сети. Продвинутые же программисты могут легко написать свои диагностические программы, базирующиеся на ICMP , как для локальной сети, так и для "окрестного" Интернет .

Когда маршрутизатор не может доставить дейтаграмму по месту назначения, он посылает отправителю сообщение "адресат недостижим" ( destination unreachable). Формат такого сообщения показан ниже (на рис. 3.3).

Рис. 3.3. Формат ICMP-сообщения "адресат недостижим"

Поле код содержит целое число , проясняющее положение дел. Перечень кодов таких сообщений помещен в таблице 3.1 . Поле MTU на следующем этапе характеризует максимальную длину пакетов на очередном шаге пересылки. Эта информация ( MTU ) позволяет выбрать оптимальный размер пакета .

Так как в сообщении содержится Интернет -заголовок и первые 64-бита дейтаграммы, легко понять, какой адрес оказался недостижим. Этот тип ICMP -сообщения посылается и в случае, когда дейтаграмма имеет флаг DF=1 ("не фрагментировать"), а фрагментация необходима. В поле код в этом случае будет записано число 4.

Если буфер приема сообщения переполнен, ЭВМ посылает сообщение типа 4.

Так как собственные часы различных ЭВМ имеют свое представление о времени, протокол ICMP , среди прочего, служит для синхронизации работы различных узлов, если это требуется (запросы временных меток). Протокол синхронизации NTP ( network time protocol ) описан в RFC-1119.

Когда дейтаграммы поступают слишком часто и принимающая сторона не справляется с этим потоком, отправителю может быть послано сообщение с требованием резко сократить информационный поток (quenchзапрос). Снижение потока должно продолжаться до тех пор, пока не прекратятся quenchзапросы. Такое сообщение имеет формат, показанный на рис. 3.4 .

Рис. 3.4.

В Internet таблицы маршрутизации остаются без изменений достаточно долгое время, но иногда они все же меняются. Если маршрутизатор обнаружит, что ЭВМ использует неоптимальный маршрут , он может послать ей ICMP - запрос переадресации. При этом следует учитывать, что этой возможностью может воспользоваться и хакер . Формат такого сообщения отображен на рисунке 3.5 .

Рис. 3.5.

Поле Internet-адрес маршрутизатора содержит адрес маршрутизатора, который ЭВМ должна использовать, чтобы посланная дейтаграмма достигла места назначения, указанного в ее заголовке. В поле internet -заголовок кроме самого заголовка лежит 64 первых бита дейтаграммы, вызвавшей это сообщение. Поле код специфицирует то, как нужно интерпретировать адрес места назначения (см. табл. 3.1).

Команды переадресации маршрутизатор посылает только ЭВМ и никогда другим маршрутизаторам. Рассмотрим конкретный пример. Пусть некоторая ЭВМ на основе своей маршрутной таблицы посылает пакет маршрутизатору M1. Он, просмотрев свою маршрутную таблицу, находит, что пакет следует переслать маршрутизатору M2. Причем выясняется, что пакет из M1 в M2 следует послать через тот же интерфейс , через который он попал в M1. Это означает, что M2 доступен и непосредственно для ЭВМ-отправителя. В такой ситуации M1 посылает ICMP - запрос переадресации ЭВМ-отправителю указанного пакета с тем, чтобы она внесла соответствующие коррективы в свою маршрутную таблицу (либо чтобы администратор поменял IPадрес или маску ЭВМ).

Маршрутная таблица может загружаться из файла, формироваться менеджером сети, но может создаваться и в результате запросов и объявлений, посылаемых маршрутизаторами. После загрузки системы маршрутизатор посылает широковещательный запрос . Один или более маршрутизаторов посылают в ответ сообщения об имеющейся маршрутной информации. Кроме того, маршрутизаторы периодически (раз в 450600 сек.) широковещательно объявляют о своих маршрутах, что позволяет другим маршрутизаторам скорректировать свои маршрутные таблицы. В RFC-1256 описаны форматы ICMP -сообщений такого рода (см. рис. 3.6). Из--за своей уязвимости данная технология в последнее время практически не используется.

Рис. 3.6.

Поле число адресов характеризует количество адресных записей в сообщении. Поле длина адреса содержит число 32-битных слов, необходимых для описания адреса маршрутизатора. Поле время жизни предназначено для записи продолжительности жизни объявленных маршрутов (адресов) в секундах. По умолчанию время жизни равно 30 мин. Поля уровень приоритета представляют собой меру приоритетности маршрута по отношению к другим маршрутам данной подсети. Чем больше этот код, тем выше приоритет. Маршрут по умолчанию имеет уровень приоритета 0. Формат запроса маршрутной информации (8 октетов,

Статья отвечает на вопрос насколько опасно блокировать ICMP трафик.

Многие сетевые администраторы считают, что протокол межсетевых управляющих сообщений (Internet Control Message Protocol (ICMP) представляет собой угрозу безопасности и поэтому должен всегда блокироваться на . Это правда, что протокол имеет некоторые связанные с этим проблемы безопасности, и что часть запросов должна быть заблокирована. Но это не повод блокировать весь ICMP-трафик!

ICMP-трафик имеет много важных функций; какие то из них полезны для устранения неполадок, другие же необходимы для правильной работы сети. Ниже приведены сведения о некоторых важных составляющих ICMP протокола, о которых вы должны знать. Следует подумать над тем, как оптимальным образом пропускать их через вашу сеть.

Echo запрос и and Echo ответ

IPv4 – Echo запрос (Type8, Code0) и Echo ответ (Type0, Code0)
IPv6 – Echo запрос (Type128, Code0) and Echo ответ (Type129, Code0)

Мы все хорошо знаем, что ping, - один из первых инструментов для поиска и устранения неполадок. Да, если вы включите на своем оборудование обработку ICMP-пакетов, то это значит, что ваш хост теперь доступен для обнаружения, но разве ваш уже не слушает порт 80, и не отправляет ответы на клиентские запросы? Конечно, заблокируйте ещё и эти запросы, если вы действительно хотите, чтобы на границе сети была ваша DMZ. Но блокируя ICMP трафик внутри вашей сети, не усилите защиту, напротив получите систему с излишне сложным процессом поиска и устранения неполадок («Проверьте пожалуйста отзывается ли шлюз на сетевые запросы?», «Нет, но это меня ничуть не расстраивает, потому что мне это ничего не скажет! »).

Помните, также можете разрешить прохождение запросов в определенном направлении; например, настроить оборудование так, чтобы Echo запросы из вашей сети проходили в сеть Интернет и Echo ответы из Интернета в вашу сеть, но не наоборот.

Необходима фрагментация пакета (IPv4) / Пакет слишком большой (IPv6)

IPv4 – (Type3, Code4)
IPv6 – (Type2, Code0)

Данные компоненты протокола ICMP очень важны, так как являются важным компонентом в Path MTU Discovery (PMTUD), который является неотъемлемой частью протокола TCP. Позволяет двум хостам корректировать значение максимального размера сегмента TCP (MSS) до значения, которое будет соответствовать наименьшему MTU по пути связей между двумя адресатами. Если на пути следования пакетов будет узел с меньшим Maximum Transmission Unit, чем у отправителя или получателя, и у них не будет средств для обнаружения данной коллизии, то трафик будет незаметно отбрасывается. И вы не будете понимать что происходит с каналом связи; другими словами, «для вас наступят веселые деньки».

Don’t Fragment – ICMP не пройдет!

Передача IPv4-пакетов с установленным битом Don’t Fragment (большинство из них!) или IPv6-пакетов (помним, что в IPv6 нет фрагментации маршрутизаторами), которые слишком велики для передачи через интерфейс, приведёт к тому, что маршрутизатор отбросит пакет и сформирует ответ источнику передачи с следующими ICMP-ошибками: Требуется Фрагментация (Fragmentation Required ), либо Пакет Слишком Большой (Packet Too Big). Если ответы с этими ошибками не смогут вернуться к отправителю, то он будет интерпретировать отсутствие подтверждающих ответов о доставке пакетов ACK (Acknowledge ) от получателя в качестве перегрузки / потери и источником для повторной передачи пакетов, которые также будут отбрасываться.

Сложно выявить причину подобной проблемы и быстро устранить, процесс обмена TCP-рукопожатиями (TCP-handshake) работает нормально, поскольку в нем задействованы небольшие пакеты, но как только происходит массовая передача данных сеанс передачи зависает, так как источник передачи не получает сообщения об ошибках.

Исследование пути доставки пакетов

RFC 4821 был разработан для того, чтобы помочь участникам передачи трафика в сети обойти эту проблему, используя исследование пути распространения пакетов (Path MTU Discovery (PLPMTUD) . Стандарт позволяет обнаружить максимальный объём данных (Maximum Transmission Unit (MTU) , который может быть передан протоколом за одну итерацию, путем постепенного увеличения максимального размера полезного блока данных (Maximum Segment Size (MSS) , для того чтобы найти максимально возможную величину пакета без его фрагментации на пути следования от передатчика к приемнику. Данный функционал уменьшает зависимость от своевременного получения ответов с ошибками по протоколу межсетевых управляющих сообщений (Internet Control Message Protocol (ICMP) и доступен в большинстве сетевых стеков устройств и клиентских операционных систем. К сожалению, он не так эффективен, как непосредственное получение данных о максимальном возможном размере передаваемых пакетов. Пожалуйста, позвольте этим сообщениям протокола ICMP возвращаться к источнику передачи, хорошо?

Превышение времени передачи пакетов

IPv4 – (Type11, Code0)
IPv6 – (Type3, Code0)

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

Отправляет пакет с временем жизни пакета данных для протокола IP (Time to live (TTL) равным 1 , чтобы первый маршрутизатор отправил сообщение с ошибкой (включая собственный IP-адрес) о превышении времени жизни пакета. Затем отправляет пакет с TTL 2 и так далее. Данная процедура необходима для того, чтобы обнаружить каждый узел на пути следования пакетов.

NDP and SLAAC (IPv6)

Router Solicitation (RS) (Type133, Code0)
Router Advertisement (RA) (Type134, Code0)
Neighbour Solicitation (NS) (Type135, Code0)
Neighbour Advertisement (NA) (Type136, Code0)
Redirect (Type137, Code0)

В то время как IPv4 использовал протокол разрешения адресов (ARP) для сопоставления 2 и 3 уровней сетевой модели OSI, IPv6 использует другой подход в виде протокола обнаружения соседей (NDP). NDP предоставляет множество функций, включая обнаружение маршрутизатора, обнаружение префикса, разрешение адреса и многое другое. В дополнение к NDP, Автоконфигурация (StateLess Address AutoConfiguration (SLAAC) позволяет динамически настраивать хост в сети, аналогично концепции протокола динамической настройки узла (Dynamic Host Configuration Protocol (DHCP) (хотя DHCPv6 предназначается для более тонкого управления).

Эти пять типов ICMP сообщений не должны блокироваться внутри вашей сети (не учитываем внешний периметр), чтобы протокол передачи данных IP функционировал правильно.

Нумерация типов ICMP

Протокол межсетевых управляющих сообщений (ICMP) содержит много сообщений, которые идентифицируются полем «тип».

Тип	Наименование	Спецификация
	Echo Reply
1	Unassigned
2	Unassigned
3	Destination Unreachable
4	Source Quench (Deprecated)
5	Redirect
6	Alternate Host Address (Deprecated)
7	Unassigned
8	Echo
9	Router Advertisement
10	Router Solicitation
11	Time Exceeded
12	Parameter Problem
13	Timestamp
14	Timestamp Reply
15	Information Request (Deprecated)
16	Information Reply (Deprecated)
17	Address Mask Request (Deprecated)
18	Address Mask Reply (Deprecated)
19	Reserved (for Security)	Solo
20-29	Reserved (for Robustness Experiment)	ZSu
30	Traceroute (Deprecated)
31	Datagram Conversion Error (Deprecated)
32	Mobile Host Redirect (Deprecated)	David_Johnson
33	IPv6 Where-Are-You (Deprecated)
34	IPv6 I-Am-Here (Deprecated)
35	Mobile Registration Request (Deprecated)
36	Mobile Registration Reply (Deprecated)
37	Domain Name Request (Deprecated)
38	Domain Name Reply (Deprecated)
39	SKIP (Deprecated)
40	Photuris
41	ICMP messages utilized by experimental mobility protocols such as Seamoby
42	Extended Echo Request
43	Extended Echo Reply
44-252	Unassigned
253	RFC3692-style Experiment 1
254	RFC3692-style Experiment 2
255	Reserved

Пара слов об ограничении скорости

Хотя ICMP-сообщения, подобные тем, которые описаны в статье, могут быть очень полезными, помните, что генерация всех этих сообщений занимает процессорное время на ваших маршрутизаторах и генерирует трафик. Вы действительно ожидаете, что вы получите 1000 пингов в секунду через ваш брандмауэр в обычной ситуации? Будет ли это считаться нормальным трафиком? Вероятно, нет. Ограничивайте пропускную способность сети для этих типов ICMP трафика, как вы считаете нужным; этот шаг может помочь вам в защите вашей сети.

Хотя IPv4 не является надежным протоколом, на самом деле он предусматривает сообщения, которые будут отправлены в случае определенных ошибок. Эти сообщения отправляются, используя службы Протокола Контрольных Сообщений Интернета (протокол ICMP ). Цель этих сообщений состоит в том, чтобы обеспечить обратную связь о проблемах, связанных с обработкой пакетов IP при определенных условиях, но не для того, чтобы сделать IP надежным. Сообщения ICMP не являются обязательными и часто не разрешены из соображений безопасности.

ICMP является протоколом обмена сообщениями стека TCP/IP . ICMP обеспечивает контрольные сообщения и сообщения об ошибках и используется утилитами ping и traceroute . Хотя ICMP использует базовую поддержку IP, как высокоуровневый протокол, он фактически является отдельным протоколом Уровня 3 из стека TCP/IP.

Типы сообщений ICMP - и причины, почему они отправляются, - обширны. Мы обсудим некоторые из более распространенных сообщений.

Сообщения ICMP, которые могут быть отправлены, включают:

Подтверждение узла
Превышение Лимита Времени
Перенаправление маршрута
Подавление Источника

Подтверждение узла

Эхо-Сообщение ICMP может использоваться, чтобы определить, является ли узел рабочим. Локальный узел отправляет Эхо-запрос ICMP хосту. Хост, получающий эхо-сообщение, отвечает Эхо-ответом ICMP, как показано на рисунке. Это использование Эхо-сообщений ICMP является основой утилиты ping.

Недостижимое Место назначения или Служба

Недостижимое Место назначения ICMP может использоваться, чтобы уведомить узел, что место назначения или служба недостижимы. Когда узел или шлюз получают пакет, который не удается доставить, он может отправить ICMP пакет Недостижимости Места назначения хосту, отправившему исходный пакет. Пакет Недостижимости Места назначения будет содержать коды, которые указывают, почему пакет не мог быть доставлен.

Среди Кодов Недостижимости Места назначения можно назвать:

0 = недостижимая сеть

1 = недостижимый узел

2 = недостижимый протокол

3 = недостижимый порт

Коды недостижимая сеть и недостижимый узел являются ответами от маршрутизатора, когда тот не может передать пакет. Если маршрутизатор получает пакет, для которого у него нет маршрута, он может ответить Недостижимым Местом назначения ICMP с кодом = 0, указывая на недостижимую сеть. Если маршрутизатор получает пакет, для которого он имеет присоединенный маршрут, но неспособен доставить пакет узлу в подключенной сети, маршрутизатор может ответить Недостижимым Местом назначения ICMP с кодом = 1, указывая, что сеть известна, но узел недостижим.

Коды 2 и 3 (недостижимый протокол и недостижимый порт ) используются конечным хостом, чтобы указать, что сегмент TCP или дейтаграмма UDP, содержавшаяся в пакете, не могли быть доставлены службе верхнего уровня.

Когда конечный хост получает пакет PDU Уровня 4, который должен быть доставлен недоступной службе, хост может ответить узлу-отправителю ICMP сообщением Недостижимости Места назначения с кодом = 2 или с кодом = 3, указывая, что служба не доступна. Служба, вероятно, является недоступной, поскольку не запущен соответствующий демон, который предоставляет данную службу, либо потому что безопасность узла не позволяет доступ к службе.

Превышенное время

ICMP Сообщение Превышенного Времени используется маршрутизатором, чтобы указать, что пакет не может быть передан, поскольку TTL пакета истекло. Если маршрутизатор получает пакет и уменьшает поле TTL в пакете до нуля, он отбрасывает пакет. Маршрутизатор может также отправить ICMP Сообщение Превышенного Времени исходному узлу, чтобы сообщить ему причину, по которой пакет был отброшен.

Перенаправление маршрута

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

Подавление Источника

ICMP Сообщение Подавления Источника может использоваться, чтобы сообщить источнику временно прекратить отправлять пакеты. Если у маршрутизатора не будет достаточного количества буферного пространства, чтобы получать входящие пакеты, то маршрутизатор отбросит пакеты. Если маршрутизатору приходится это делать, он может также передать ICMP сообщение Подавления Источника узлам-отправителям для каждого сообщения, которое он отбрасывает.

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

Когда хост получает ICMP сообщение Подавления Источника, он сообщает об этом Транспортному уровню . Далее хост-отправитель может использовать механизмы управления потоком TCP, чтобы скорректировать передачу.

effort ), которая доставляет дейтаграмму от ее первоначального источника до ее конечного пункта назначения. Однако он имеет два дефекта: отсутствие контроля ошибок и отсутствие механизмов помощи в доставке.

Протокол IP не имеет механизма, сообщающего об ошибке или исправляющего ее. Протоколу IP также недостает ICMP - механизма запросов управления от хоста. Хост иногда должен определять, исправен ли маршрутизатор или другой хост . И иногда сетевой менеджер нуждается в информации от другого хоста или маршрутизатора.

Протокол управления сообщениями Интернета ( ICMP – Internet Control Message Protocol ) был разработан для компенсации этих вышеупомянутых дефектов. Это - спутник протокола IP . ICMP - протокол сетевого уровня. Однако он сам не передает сообщения непосредственно данных канальному уровню. Эти сообщения первыми инкапсулируются в дейтаграммы IP перед переходом к более низкому уровню (рис. 6.1).

Рис. 6.1.

Значение поля протокола в дейтаграмме IP - это "1", оно указывает, что данные IP - это ICMP -сообщение.

Типы сообщений

ICMP -сообщения разделены на две широкие категории: отчет об ошибке сообщения и запрос , как это показано на рис. 6.2.

Рис. 6.2.

Сообщение об ошибке переносит данные о проблемах, возникающих при обмене сообщениями, с которыми маршрутизатор или хост ( пункт назначения) могут столкнуться, когда они обрабатывают пакет IP .

Сообщения запроса помогают хосту или сетевому менеджеру получить заданную информацию от маршрутизатора или другого хоста. Например, узлы могут обнаружить их соседей. Также хосты могут обнаружить и узнать о маршрутизаторах на их сети, и маршрутизаторы могут помочь узлу переадресовывать его сообщения. Таблица 6.1. перечисляет ICMP -сообщения в каждой категории.

Таблица 6.1. ICMP сообщения

Категория	Тип	Сообщение
Сообщения отчета об ошибках	3	Конечный пункт не достижим
	4	подавление источника
	11	Время истекло
	12	Проблемы параметров
	5	Переназначение
	8 или 0	Эхо запрос и ответ
	13 или 14	Метка времени запрос и ответ
	17 или 18	Маска адреса запрос и ответ
	10 или 9	Маршрутизатор затребование и извещение

Формат сообщения

ICMP -сообщение имеет 8-байтовый заголовок и раздел данных переменного размера. Хотя общий формат заголовка различен для каждого типа сообщения, первые 4 байта - общие для всех. Как показывает рис. 6.3. , первое поле , ICMP , определяет тип сообщения . Поле кода определяет основание для конкретного типа сообщения. Последнее общее поле – это поле контрольной суммы. Остальная часть заголовка задана для каждого типа сообщения.

Рис. 6.3.

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

Сообщения ошибки

Одна из главных обязанностей ICMP состоит в том, чтобы известить об ошибках. Хотя технологии передачи сегодня предоставляют для передачи все более и более достоверные среды, ошибки все еще существуют и должны быть обработаны. IP , как обсуждалось ранее, является ненадежным протоколом. ICMP был частично предназначен для компенсирования этого недостатка. Однако ICMP не исправляет ошибки, он просто извещает о них. Исправление ошибки оставляют протоколам высокого уровня. Сообщения об ошибках всегда посылают первоначальному источнику, потому что единственная информация , доступная в дейтаграмме о маршруте - адреса IP пункта назначения и источник. ICMP использует исходный адрес IP , чтобы послать сообщение об ошибках источнику дейтаграммы. Обрабатываются пять типов ошибок