Протокол ICMP

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

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

Протокол ICMP выполняет следующие основные функции:

обмен тестовыми сообщениями для выяснения наличия и активности уз­лов сети;

анализ достижимости узлов и сброс пакетов, направленных к недостижи­мым узлам;

изменение маршрутов (Redirect);

уничтожение пакетов с истекшим временем жизни (Time-To-Live);

синхронизация времени в узлах сети;

управление трафиком (регулирование частоты отправки пакетов).

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

ICMP-сообщения бывают двух видов: сообщение-запрос и сообщение об ошибке. Сообщение об ошибке тесно связано с породившей его дейтаграм­мой и всегда содержит заголовок этой IP-дейтаграммы и первые 64 бит ее данных. Это необходимо для того, чтобы узел-источник смог более точно проанализировать причину ошибки, так как все прикладные протоколы стека TCP/IP содержат наиболее важную информацию для анализа в первых 8 байт своего сообщения. Сообщения-запросы передают информацию об определен­ной сети и об определенном компьютере или их используют для диагностичес­ких целей.

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

Правило 1: потеря пакета с ICMP-сообщением никогда не генерирует ново­го ICMP-сообщения.

Правило 2: сообщения об ошибке никогда не генерируются в ответ на IP- дейтаграммы с широковещательными или групповыми адресами, чтобы не вызвать полную перегрузку сети - широковещательный шторм (broadcast storm ).

Правило 3 : при повреждении фрагментированной дейтаграммы, 1СМР-со- общение отправляют только после первого поврежденного фрагмента (так как источник все равно повторит передачу всей дейтаграммы целиком).

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

Несмотря на то, что сообщения ICMP инкапсулируются и посылаются, ис­пользуя IP, ICMP не считают протоколом более высокого уровня - он является

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

Формат ICMP-пакетов. Хотя каждое сообщение ICMP имеет свой соб­ственный формат, все они начинаются с трех одинаковых полей: 8-битового целочисленного поля «Тип», идентифицирующего сообщение, 8-битового поля «Код», обеспечивающего более точную информацию о типе сообщения, и 16­битового поля «Контрольная сумма» (рис. 5.30). Помимо того, сообщения ICMP, сообщающие об ошибках, всегда включают заголовок и первые 64 бит данных дейтаграммы, вызвавшей ошибку. Это необходимо для того, чтобы узел-от­правитель смог более точно проанализировать причину ошибки, так как все протоколы прикладного уровня стека TCP/IP содержат наиболее важную ин­формацию для анализа в первых 64 бит своих сообщений.

Сетевые программы распознают ICMP-сообщения по двум признакам: зна­чению поля «Тип» и значению поля «Код». Контрольная сумма вычисляется не только для ICMP-заголовка, но и для всего сообщения.

Таблица 5.12. Типы сообщений ICMP

Типы сообщений ICMP представлены в табл. 5.12. Рассмотрим каждое из этих сообщений и его формат подробнее.

Тестирование достижимости места назначения. Протоколы TCP/IP обеспечивают средства, помогающие сетевым администраторам или пользо­вателям идентифицировать проблемы в сети. Пользователь в качестве одного из широко используемых средств отладки применяют команду, которая вызы­вает сообщения ICMP запроса эха и ответа эха. Компьютер или маршрутиза­тор посылает сообщение запроса эха указанному месту назначения. Любая машина, получившая запрос эха, генерирует ответ на эхо и возвращает его пер­воначальному отправителю. Этот запрос содержит необязательную область данных; ответ содержит копию данных, посланных в запросе. Запрос эха и свя­занный с ним ответ можно использовать для проверки достижимости назначе­ния и его способности отвечать на запросы. Так как и запрос эха, и ответ на него передаются в IP-дейтаграммах, успешный прием ответа свидетельству­ет о работоспособности основных частей транспортной системы. Во-первых, программное обеспечение IP на машине источника выполнило маршрутиза­цию дейтаграммы. Во-вторых, промежуточные маршрутизаторы между ис­точником и получателем работоспособны и корректно маршрутизируют дей­таграммы. В-третьих, машина получателя работает (по крайней мере, она обрабатывает прерывания) и программное обеспечение, как IP, так и ICMP, выполняет свои функции. И, наконец, таблицы маршрутов в маршрутизаторах на всем обратном пути корректны.

Во многих системах команда, которую пользователи вызывают для посыл­ки запроса эха ICMP, называется ping . Усложненные версии этой программы посылают серии запросов эха ICMP, принимают ответы и выдают статистику о потерях дейтаграмм. Они позволяют пользователю указывать длину посы­лаемых данных и интервалы времени между запросами. Менее сложные вер­сии просто посылают запрос эха ICMP и ждут ответа.

Формат сообщения запроса эха и ответа эха. Средства для тестирова­ния достижимости узлов сети представляют собой очень простой эхо-прото­кол, включающий обмен двумя типами сообщений: эхо-запрос и эхо-ответ. Ком­пьютер или маршрутизатор посылают по интерсети эхо-запрос, в котором указывают IP-адрес узла, достижимость которого нужно проверить. Узел, по­лучающий эхо-запрос, формирует и отправляет эхо-ответ и возвращает сооб­щение узлу - отправителю запроса. В запросе могут содержаться некоторые данные, которые должны быть возвращены в ответе.

Рис. 5.30 иллюстрирует формат сообщений запроса эха и ответа на запрос эха. Поле «Необязательные данные» имеет переменную длину и содержит дан­ные, которые надо вернуть отправителю. Ответ на эхо всегда возвращает те же самые данные, что были получены им в запросе. Поля «Идентификатор» и «Последовательный номер» отправитель использует для проверки соответствия ответов запросам. Значение поля «Тип» определяет, является ли сообщение запросом (8) или ответом (0).

Сообщения о недостижимости назначения. Когда маршрутизатор не может доставить IP-дейтаграмму, он посылает сообщение «назначение недо­стижимо» первоначальному отправителю, используя формат, приведенный на рис. 5.31. Поле «Код» в сообщении о недостижимости назначения содержит целое число, которое описывает причину. Возможные значения представлены в табл. 5.13.

Таблица 5.13. Коды сообщений о недостижимости

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

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

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

Управление потоком дейтаграмм и переполнение сети. Так как IP- протокол не устанавливает соединения, то маршрутизаторы не могут резерви­ровать память или коммуникационные ресурсы до получения дейтаграмм. В результате, трафик может вызвать перегрузку маршрутизаторов, ситуацию, на­зываемую переполнением сети (congestion). Переполнение сети происходит по двум совершенно разным причинам. Во-первых, высокоскоростной компью­тер может генерировать трафик быстрее, чем сеть может передавать его. На­пример, представим суперкомпьютер, генерирующий межсетевой трафик. Дей­таграммам, посылаемым им, может потребоваться передача, в конечном счете, по медленной глобальной сети (WAN), хотя сам суперкомпьютер может быть присоединен к высокоскоростной LAN. Переполнение будет возникать в мар­шрутизаторе, присоединенном к глобальной сети, так как дейтаграммы будут прибывать быстрее, чем их можно послать. Во-вторых, если большому числу компьютеров одновременно нужно посылать дейтаграммы через один марш­рутизатор, этот маршрутизатор может оказаться переполненным, хотя ни один источник в отдельности не вызывает эту проблему.

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

Сообщение о подавлении источника требует от источника уменьшить ско­рость передачи дейтаграмм. Обычно переполненные маршрутизаторы посы­лают по одному сообщению о подавлении источника на каждую удаляемую дейтаграмму или используют более сложные технологии выхода из переполне­ния. Формат подавления источника представлен на рис. S.32. Помимо обыч­ных полей ICMP «Тип», «Код» и «Контрольная сумма» и неиспользуемого 32-битового поля, сообщения о подавлении источника имеют поле, содержащее

префикс дейтаграммы. Как и в других сообщениях об ошибках ICMP поле префикса дейтаграммы содержит префикс дейтаграммы, вызвавшей этот зап­рос подавления источника.

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

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

При изменении топологии сети таблицы маршрутизации в маршрутизаторе или компьютере могут стать некорректными. Изменение может быть времен­ным (например, нужно заменить неисправное оборудование) или постоянным (например, когда в межсетевое взаимодействие включается новая сеть). Мар­шрутизаторы периодически обмениваются информацией о маршрутизации, чтобы отслеживать изменения в сети и своевременно менять маршруты. Для корректировки поведения компьютеров маршрутизатор может использовать сообщение протокола ICMP, называемое «перенаправлением» (Redirect), зап­рашивающее изменение маршрута в таблице маршрутизации компьютера.

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

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

Сообщения о перенаправлении, тем не менее, не решают проблему распро­странения информации о маршрутах полностью, так как они предназначены только для взаимодействия между маршрутизатором и компьютером в одной физической сети. Каждое сообщение о перенаправлении содержит 32-битовое поле «IP-адрес маршрутизатора» и поле «Префикс дейтаграммы», как это по­казано на рис. 5.33.

Поле «Межсетевой адрес маршрутизатора» содержит IP-адрес маршрути­затора, который должен использовать компьютер при отправлении дейтаграм­мы к назначению, указанному в заголовке дейтаграммы. Поле «Префикс дей­таграммы» содержит заголовок IP и следующие 8 байт дейтаграммы, которая привела к появлению этого сообщения. Поэтому компьютер, принимающий сообщение о перенаправлении ICMP, должен выделить адрес назначения дей­таграммы из префикса дейтаграммы. Поле «Код» в сообщении о перенаправ­лении ICMP более конкретно указывает, как интерпретировать адрес назначе­ния, при этом значения имеют следующий смысл: 0 - перенаправление дейтаграмм для этой сети (устарело), 1 - перенаправление дейтаграмм для этого компьютера, 2 - перенаправление дейтаграмм для этого типа сервиса и сети, 3 - перенаправление дейтаграмм для этого типа сервиса и компьютера. Напомним, что каждый заголовок IP указывает тип сервиса, используемого при маршрутизации. Как правило, маршрутизаторы посылают запросы пере­назначения ICMP только на компьютеры, а не на другие маршрутизаторы.

Изменение маршрута является одной из наиболее интересных функций про­токола ICMP - по существу, это один из механизмов автоматической оптими­зации доставки пакетов и адаптации сетей TCP/IP к изменениям топологии.

Запросы «Информация о маршрутизаторах» (типы 9 и 10).

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

Существует 2 типа сообщений маршрутизаторов:

9 - информация о маршрутизации;

10-регистрация маршрутизатора.

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

Формат сообщения «Информация о маршрутизации» (тип 9) описан в RFC 1256 (рис. 5.34).

В одном ICMP-сообщении может содержаться описание нескольких адре­сов, количество которых указано в поле «Количество адресов». Поле «Размер адреса» задает длину адреса в 32-битовых словах. В настоящее время «Длина поля адреса» всегда равна 2.

Поле «Время существования» задает интервал времени, в течение которо­го информация еще не устарела. Как правило, это 1800 с.

Поле «Приоритет» указывает, какой из адресов следует использовать пер­вым и более интенсивно. Как правило, чем больше значение поля, тем выше приоритет. Маршрутизаторы передают информационные сообщения широко­вещательно через случайные интервалы времени. Обычно через 450...600 с. Поле «Время существования» можно использовать для уведомления, что дан­ный маршрутизатор выключается. При этом содержимое данного поля уста­навливается равным 0.

Формат сообщения «Регистрация» (тип 10) представлен на рис. 5.35.

Запрос «Регистрация» передается 3 раза с интервалом 3 с при запуске мар­шрутизатора и продолжает (при необходимости) передаваться, пока маршру­тизатор не получит информационного сообщения с нужной маршрутной инфор­мацией.

Обнаружение циклических или слишком длинных путей. Как было от­мечено выше для защиты Интернета от перегрузок каждая дейтаграмма име­ет счетчик времени жизни TTL (Time-To-Live). Маршрутизатор декременти­рует счетчик времени жизни всякий раз, когда он обрабатывает дейтаграмму, и удаляет ее, когда счетчик становится нулевым.

Независимо от того, удалил ли маршрутизатор дейтаграмму из-за обнуле­ния счетчика времени жизни или из-за превышения времени ожидания фраг­ментов дейтаграммы, он посылает сообщение ICMP «Лимит времени для дейта­граммы превышен» источнику дейтаграммы определенного формата (рис. 5.36).

Поле «Код» объясняет причину сообщения: 0 - превышено значение счет­чика времени жизни; 1 - превышено время ожидания фрагмента при сборке.

Сообщения о других ситуациях. Когда маршрутизатор или компьютер стал­кивается с проблемой, не укладывающейся в рамки описанных сообщений об ошибках ICMP (например, некорректный заголовок дейтаграммы), связанной с дейтаграммой, он посылает сообщение «Проблема с параметром пакета» первоначальному отправителю. Такую ситуацию может вызвать некоррект­ность аргументов опции. Сообщение, формат которого показан на рис. 5.37, посылается только в том случае, если дейтаграмма должна быть удалена из- за этой ошибки. Для уточнения места ошибки в дейтаграмме отправитель ис­пользует поле «Указатель» в заголовке сообщения для идентификации октета в дейтаграмме, содержащего ошибку.

Синхронизация часов и оценка времени передачи. Стек протоколов TCP/IP включает несколько протоколов, которые могут использоваться для синхрони­зации часов. В сети для этого используется несколько технологий. Одна из про­стейших технологий реализуется сообщениями ICMP для получения значения времени от другой машины. Запрашивающая машина посылает сообщение ICMP «Запрос метки времени» другой машине, ожидая, что вторая машина вернет ей текущее значение времени. Принимающая машина возвращает «От­вет для метки времени» машине, выдавшей запрос. Рис. 5.38 иллюстрирует формат сообщений запроса и ответа временной метки. Поле «Тип» идентифи­цирует сообщение как запрос (13) или ответ (14); поля «Идентификатор» и «Пос­ледовательный номер» используют источник для связи между ответами и зап­росами. Оставшиеся поля специфицируют времена, указанные в миллисекундах после полуночи, по Гринвичу. Поле «Временная метка отправителя» заполняет

первоначальный отправитель перед передачей пакета, поле «Временная метка приема» заполняется сразу после приема запроса, а поле «Временная метка передачи» - непосредственно перед отправкой ответа.

Компьютеры используют эти три поля временных меток для определения ожидаемого времени передачи между ними и синхронизации своих часов. Так как ответ включает поле «Временная метка отправителя», компьютер может вычислить общее время, требуемое для передачи запроса к назначению, фор­мирования ответа на него и возвращения ответа. Так как ответ содержит как время прихода запроса на удаленную машину, так и время выдачи ответа, ком­пьютер может вычислить время передачи по сети, а на его основе - разницу между своими и удаленными часами. На практике бывает трудно точно оце­нить время передачи по сети, так как ГР является технологией с негарантиро­ванной доставкой, дейтаграммы могут бьггь потеряны, задержаны или достав­лены не по порядку, что ограничивает полезность сообщений ICMP о временных метках.

Сообщения запроса и ответа информации. Сообщения ICMP запроса информации и ответа информации (тип 15 и 16) в настоящее время устарели и их использовать не рекомендуется. Они предназначались для обнаружения компьютерами своих IP-адресов при загрузке. Сейчас для определения адреса используют протоколы RARP и ВООТР.

Получение маски подсети. Для применения адресации подсетей компью­теру надо знать, какие биты их 32-битного IP-адреса соответствуют физичес­кой сети, а какие - адресу компьютера. Информация, требуемая для интерпре­тации адреса, представляет собой 32-битовую величину, называемую маской подсети. Чтобы узнать маску подсети, используемую в локальной сети, маши­на может послать сообщение запроса маски адреса маршрутизатору и полу­чить ответ маски адреса. Машина, формирующая запрос, может либо послать сообщение напрямую, если она знает адрес маршрутизатора, либо послать ши­роковещательное сообщение, если не знает его. Рис. 5.39 иллюстрирует фор­мат сообщений маски адреса. Поле «Тип» в сообщении маски адреса указыва­ет, является ли сообщение запросом (17) или ответом (18). Ответ содержит маску адреса подсети в поле «Маска адреса». Как правило, поля «Идентифи­катор» и «Последовательный номер» позволяют машине связать ответ с зап­росом.

Протокол IP имеет ясную и элегантную структуру. В нормальных ситуациях IP очень эффективно использует для пересылки память и ресурсы. Однако что произойдет в нестандартной ситуации? Что может прервать бесцельное блуждание датаграммы до завершения ее времени жизни после краха маршрутизатора и неисправности в сети? Кто предупредит приложение о прекращении отправки датаграмм в недостижимую точку назначения?

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

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

Рис. 7.1. Пакетирование сообщения ICMP

Бывают ситуации, приводящие к отбрасыванию (удалению из сети) датаграммы IP. Например, точка назначения может стать недоступной из-за обрыва связи. Или может завершиться время жизни датаграммы. Маршрутизатор не сможет переслать длинную датаграмму при запрещении фрагментации.

При отбрасывании датаграммы по адресу ее источника направляется сообщение ICMP, указывающее на возникшую проблему. На рис. 7.2 показано сообщение ICMP, направленное к источнику датаграммы.

Рис. 7.2. Сообщение ICMP направляется по пути трафика.

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

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

Реально ICMP не имеет средств предоставить отчет об ошибках выделенному операционному центру. Для этого служит протокол SNMP (см. главу 20).

На рис. 7.3 показаны обобщенные сообщения, формируемые маршрутизатором и хостом назначения для отчета о возникшей проблеме. В таблице 7.1 перечислены формальные имена сообщений об ошибках ICMP.

Рис. 7.3. Типы сообщений об ошибках ICMP

Таблица 7.1 Сообщения об ошибках ICMP

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

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

Что происходит при получении хостом сообщения ICMP? Рассмотрим пример, когда производится попытка обращения по зарезервированному (и, следовательно, недостижимому) адресу сети:

telnet: connect: Host is unreachable

Произошло то, что и должно было произойти,- в сообщении указано на недостижимость хоста (Host is unreachable).

Чтобы определить, какой из маршрутизаторов послал сообщение ICMP, можно использовать команду traceroute :

traceroute to 10.1.1.1 (10.1.1.1), 30 hops max, 40 byte packets

> nomad-gateway (128.121.50.50) 2 ms 2 ms 2 ms

> liberty-gateway (130.94.40.250) 91 ms 11 ms 78 ms

border2-hssi2-0.NewYork.mci.net (204.70.45.9) !H !H !H

Маршрутизатор New York послал сообщение Destination Unreachable , которое отображается на экране как!Н.

Функции traceroute основаны на ICMP-сообщении Time Expired и формируются следующим образом:

■ Создается короткое сообщение UDP, которое имеет заголовок IP с установленным в 1 полем TTL.

■ Трижды отправляется датаграмма.

■ Первый маршрутизатор (в примере - nomad-gateway ) устанавливает значение Time-to-Live (время жизни) в 0, отбрасывает датаграмму и отправляет источнику ICMP-сообщение Time Expired .

■ Функция traceroute идентифицирует пославший сообщение маршрутизатор и трижды выводит само сообщение.

■ Значение Time-to-Live устанавливается в 2, и сообщение посылается дальше.

■ Процесс повторяется с увеличением Time-to-Live на каждом шаге.

Если можно достичь точки назначения, то в итоге можно получить полный путь до него.

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

■ Маршрутизации и доставке ICMP-сообщений messages

■ Широковещательных и многоадресных датаграммах

■ Фрагментах датаграмм, кроме первых

■ Сообщениях, чей адрес источника не идентифицирует уникальный хост (например, IP-адреса источников 127.0.0.1 или 0.0.0.0)

Сообщение ICMP переносится в части данных датаграммы IP. Каждое сообщение ICMP начинается тремя одинаковыми полями: полем типа (Type), полем кода (Code), обеспечивающим более подробное описание ошибки, и полем контрольной суммы (Checksum). Формат оставшейся части сообщения определяется типом сообщения.

Сообщение об ошибке ICMP обрамляется заголовком IP. Добавляются первые 8 октетов датаграммы, которая привела к ошибке. Эти сведения позволяют проанализировать причину ошибки, поскольку содержат информацию о предполагаемом назначении датаграммы и целевом протоколе четвертого уровня. Дополнительные 8 байт позволяют определить коммуникационный элемент приложения (более подробно об этом см. в разделе о протоколах TCP и UDP).

В сообщение включается и контрольная сумма ICMP, начиная от поля Type .

Существует много причин прекращения доставки датаграммы. Разорванная связь физически не позволит маршрутизатору достичь подсети назначения или выполнить пересылку в точку следующего попадания. Хост назначения может стать недоступным при отключении его для проведения профилактики.

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

Рис. 7.4. Формат ICMP-сообщения Destination Unreachable

Формат сообщения Destination Unreachable показан на рис. 7.4. Поле Type (в нашем случае 3) идентифицирует именно этот тип сообщения. Поле Code отражает причину отправки сообщения. Полный список кодов этого поля представлен в таблице 7.2.

Таблица 7.2 Коды ошибок сообщения Destination Unreachable

Пересылаемая датаграмма может быть отброшена по тайм-ауту при уменьшении до нуля ее времени жизни (TTL). Еще один тайм-аут может возникнуть в хосте назначения, когда завершится время, выделенное на сборку, а прибыли еще не все фрагменты датаграммы. В обоих случаях формируется сообщение Time Exceeded для источника датаграммы. Формат этого сообщения показан на рис. 7.5.

Рис. 7.5. Формат ICMP-сообщения Time Exceeded

Значения кодов (см. таблицу 7.3) отражают причину тайм-аута.

Таблица 7.3 Коды сообщения Time Exceeded

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

Рис. 7.6. Формат ICMP-сообщения Parameter Problem

Поле Pointer (указатель) сообщения Parameter Problem идентифицирует октет, в котором выявлена ошибка. На рис. 7.6 показан формат сообщения Parameter Problem , а в таблице 7.4 - значения кодов ошибок.

Таблица 7.4 Коды сообщения Parameter Problem

Протокол IP очень прост: хост или маршрутизатор обрабатывают датаграмму и посылают ее как можно быстрее. Однако доставка не всегда проходит гладко. Могут возникнуть различные проблемы.

Когда один или несколько хостов отправляют трафик UDP на медленный сервер, то на последнем может возникнуть перегрузка, что приведет к отбрасыванию сервером некоторой части этого трафика.

Маршрутизатор может переполнить свои буферы и далее будет вынужден отбрасывать некоторые поступающие датаграммы. Медленное соединение через региональную сеть (например, на скорости 56 Кбит/с) между двумя скоростными локальными сетями (например, в 10 Мбит/с) может создать затор на пути следования датаграмм. Из-за этого в сети возникнут перегрузки, которые также приведут к отбрасыванию датаграммы и, следовательно, к созданию еще большего трафика.

Сообщение Source Quench (подавление источника) показано на рис. 7.7. Оно позволяет попытаться решить проблему перегрузок, хотя и не всегда успешно. Механизмы для подавления источника перегрузки сети должны создавать разработчики конкретных продуктов, но остается открытым конкретный вопрос:

Когда и кому маршрутизатор или хост должен отправлять сообщение Source Quench? Рис. 7.7. Формат ICMP-сообщения Source Quench

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

Текущий документ по требованиям к хостам (RFC 1812) оговаривает в качестве особого пункта, что сообщения Source Quench вовсе не нужно посылать. Работа должна выполняться более совершенным механизмом управления нагрузкой в сети.

К локальной сети может быть подключено более одного маршрутизатора. Когда локальный хост посылает датаграмму не на тот маршрутизатор, последний пересылает ее и отправляет хосту источника ICMP-сообщение Redirect (перенаправление), как показано на рис. 7.8. Хост должен переключить последующий трафик на более короткий путь.

Рис. 7.8 . Коррекция маршрутизации на хосте посредством сообщения Redirect

Сообщение Redirect используется и для выключения маршрутизатора системным администратором. Хост может быть сконфигурирован с единственным маршрутизатором по умолчанию; при этом он будет динамически определять возможности пересылки через другие маршрутизаторы.

Рис. 7.9. Формат ICMP-сообщения Redirect

Формат сообщения о перенаправлении показан на рис. 7.9. Коды этого сообщения перечислены в таблице 7.5. Некоторые протоколы маршрутизации способны выбирать путь доставки на основе содержимого поля типа обслуживания (TOS) датаграммы. Коды 2 и 3 предоставляют некоторые сведения да такого выбора.

Таблица 7.5 Коды перенаправления

Что должен делать хост, получивший сообщение ICMP? Реализации различных разработчиков по-разному отвечают на этот вопрос. В некоторых из них хосты игнорируют все или многие такие сообщения. Стандарты TCP/IP оставляют большую свободу выбора в решении этого вопроса. Для различных типов сообщений ICMP предлагаются следующие рекомендации:

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

При пересылке большого объема данных (например, при копировании файлов по сети) с одного хоста на другой размер датаграмм существенно влияет на производительность. Заголовки IP и TCP требуют не менее 40 дополнительных байт.

■ Если данные пересылаются в 80-байтовых датаграммах, дополнительная нагрузка составит 50%.

■ Если данные пересылаются в 400-байтовых датаграммах, дополнительная нагрузка составит 10%.

■ Если данные пересылаются в 4000-байтовых датаграммах, дополнительная нагрузка составит 1%.

Для минимизации дополнительной нагрузки лучше отсылать датаграммы наибольшего размера. Однако этот размер ограничивается значением максимального элемента пересылки (Maximum Transmission Unit - MTU) для каждого из носителей. Если датаграмма будет слишком большой, то она будет фрагментирована, а этот процесс снижает производительность. (С точки зрения пользователя, качество сети определяется двумя параметрами: интервалом пересылки (от начала пересылки до ее завершения) и временем ожидания (задержкой доступа к сети, занятой другими пользователями). Увеличение размера датаграммы приводит к снижению интервала пересылки, но увеличению ожидания для других пользователей. Грубо говоря, нагрузка на сеть будет выглядеть как пиковые импульсы с очень небольшой нагрузкой между ними, что считается самым неудачным вариантом загрузки сети. Гораздо лучше, когда сеть нагружается равномерно. - Прим. пер .)

Многие годы хосты избегали фрагментации, устанавливая эффективное значение MTU для пересылки в 576 октетов для всех нелокальных хостов. Это часто приводило к ненужному снижению производительности.

Гораздо полезнее заранее знать наибольший допустимый размер датаграммы, которую можно переслать по заданному пути. Существует очень простой механизм исследования MTU по пути (Path MTU discovery), позволяющий узнать это значение. Для такого исследования:

■ Флаг "Не фрагментировать" заголовка IP устанавливают в 1.

■ Размер MTU по пути первоначально устанавливают в значение MTU для локального интерфейса.

■ Если датаграмма будет слишком велика для одного из маршрутизаторов, то он пошлет обратно ICMP-сообщение Destination Unreachable с кодом 4.

■ Хост источника уменьшит размер датаграммы и повторит попытку.

Какое же значение нужно выбрать для следующей попытки? Спецификация IP предполагает сохранение значения MTU и его доступность для протоколов транспортного уровня. Если маршрутизатор имеет современное программное обеспечение, то он будет включать в пересылаемое дальше по сети сообщение Destination Unreachable размер MTU (см. рис. 7.10). Иногда средства защиты конфигурируются на полное исключение всех входящих сообщений ICMP, что не позволяет использовать механизм определения MTU по пути следования датаграммы.

Рис. 7.10. Сообщение Destination Unreachable приносит результат исследования размера

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

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

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

Не все сообщения ICMP сигнализируют об ошибках. Некоторые из них извлекают из сети полезные сведения. Работает ли хост X? Не выключен ли хост Y? Как долго движется датаграмма до хоста Z и обратно? Какова маска подсети хоста источника?

Ответы на эти вопросы дают следующие сообщения ICMP:

■ Эхо-запросы и эхо-ответы обеспечивают обмен информацией между хостами и маршрутизаторами.

■ Запросы и ответы о маске адреса позволяют системе исследовать присвоенную интерфейсу маску адреса.

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

На рис. 7.11 представлено обслуживание запросов ICMP. Программа Ping посылает эхо-сообщение "Вы в рабочем состоянии?", которое используется в ежедневной работе сетевого администратора. Запросы о маске адреса применяются от случая к случаю, а запросы о временной метке вообще редко.

Рис. 7.11. Сообщение запроса ICMP

Эхо-запросы (Echo Request) и эхо-ответы (Echo Reply) применяются для проверки активности системы. Код типа 8 применяется в запросах, а код 0 - в ответах. Количество октетов в поле данных переменно и может выбираться отправителем.

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

Рис. 7.12. Формат ICMP-сообщений Echo Request и Echo Reply

Широко известная команда ping доступна почти во всех системах TCP/IP, а ее работа основана на ICMP-сообщениях для эхо-запросов и эхо-ответов. В приведенном ниже диалоге сначала тестируется хост ring.bell.com . Затем отсылается последовательность из 14 сообщений, содержащих по 64 октета каждое. Отметим, что сообщения 0, 1 и 2 были потеряны. Справа приводятся сведения о пути туда и обратно.

> ping -s ring.bell.com 64 14

64 bytes from ring.bell.com: icmp_seq=3. time = 21. ms

64 bytes from ring.bell.com: icmp_seq=4. time = 18. ms

64 bytes from ring.bell.com: icmp_seq=5. time = 17. ms

64 bytes from ring.bell.com: icmp_seq=6. time = 19. ms

64 bytes from ring.bell.com: icmp_seq=7. time = 17. ms

64 bytes from ring.bell.com: icmp_seq=8. time = 17. ms

64 bytes from ring.bell.com: icmp_seq=9. time = 17. ms

64 bytes from ring.bell.com: icmp_seq=10. time = 18. ms

64 bytes from ring.bell.com: icmp_seq=11. time = 17. ms

64 bytes from ring.bell.com: icmp_seq=12. time = 17. ms

64 bytes from ring.bell.com: icmp_seq=13. time = 17. ms

-ring.bell.com PING Statistics-

14 packets transmitted, 11 packets received, 21% packet loss

round-trip (ms) min/avg/max = 17/17/21

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

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

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

На рис. 7.13 показан формат запроса маски адреса и ответа на него. Тип 17 применяется для запроса, а тип 18 - для ответа. В общем случае можно игнорировать идентификатор и последовательный номер.

Рис. 7.13. Формат ICMP-сообщений Address Mask

На практике более предпочтительный метод определения маски адреса предоставляют протоколы загрузки, например Dynamic Host Configuration Protocol или BOOTP . Эти протоколы более эффективны, поскольку обеспечивают полный набор конфигурационных параметров. Кроме того, операции выполняются более точно, в том числе и некорректные.

Сообщение с ответом на Timestamp предоставляет сведения о времени в системе. Оно предназначено для оценки буферизации и обработки датаграммы на удаленной системе. Отметим следующие поля:

По возможности, возвращаемое время должно измеряться в миллисекундах относительно полуночи по универсальному времени (Universal Time), которое ранее называлось временем по Гринвичу (Greenwich Mean Time). Большинство реализаций реально возвращает одно и то же время в полях Receive timestamp и Transmit timestamp .

Протокол ICMP обеспечивает очень простой способ синхронизации систем по времени. Однако это несколько грубая синхронизация, поскольку на нее влияют задержки в сети. Существует более совершенный протокол сетевого времени (Network Time Protocol), который был разработан для синхронизации по времени в Интернете.

Тип 13 используется для запросов, а 14 - для ответов. Формат сообщения представлен на рис. 7.14.

Рис. 7.14. Формат сообщений запросов и ответов о временной метке

Ниже показана часть отчета о статистике протоколов команды netstat. Приведенный фрагмент посвящен протоколу ICMP. В отчете отражены операции ICMP, выполненные после последней инициализации.

destination unreachable: 1075

2 messages with bad code fields

destination unreachable: 1269

231 message responses generated

Система отправила 1075 сообщений Destination Unreachable . Был получен 231 запрос Echo Requests , на каждый из которых был отправлен ответ. Было получено 26 ответов Echo Replies .

Локальная система зафиксировала 21 сообщение ICMP, полученное с неверной контрольной суммой ICMP.

Системой было получено 1269 сообщений Destination Unreachable и 2 сообщения Source Quenches .

Следующий далее отчет команды netstat содержит сведения о маршрутизации. Видно, что через сообщения Redirect были динамически обнаружены новые маршрутизаторы. Было 12 отчетов о недостижимости точки назначения (Destination Unreachable). Для выбора маршрута по умолчанию было использовано около 349 подстановочных символов (wildcard).

2 new routers due to redirects

2 destinations found unreachable

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

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

Протокол исследования маршрутов (Router Discovery) предоставляет надежный метод, основанный на сообщениях ICMP, для отслеживания маршрутизаторов локальной сети. Основная идея состоит в периодическом объявлении маршрутизаторами о своем присутствии. Хостам нужно прослушивать такие сообщения.

Предпочтительным способом для объявления маршрутизатора о своем присутствии является отправка многоадресной рассылки по адресу для всех систем (224.0.0.1). Однако не все хосты поддерживают прием многоадресных рассылок, поэтому иногда применяется широковещательный адрес (255.255.255.255).

Подключающийся к сети хост может быть не способен к ожиданию при поиске маршрутизаторов локальной сети. Такой хост самостоятельно запрашивает маршрутизаторы об отправке их объявлений о присутствии на собственный адрес. Для этого лучше всего использовать сообщение Router Solicitation (настоятельная просьба к маршрутизаторам) в многоадресной рассылке по адресу "все маршрутизаторы" (224.0.0.2). Поскольку не все системы поддерживают многоадресные рассылки, иногда применяется широковещательная рассылка (255.255.255.255).

Типичный сценарий для маршрутизатора:

■ Каждый интерфейс маршрутизатора конфигурируется с адресом объявления (advertisement address) - 224.0.0.1 или 255.255.255.255 - для локальной сети, подключенной к данному интерфейсу.

■ При инициализации маршрутизатора и использовании многоадресной рассылки маршрутизатор начинает прослушивание адреса многоадресной рассылки для всех маршрутизаторов (224.0.0.2). Кроме того, прослушиваются и широковещательные рассылки.

■ Маршрутизатор объявляет о своем присутствии всем подключенным к локальной сети хостам посредством трансляции сообщения Router Advertisement на адрес объявления такой локальной сети. В объявлении о присутствии перечисляются все IP-адреса маршрутизатора для данного интерфейса.

■ Маршрутизатор напоминает о себе различными периодическими сообщениями Router Advertisement (рекомендуемый период 7–10 мин.).

■ Маршрутизатор посылает объявление о присутствии при запросе об этом от хоста.

Для хоста сценарий выглядит так:

■ Каждый интерфейс хоста конфигурируется с Solicitation Address - 224.0.0.2 или 255.255.255.255.

■ При инициализации хоста начинается прослушивание Router Advertisement .

■ При запуске хост может послать необязательное сообщение Router Solicitation по адресу настоятельных просьб (solicitation address). Маршрутизаторы ответят как по IP-адресу хоста, так и по адресу объявления.

■ Когда хост услышит о новом маршрутизаторе, он добавит маршрут по умолчанию в свою таблицу маршрутизации. Этому элементу таблицы присваивается значение тайм-аута на время жизни (обычно 30 мин), которое указано в Router Advertisement .

■ Тайм-аут на время жизни сбрасывается при получении нового объявления от маршрутизатора. Если время жизни завершается по тайм-ауту, элемент для маршрутизатора удаляется из таблицы маршрутизации хоста.

■ Для объявления всем о корректном отключении от сети маршрутизатор может послать объявления с нулевым значением для времени жизни.

Если имеется более одного маршрутизатора, то как хост определяет тот, которому следует направить данную датаграмму? Каждое объявление маршрутизатора содержит номер предпочтительного уровня (preference level). Если таблица маршрутизации не содержит специальных указаний, выбирается маршрутизатор с наибольшим предпочтительным уровнем. Если он не сможет обеспечить наилучший маршрут, то ответит хосту ICMP-сообщением о перенаправлении.

В ICMP-сообщении Router Advertisement имеет значение типа 9, a Router Solicitation - 10.

Исследование маршрутов (маршрутизаторов) помогает хостам определить крах локального маршрутизатора, однако после достаточно длительного периода времени - возможно, через 30 мин. Реализация TCP/IP для хостов предполагает использование встроенного алгоритма для определения неисправности маршрутизатора. Его достоинства очевидны, например:

■ Существование активного сеанса TCP/IP через маршрутизатор

■ Фиксирование получения от маршрутизатора ICMP-сообщений о перенаправлении.

К числу недостатков можно отнести:

■ Невозможность ответа на запросы ARP

■ Множество последовательных тайм-аутов при повторной пересылке в TCP

IP версии 6 обеспечивает наилучший способ исследования причин приостановки работы локальных хостов или маршрутизаторов.

ICMP определен в RFC 792. RFC 1122 (требования к хостам) и RFC 1812 (требования к маршрутизаторам) содержат несколько очень полезных разъяснений. Исследованию маршрутов посвящен RFC 1256.

Исследование MTU по пути рассмотрено в RFC 1191, а дополнительные рекомендации представлены в RFC 1435.

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-эхо-запросы (пинги).

Блокирует фрагменты 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 (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) содержит много сообщений, которые идентифицируются полем «тип».

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

Хотя 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, чтобы скорректировать передачу.