69584

Протокол ICMP

Практическая работа

Информатика, кибернетика и программирование

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

Русский

2014-10-07

3.35 MB

6 чел.

Протокол ICMP

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

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

Для решения перечисленных выше задач: диагностики неисправностей и уведомления об ошибках в стеке TCP/IP существует специальный протокол ICMPInternet Control Message Protocol (Протокол управляющих сообщений составной сети).

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

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

Таким образом, ICMP не делает IP сеть надежной, он применяется лишь для уведомления об ошибках, при чем доставка самих ICMP сообщений тоже не гарантируется. ICMP предназначен для помощи в диагностике неисправностей, но при этом НИЧЕГО не гарантирует.

 ICMP передается по составной сети непосредственно в IP пакете, для чего одно из значений поля Protocol IP заголовка (а именно 01) зарезервировано за ICMP. Протокол ICMP описан в основном в RFC792. Рассмотрим обобщенный формат ICMP заголовка:

<----------8--------><---------8---------><--------------------16-------------------->

Type

Code

Checksum

Зарезервировано, может использоваться в зависимости от значений полей тип и код

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

Значение полей:

Поле Type показывает тип пакета. Что это значит? Уж ясно, что протокол ICMP выполняет много различных, порой непохожих друг на друга функций. Как один протокол с одним, формализованным, заголовком может выполнять множество разнородных задач? Фактически, поле Type показывает, что именно делает данное сообщение ICMP, какую функцию реализует, и тогда последующие поля (зарезервированное четырехбайтовое слово и поле данных) принимают значения, специфичные для данного конкретного значения пỏля Type. С формальной точки зрения можно сказать, что ICMP – это много разных протоколов, поле Type показывает - о каком именно подпротоколе идет речь.

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

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

Фактически, неизменным в ICMP остается только первое четырехбайтовое слово заголовка, остальное содержимое заголовка пакета и поля данных зависит от значения поля Type.

 Приступим к изучению работы протокола ICMP с описания сообщений со значениями поля Type равными 0 и 8 (Echo or Echo Reply Message). Одним из методов проверки взаимодействия 3-го уровня может быть совместная работа приложений, выполняемых на разных станциях, взаимодействующих по сети. Недостатком данного метода является отсутствие возможности контроля выполнения в данный момент времени приложения на каждой станции, вследствие чего возможна неправильная интерпретация результатов подобной проверки. Другими словами, мы не можем утверждать, что в данный момент приложение запущено «на той стороне». А как быть с узлами, на которых пока не запущены приложения? Было бы хорошо, если бы можно было послать на станцию такой пакет, на который, в любом случае, ответит компонент стека TCP/IP, а не приложение, которое может быть и не запущено. В стеке TCP/IP такая возможность предусмотрена. В предыдущих уроках, для проверки возможности обмениваться пакетами с некоторой станцией применялась утилита ping.exe, но каким образом она работает, и какой протокол использует, нами не рассматривалось. Освещением этого вопроса мы сейчас и займемся. 

Итак, ICMP пакет, поле Type которого равно 8, называется эхо-запрос. Любая станция или маршрутизатор, получившие такое сообщение, должны сгенерировать в ответ ICMP сообщение с типом 0, которое называется эхо-ответ, это сообщение получит отправитель эхо-запроса. Так как поддержка ICMP должна обязательно присутствовать во всех реализациях стека TCP/IP, то любая станция или маршрутизатор всегда ответят на эхо-запрос эхо-ответом, что позволяет проверить возможность обмениваться IP пакетами с любой станцией или маршрутизатором, не зависимо от работающих на узлах или маршрутизаторах приложений. Так как установка поля Type в значение 8 уже означает, что данный ICMP пакет есть эхо-запрос, и никакие дополнительные уточнения не требуются,  то поле Code как эхо-запросов, так и эхо-ответов всегда равно 0.

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

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

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

Type = 8 или 0

Code = 0

Checksum

Identifier

Sequence Number

Произвольные данные произвольной длины

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

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

Как должен поступить стек TCP/IP, получив ICMP сообщение типа 8 с кодом 0? Необходимо сформировать ICMP пакет с типом 0 и кодом 0, процитировать из полученного запроса поля Identifier и Sequence Number, процитировать все данные, которые получены в запросе,  сформировать IP пакет, поменяв местами адрес отправителя и получателя и вложить в него данное, сформированное ICMP сообщение.

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

C:\>ping www.alkar.net

Обмен пакетами с www.alkar.net [195.248.190.51] по 32 байт:

Ответ от 195.248.190.51: число байт=32 время=345мс TTL=58

Ответ от 195.248.190.51: число байт=32 время=319мс TTL=58

Ответ от 195.248.190.51: число байт=32 время=113мс TTL=58

Ответ от 195.248.190.51: число байт=32 время=361мс TTL=58

Статистика Ping для 195.248.190.51:

   Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),

Приблизительное время приема-передачи в мс:

   Минимальное = 113мсек, Максимальное = 361 мсек, Среднее = 284 мсек

По умолчанию утилита ping.exe  в Windows посылает 4 запроса и ожидает на них ответов, в случае, если ответы приходят - показывает задержку между посылкой запроса и приходом ответа, которую измерила сама программа ping. Анализ пакетов нижеприведенного дампа показывает, что послано действительно 4 запроса, на все получены ответы, и замеры задержек самим анализатором очень близки к замерам времени утилитой ping.exe. Рассмотрим  изученные поля в заголовке пакета: в ответах цитируются Identifier и Sequence Number из запроса. Утилита ping.exe  в Windows по умолчанию, посылает пакеты с 32 байтами данных, и данные эти совершенно не несут самостоятельной смысловой нагрузки, а просто являются «алфавитом».

Обратите внимание, поле Sequence Number различных запросов отличаются, а Identifier не меняются.

Рассмотрим пример работы утилиты ping.exe  с потерянным запросом (или ответом):

C:\>ping www.exler.ru

Обмен пакетами с www.exler.ru [217.16.18.192] по 32 байт:

Превышен интервал ожидания для запроса.

Ответ от 217.16.18.192: число байт=32 время=664мс TTL=51

Ответ от 217.16.18.192: число байт=32 время=155мс TTL=51

Ответ от 217.16.18.192: число байт=32 время=581мс TTL=51

Статистика Ping для 217.16.18.192:

   Пакетов: отправлено = 4, получено = 3, потеряно = 1 (25% потерь),

Приблизительное время приема-передачи в мс:

   Минимальное = 155мсек, Максимальное = 664 мсек, Среднее = 466 мсек

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

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

C:\>ping –w 1000 www.pravda.ru

Обмен пакетами с www.pravda.ru [217.16.28.239] по 32 байт:

Превышен интервал ожидания для запроса.

Ответ от 217.16.28.239: число байт=32 время=790мс TTL=242

Ответ от 217.16.28.239: число байт=32 время=997мс TTL=242

Превышен интервал ожидания для запроса.

Статистика Ping для 217.16.28.239:

   Пакетов: отправлено = 4, получено = 2, потеряно = 2 (50% потерь),

Приблизительное время приема-передачи в мс:

   Минимальное = 790мсек, Максимальное = 997 мсек, Среднее = 893 мсек

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

Для того чтобы гибко изменять время ожидания ответа и не допускать ситуации, когда обмен пакетами есть, но из-за большой задержки создается впечатление, что обмен пакетами не возможен - утилита ping.exe поддерживает ключ –w xxxx, где хххх – количество миллисекунд, в течение которых ping.exe ждет ответа и не посылает следующий запрос.

Пример использования ключа –w.

C:\>ping -w 99999 www.inter.com

Pinging gekko.bpsi.net [199.199.134.10] with 32 bytes of data:

Reply from 199.199.134.10: bytes=32 time=413ms TTL=230

Reply from 199.199.134.10: bytes=32 time=343ms TTL=230

Reply from 199.199.134.10: bytes=32 time=319ms TTL=230

Reply from 199.199.134.10: bytes=32 time=1030ms TTL=230

Ping statistics for 199.199.134.10:

   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

   Minimum = 319ms, Maximum = 1030ms, Average = 526ms

Кроме того, утилита ping.exe может позволить администратору генерировать ICMP эхо-запрос с произвольным количеством данных, для этого применяют ключ –l. При этом нужно понимать, что после ключа –l указывается количество данных ICMP пакета в байтах, т.е. для того, чтобы выяснить результирующий размер IP пакета к нему еще нужно добавить заголовок ICMP (8 байт) и заголовок IP (переменная длина, обычно 20 байт, если не используются опции). Поэтому, для генерации ICMP эхо запроса, который будет упакован в канальный кадр максимальной длины, в Ethernet необходимо указать длину ICMP данных 1500-8-20=1472. Если использовать большее значение, то локальный стек TCP/IP на узле отправителе будет вынужден фрагментировать пакет. При этом, так как в ответах необходимо процитировать данные запроса, то пришедшие ответы тоже будут фрагментированы либо отвечающим узлом, либо транзитными маршрутизаторами.

Примеры использования ключа –l 1472 и –l 1474:

ping 19.248.190.51 –l 1472

В результате размер кадра канального уровня равен

1472(данные ICMP)+8(заголовок ICMP)+20(заголовок IP)+[6+6+2](поля Ethernet DIX) = 1514 байт

ping 19.248.190.51 –l 1474

В результате размер кадра канального уровня равен

1474(данные ICMP)+8(заголовок ICMP)+20(заголовок IP)+[6+6+2](поля Ethernet DIX) = 1516 байт. Что вызывает фрагментацию.

Ключ –n, позволяющий отправить не четыре, а любое оговоренное заранее количество запросов, и ключ –t, позволяющий отправлять запросы до тех пор, пока это не будет прервано с клавиатуры.

C:\>ping -n 5 www.kp.ru

Pinging www.kp.ru [217.16.28.84] with 32 bytes of data:

Reply from 217.16.28.84: bytes=32 time=456ms TTL=45

Reply from 217.16.28.84: bytes=32 time=449ms TTL=45

Reply from 217.16.28.84: bytes=32 time=640ms TTL=45

Reply from 217.16.28.84: bytes=32 time=587ms TTL=45

Reply from 217.16.28.84: bytes=32 time=415ms TTL=45

Ping statistics for 217.16.28.84:

   Packets: Sent = 5, Received = 5, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

   Minimum = 415ms, Maximum = 640ms, Average = 509ms

C:\>ping -t www.kp.ru

Pinging www.kp.ru [217.16.28.84] with 32 bytes of data:

Reply from 217.16.28.84: bytes=32 time=464ms TTL=45

Reply from 217.16.28.84: bytes=32 time=546ms TTL=45

Reply from 217.16.28.84: bytes=32 time=392ms TTL=45

Reply from 217.16.28.84: bytes=32 time=486ms TTL=45

Reply from 217.16.28.84: bytes=32 time=830ms TTL=45

Reply from 217.16.28.84: bytes=32 time=660ms TTL=45

Reply from 217.16.28.84: bytes=32 time=558ms TTL=45

Reply from 217.16.28.84: bytes=32 time=657ms TTL=45

Reply from 217.16.28.84: bytes=32 time=926ms TTL=45

Reply from 217.16.28.84: bytes=32 time=731ms TTL=45

Reply from 217.16.28.84: bytes=32 time=922ms TTL=45

Ping statistics for 217.16.28.84:

   Packets: Sent = 11, Received = 11, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

   Minimum = 392ms, Maximum = 926ms, Average = 652ms

Control-C

^C

C:\>

Кроме того, с помощью утилиты ping.exe можно установить в эхо-запросе произвольный TTL с помощью флага –i:

C:\>ping -i 255 www.kp.ru

Pinging www.kp.ru [217.16.28.84] with 32 bytes of data:

Reply from 217.16.28.84: bytes=32 time=329ms TTL=45

Reply from 217.16.28.84: bytes=32 time=330ms TTL=45

Reply from 217.16.28.84: bytes=32 time=372ms TTL=45

Reply from 217.16.28.84: bytes=32 time=381ms TTL=45

Ping statistics for 217.16.28.84:

   Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

   Minimum = 329ms, Maximum = 381ms, Average = 353ms

Так же, существует возможность назначения поля TOS отправляемому IP пакету (в MS Windows не работает ). С помощью утилиты ping.exe можно снабдить IP заголовок отправляемого ICMP эхо пакета опцией RR, TS, LSRR, SSRR – ключи r, s, l и k.

Таким образом, утилита ping – важный диагностический инструмент, позволяющий администратору находить разнообразные неисправности в сети, ее работа базируется на ICMP сообщениях типа 8 и 0.

Переходим к следующему по порядку сообщению: сообщения типа 1 и типа 2 зарезервированы, рассмотрим сообщение типа 3.

Сообщения типа 3 - называют сообщениями о недостижимости получателя (Destination Unreachable). Такие ICMP пакеты могут слать как узлы, так и маршрутизаторы в случае, если они не могут доставить пакет получателю. Так как причин недостижимости может быть много, в сообщениях типа 3 применятся поле Code, которое уточняет причину недостижимости. Рассмотрим, для начала кратко, основные причины недостижимости получателя и соответствующие коды.

Код 0. Net Unreachable (Сеть недостижима).

Этот код, в полученном ICMP сообщении о недостижимости означает, что маршрутизатор (а такие пакеты может слать только маршрутизатор) не имеет маршрута в сеть получателя (и, разумеется, маршрута по умолчанию тоже) и поэтому вынужден отбросить пакета. Подобная конфигурация маршрутизатора известна, пакет в таком случае отбрасывается, но при этом так же посылается ICMP сообщение типа 3 с кодом 0, с помощью которого маршрутизатор информирует узел отправитель о том, что он отбрасывает пакет. Так же подобное сообщение будет послано, если адрес следующего маршрутизатора известен, но маршрутизатор не откликается на ARP запросы.

Код 1. Host Unreachable (Узел недостижим).

Этот код означает, что маршрутизатор отбрасывает пакет, так как не смог передать его непосредственно узлу получателю. Т.е. пакет поступил на маршрутизатор подключенный к сети, которой принадлежит получатель, после чего маршрутизатор послал ARP запросы в поисках МАС адреса получателя и не получил ответа. Таким образом, маршрутизатор убедился, что узел-получатель недоступен. Такой пакет может послать только маршрутизатор, при чем не любой маршрутизатор, а только тот, который подключен непосредственно к той сети, которой принадлежит получатель пакета.

Код 2. Protocol Unreachable (Протокол недостижим).

Положим, станция получила некоторый IP пакет. В этом пакете лежат данные, какого либо протокола верхнего уровня (например, ICMP). Станция получатель пакета узнает из анализа поля Protocol заголовка IP пакета, какому протоколу верхнего уровня передать  данные из IP пакета для дальнейшей обработки. Предположим, что на станции получателе нет программного обеспечения, которое должно обрабатывать пакеты с таким полем Protocol. В таком случае станция отбрасывает IP пакет, но отсылает отправителю ICMP сообщение типа 3 с кодом 2 – сообщение о недостижимости протокола на узле-получателе пакета. Такие ICMP сообщения не имеют права слать транзитные маршрутизаторы т.к. на них не обязательно наличие программного обеспечения для анализа содержимого IP пакета, такого - какое есть у узла получателя пакета. Кроме того, маршрутизаторам вообще не положено анализировать поле данных IP пакета.

Код 3. Port Unreachable (Порт недостижим).

Поле Protocol IP заголовка столь мало (1 байт), что адресовать приложения, передающие свои данные с помощью IP пакетов с его помощью невозможно. Поэтому, даже для тех приложений, которым не нужны функции транспортного и сеансового уровней (т.е. гарантии доставки данных) необходимо иметь протокол, который бы располагался над IP и позволял адресовать большое количество приложений, а не 256, как IP. Фактически, между IP заголовком и приложениями нужен «переходник», которому присвоено некоторое значение поля Protocol, а сам этот протокол, будет иметь длинные поля для адресации приложений (например, двухбайтовые). Именно эту функцию и выполняет протокол UDP, а его поле, предназначенное для адресации приложений, называется «порт». Соответственно, когда на станцию поступает IP пакет, внутри которого лежит заголовок UDP, а внутри UDP пакета лежат данные какого то прикладного протокола - UDP на станции получателе передает извлеченные из пакета данные в адрес (на порт) этого приложения. Если на узле получателе нет соответствующего приложения (т.е. порт с данным номером не соответствует ни одному запущенному приложению) то пакет отбрасывается, а его отправителю посылается ICMP сообщение типа 3 с кодом 3. Данное сообщение, очень похоже на предыдущее (тип 3 код 2) и, по той же причине, никогда не может быть послано маршрутизатором, а посылается лишь узлом получателем пакета.

Код 4. Fragmentation needed and DF set (необходимо фрагментация, но установлен флаг DF). Данное сообщение посылается только маршрутизаторами и означает, что пакет необходимо фрагментировать, однако это запрещено, так как установлен флаг DF в заголовке IP пакета.

Код 5. Source route failed (неверный маршрут от источника). Данное сообщение посылают маршрутизаторы в случае, если в заголовке IP пакета присутствует опция SSRR, однако достичь на канальном уровне следующего указанного отправителем маршрутизатора нет возможности.

Приведенные выше коды описаны в RFC792. Кроме этого, существуют несколько сообщений типа 3, описанных в более поздних RFC, однако сообщения с этими кодами сегодня не применяются и рассматривать их мы не будем.

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

Но в любом случае остается открытым вопрос: откуда станция, пославшая много пакетов, возможно многим станциям составной сети, и получившая ICMP сообщение о недостижимости узла поймет, какой именно узел недостижим? Рассмотрим пример: мы послали 1000 писем бумажной почтой, и нам приходит извещение – ваше письмо не доставлено, так как адресат выбыл! КОМУ не доставлено письмо? Без этой информации ICMP сообщение об ошибке выглядит бессмысленно: получатель не достижим, а кто не достижим – не понятно. Для того чтобы снабдить отправителя сведениями о том, какой именно пакет не смог достичь получателя, в поле данных ICMP пакета о недостижимости полностью цитируется IP заголовок уничтоженного пакета и первые 8 байт данных этого пакета. Получив такое сообщение о недостижимости, отправитель сможет проанализировать заголовок уничтоженного пакета и понять, КАКОЙ ИМЕННО узел оказался не достижим. Рассмотрим формат ICMP пакета о недостижимости:

Type = 3

Code  

Checksum

Не используется, равно 00 00

IP заголовок уничтоженного пакета и первые 8 байт данных этого пакета.

Всего от 28 до 68 байт данных

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

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

Пусть на левом маршрутизаторе не настроен маршрут в сеть 192.168.133.0/24. В таком случае, если станция 192.168.0.89 пошлет пакет к станции 192.168.133.10, левый маршрутизатор пошлет станции 192.168.0.89 ICMP пакет о недостижимости сети. Рассмотрим приведенный ниже дамп.

Что мы видим: вместо пакета о недостижимости сети, который мы ожидали получить, мы получаем сообщение о недостижимости узла! (файл HU.cap)

Видно, что в поле данных ICMP пакета о недостижимости узла цитируется IP заголовок уничтоженного пакета, из которого следует, что недостижим именно 192.168.133.10. Однако почему вместо ожидаемого Net Unreachable мы видим Host Unreachable? Это связано с некоторыми изменениями, которые были внесены в работу IP уже после появления RFC792.
Точнее это связано с введение масок подсетей и технологии
CIDR для распределения адресов. Рассмотрим это на примере:

Пусть пока на магистрали Интернет используются классы, но классовые сети могут быть разбиты на подсети масками. Пусть станция послала пакет узлу 68.1.2.3 и получила в ответ сообщение о недостижимости СЕТИ получателя от какого либо маршрутизатора. Из этого сообщения, которое, разумеется, не содержит в себе маски, станция отправитель  может сделать только один вывод: сеть 68.0.0.0 (сеть класса А) недостижима! Т.е. станция может перестать некоторое время пытаться посылать пакеты во всю сеть 68.0.0.0 после получения такого пакета. Но сеть 68.0.0.0 может быть разбита на подсети и возможно не достижима лишь подсеть 68.1.0.0/16, а остальные подсети сети 68.0.0.0 вполне достижимы. Следовательно, получение такого пакета с сообщением о недостижимости сети может препятствовать нормальным коммуникациям с множеством узлов из диапазона 68.0.0.0/8. Вина в этом случае лежит на администраторе сети 68.0.0.0, но это не слишком хорошее оправдание.

В случае применения CIDR ситуация еще хуже. Возможно сеть класса А 68.0.0.0 предоставлена различным провайдерам в соответствии с технологий CIDR, следовательно, адресное пространство предоставлено без учета классов, т.е., например, диапазон 68.0.0.0/20 может принадлежать одному провайдеру, а диапазон 68.0.16.0/20 – другому провайдеру. Следовательно, получив ICMP пакет о недостижимости СЕТИ, при попытке передать пакет узлу 68.1.2.3 станция может сделать вывод о недостижимости все сети 68.0.0.0/8, в то время как огромная часть диапазона 68.0.0.0/8 принадлежит другим провайдерам и вполне достижима. Следовательно, если отправитель пакета к станции 68.1.2.3 получит в ответ от маршрутизатора ICMP пакет типа 3 с кодом 0 и сделает вывод о недостижимости всей сети 68.0.0.0/8 то будет утрачена возможность взаимодействия с множеством узлов по вине совершенно постороннего администратора диапазона 68.0.0.0/20, который своими неверными настройками разрушил коммуникации не только в рамках своего диапазона адресов но и нарушил возможность взаимодействия огромному количеству других систем.

Вследствие вышеописанного, сегодня ICMP сообщения типа 3 с кодом 0 КАТЕГОРИЧЕСКИ осуждаются. Узлам и маршрутизаторам предписано бороться с такими сообщениями следующим образом:

Маршрутизаторам рекомендовано отказаться от посылки ICMP сообщений типа 3 с кодом 0, вместо этого  следует всегда посылать ICMP сообщения типа 3 с кодом 1 – узел недостижим.

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

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

Теперь рассмотрим ситуацию, в которой должно быть сформировано сообщение Host Unreachable, действительно означающее недостижимость хоста. Такое сообщение должен посылать маршрутизатор, если на его ARP запросы в поисках узла получателя не поступило ответа. Теоретически, для этого достаточно послать пакеты (например, ICMP эхо запросы) несуществующему узлу другой сети через маршрутизатор. Однако, на практике, пример операционной системы Windows 2003 Server, показывает обратное:

C:\>ping 192.168.55.3

Pinging 192.168.55.3 with 32 bytes of data:

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Ping statistics for 192.168.55.3:

   Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

В анализаторе на стороне 192.168.0.89

На стороне 192.168.55.1

Явный Host Unreachable, при аналогичных условиях, получается на примере операционной системы Linux.

Переходим к следующему сообщению – протокол недостижим. ICMP сообщения данного типа/кода могут посылать только узлы. Причиной появления данного сообщения является приход на станцию получатель пакета с неизвестным кодом протокола инкапсуляции. В ответ станция генерирует ICMP сообщение о недостижимости протокола. Рассмотрим пакет с неизвестным значением поля Protocol и ICMP сообщение о недостижимости (файл PU.cap):

Указанный код инкапсуляции (254) является зарезервированным, ему не соответствует ни один из существующих протоколов.

Далее рассмотрим сообщение с кодом 3 – Port Unreachable. Данное сообщение является реакцией стека TCP/IP на получение пакета с номером порта получателя не обслуживаемым в данный момент ни одним процессом в операционной системе. Такое ICMP сообщение может посылать только узел, а не транзитные маршрутизаторы, так как маршрутизаторы не являются конечными получателями инкапсуляции IP пакета -UDP. Пример таких пакетов (файл PrtU.cap). В поле Destination Port пакета указывается номер порта который в данный момент не обслуживается ни одним приложением.

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

Рассмотрим следующее сообщению о недостижимости с кодом 4 – Fragmentation Needed and DF Set (необходима фрагментация, но установлен флаг DF).

В RFC792 формат ICMP сообщения о недостижимости вследствие запрета фрагментации не отличается от формата других сообщений о непостижимостях, т.е. второе четырехбайтовое слово заголовка ICMP является зарезервированным. Если маршрутизатор уничтожает пакет по причине невозможности его фрагментировать, то узел отправитель пакета получает это сообщение и должен сам уменьшить размер пакета, не имея на самом деле достоверной информации о том, НА СКОЛЬКО уменьшить размер пакета. Если узел уменьшит размер пакета незначительно, то он рискует снова получить сообщение о недостижимости, таким образом, взаимодействие будет замедлено. Если узел стразу значительно уменьшит размер пакета, то может получиться неэффективная работа сети из-за передачи малых порций данных (при фиксированном размере заголовка), если же узел уберет флаг DF из пакета, то тем самым он откажется от избавления маршрутизаторов от фрагментации, что приведет к не достижению цели, которая ставилась изначально использованием флага DF. Для решения данной проблемы в RFC1191 была предложена следующая модификация заголовка ICMP сообщения о недостижимости типа 3 с кодом 4:

Type = 3

Code = 4

Checksum

Не используется, равно 00 00

MTU следующей сети

IP заголовок уничтоженного пакета и первые 8 байт данных этого пакета.

Всего от 28 до 68 байт данных

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

Видно, что Sniffer Pro не умеет декодировать поле, введенное в RFC1191, попробуем просмотреть то же пакет в Network Monitor (DF2.cap):

Видно, что этот анализатор протоколов понимает поле Next Hop MTU в заголовке ICMP сообщения типа 3 с кодом 4.

Переходим к следующему сообщению о недостижимости получателя, сообщение с кодом 5, которое означает, что неверен маршрут, указанный отправителем пакет (при использовании маршрутизации от источника) - Source route failed.

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

C:\>ping -n 1 -k 192.168.0.1 21.1.1.1 212.15.128.1

Обмен пакетами с 212.15.128.1 по 32 байт:

Ответ от 192.168.0.1: Указан неправильный маршрут.

Статистика Ping для 212.15.128.1:

   Пакетов: отправлено = 1, получено = 1, потеряно = 0 (0% потерь),

Приблизительное время приема-передачи в мс:

   Минимальное = 0мсек, Максимальное = 0 мсек, Среднее = 0 мсек

Здесь первый проходимый маршрутизатор действительно достижим на канальном уровне, но уже второй маршрутизатор не достижим первым маршрутизатором. В ответ первый маршрутизатор посылает отправителю ICPM сообщение о неверном маршруте, указанном источником: (файл SRF.cap, опции рекомендуется анализировать в Network Monitor):

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

ICMP Type = 4.

ICMP сообщение типа 4 может иметь только код, он равен нулю. Данное сообщение называется Source Quench – подавление источника. Это сообщение предлагалось посылать маршрутизаторам в том случае, если поток данных на маршрутизатор превышает тот поток, который маршрутизатор может обработать. Возможно несколько ситуаций, когда маршрутизатор не справляется с потоком данных, поступающих на него:

  •  Станция, подключенная к сети высокоскоростным интерфейсом, посылает на маршрутизатор большое количество данных в сеть, доступную маршрутизатору на низкой скорости. В таком случае маршрутизатор не испытывает перегрузок, но перегрузки испытывает сеть, в которую необходимо отправлять пакеты. Разумеется, маршрутизатор может и должен буферизировать такие пакеты, но буфер любого размера, тем не менее, конечен. И когда место в буфере маршрутизатора начинает заканчиваться, маршрутизатор уведомляет станцию с помощью ICMP сообщения о подавлении источника, чтобы станция уменьшила поток данных для этого получателя, отправляемый на маршрутизатор. Отправка такого ICMP сообщения в общем случае не означает, что пакеты, на которые отправляются сообщения типа 4 отбрасываются, но это сообщение уведомляет отправителя, что пакеты могут быть отброшены, если поток пакетов на маршрутизатор не уменьшится.
  •  Маршрутизатор просто перегружен пакетами, которые отправляют на него станции, ему не хватает буферной памяти для сохранения ожидающих обработки пакетов и он отправляет ICMP Source Quench с целью попросить узлы замедлить передачу пакетов.

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

 Фактически, ICMP сообщение типа 4, предназначалось для решения задачи об управлении потоком данных в составной сети (аналогично управление потоком в локальных сетях в полудуплексном и дуплексном режимах работы). Однако такой простой метод управления потоком оказался неэффективным в сложных составных сетях. Сегодня вместо того, чтобы управление потоком данных возлагалось на маршрутизаторы, решение этой проблемы лежит на узлах сети. А именно, коммуникации можно разделить на два условных типа:  коммуникации, при которых отправляются единичные пакеты и коммуникации, при которых отправляются длительные, устойчивые потоки данных. Для коммуникаций первого типа используется протокол UDP, для коммуникаций второго типа используется протокол TCP (UPD и TCP будут подробно изучены в следующем курсе). Если станция отправляет единичные пакеты, то управлять потоком данных от этой станции нет смысла, так как никакого потока и нет, а если станция отправляет большие потоки данных, используя протокол TCP, то именно на протокол TCP и возлагается задача об управлении этим потоком данных. Каким образом протокол TCP управляет потоком данных, будет подробно рассмотрено при изучении протокола TCP. Таким образом, на сегодняшний день маршрутизаторам нет нужды управлять потоком данных, и поэтому ICMP сообщения типа 4 сегодня считаются морально устаревшими и практически не применяются. Рассмотрим использование ICMP Source Quench на примере  (файл SQ.cap). В большинстве случаев маршрутизаторы не поддерживают ICMP Source Quench.

Переходим к сообщениям следующего типа, если поле Type = 5, то такие сообщения называют ICMP Redirect. Рассмотрим работу Redirect на примере:

Пусть узел находится в сети множественного доступа (например, Ethernet). Эта сеть – часть составной сети, в этой сети есть два маршрутизатора, при чем часть сетей составной сети доступна через маршрутизатор R1, а часть сетей доступна через маршрутизатор R2. Разумеется, маршрутизаторы R1 и R2 имеют соответствующие правильные таблицы маршрутизации и могут перенаправлять пакеты во все сети. Вопрос в следующем: как сконфигурировать узел 192.168.0.89? Мы привыкли к тому, что узлу просто сообщают адрес шлюза по умолчанию, и он свою задачу о маршрутизации решает просто: пакеты в свою сеть отправляет непосредственно в кадрах канального уровня, адресованных получателям, а пакеты в удаленные сети отправляет единственному доступному маршрутизатору по умолчанию. Но в данном случае узлу доступно два маршрутизатора, при чем через каждый из них пролегают маршруты в разные сети. Это значит, что перед узлом стоит серьезная задача о маршрутизации пакетов: узел должен правильно определять, на какой из маршрутизаторов (192.168.0.253 или 192.168.0.254) отправлять пакеты в ту или иную сеть. А следовательно, вместо простой таблицы маршрутизации, узел должен иметь полноценную таблицу маршрутизации, в которой были бы описаны маршруты ко всем сетям составной сети. Удобно ли конфигурировать узел таким образом? А сотни узлов? Разумеется, необходимо избегать сложного конфигурирования узлов, так как этих узлов МНОГО, что же делать? На самом деле решение очень простое – необходимо просто указать в настройках узла в качестве шлюза по умолчанию один из маршрутизаторов: или 192.168.0.253 или 192.168.0.254. Предположим для определенности, что узлу указан в качестве шлюза по умолчанию маршрутизатор 192.168.0.253, и следовательно все пакеты в удаленные сети узел передает именно маршрутизатору R1. Если узлу необходимо отправить пакет в сеть «слева» то этот пакет передается как раз нужному маршрутизатору – сети слева доступны как раз через маршрутизатор R1. А если нужно передать пакет в сеть «справа»? В соответствии с оговоренными выше настройками такой пакет тоже передается маршрутизатору R1. Что он с ним делает? Ответ очевиден – ищет в своей таблице маршрутизации запись о маршруте к данной сети «справа» и передает пакет следующему маршрутизатору – а именно R2. Т.е. ничего страшного не произошло – пакеты в сети «справа» все равно попадут на маршрутизатор R2. Это не совсем экономично с точки зрения трафика – по сути, в сети 192.168.0.0 пакет передается дважды – сначала от узла на R1, а затем от R1 к R2. Зато мы упростили настройку узлов – это важнее, чем экономия трафика в данном случае (если не важнее, то можно конфигурировать таблицу маршрутизации на каждом узле – пожалуйста, никто не запрещает ). Итого, при обычных настройках узла все работает, правда не совсем оптимально. А можно ли добиться оптимальности в такой ситуации? Именно для этого и применяется сообщение ICMP с типом 5 – сообщение о перенаправлении.  Его шлют маршрутизаторы в том случае, если понимают, что узел ОТПРАВИТЕЛЬ и адрес СЛЕДУЮЩЕГО маршрутизатора в одной сети – следовательно, узел отправитель мог САМ передать пакет следующему маршрутизатору, не задействуя данный, тот, который и шлет сообщение о перенаправлении. При этом маршрутизаторы не уничтожают перенаправляемый пакет, а маршрутизируют его обычным образом. Формат сообщения о перенаправлении:

Type = 5

Code

Checksum

Gateway Internet Address

IP заголовок перенаправляемого пакета и первые 8 байт данных этого пакета.

Всего от 28 до 68 байт данных

Получив такой пакет, узел анализирует его и из цитируемого заголовка пакета, который рекомендовано перенаправлять делает вывод: пакеты КОМУ впредь следует передавать новому маршрутизатору, а из поля «Gateway Internet Address» узнает, какому именно маршрутизатору следует передавать пакет для данного получателя впредь.

ICMP сообщение данного типа изначально использовало 4 различных кода:

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

1 – перенаправление пакетов к хосту. Получивший данное сообщение о перенаправлении, должен все пакеты к тому узлу, в ответ на пакет которому получено сообщение, впредь передавать указанному в сообщении маршрутизатору. Именно это сообщение рекомендуется посылать современным маршрутизаторам вместо сообщения о перенаправлении в сеть, узлам же рекомендуется сообщения с кодом 0 обрабатывать как сообщения с кодом 1.

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

3 – перенаправление пакетов к хосту для данного типа обслуживания (TOS). Это сообщение рекомендует перенаправлять впредь все пакеты данному узлу (в ответ на пакет, к которому получено сообщение) через указанный в сообщении маршрутизатор.

Сообщения с кодами 2 и 3 используются редко, так как современные маршрутизаторы редко поддерживают обработку поля TOS и, тем не менее, определены в стандарте RFC792.

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

 

Рассмотрим таблицу маршрутизации узла 192.168.0.89 для вышеописанной сети:

C:\>route print

===========================================================================

Список интерфейсов

0x1 ........................... MS TCP Loopback interface

0x2 ...00 02 44 08 ef 7e ...... Realtek RTL8139 Family PCI Fast Ethernet NIC

===========================================================================

===========================================================================

Активные маршруты:

Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика

         0.0.0.0          0.0.0.0    192.168.0.253    192.168.0.89       20

       127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1

     192.168.0.0    255.255.255.0     192.168.0.89    192.168.0.89       20

    192.168.0.89  255.255.255.255        127.0.0.1       127.0.0.1       20

   192.168.0.255  255.255.255.255     192.168.0.89    192.168.0.89       20

       224.0.0.0        240.0.0.0     192.168.0.89    192.168.0.89       20

 255.255.255.255  255.255.255.255     192.168.0.89    192.168.0.89       1

Основной шлюз:       192.168.0.253

===========================================================================

Обратите внимание на наличие маршрута по умолчанию через левый маршрутизатор. Левый маршрутизатор содержит маршрут в сеть 5.0.0.0/8, рассмотрим трафик при обращении к узлу 5.0.0.100 с консоли узла 192.168.0.89. При условии, что операционная система узла 192.168.0.89 – Windows Server, трафик имеет вид (файл REDIRECT1.cap):

Рассмотрим пакет с сообщением о перенаправлении.

Пакет имеет тип Перенаправление к узлу, содержит адрес шлюза, через который маршрутизатор, отправляющий сообщение, просит перенаправлять пакеты (на 192.168.0.254). В заголовке цитируемого пакета присутствует адрес получателя, из которого узлу 192.168.0.89 должно быть ясно, кому именно перенаправлять пакеты через новый маршрутизатор. Следовательно,  левый маршрутизатор не уничтожает пакет, а перенаправляет его на правый маршрутизатор. 

Обратите внимание на оставшуюся часть трафика - никакого перенаправления на самом деле не происходит: станция 192.168.0.89 следующий пакет для станции 5.0.0.100 снова шлет на левый маршрутизатор и весь трафик повторяется! При этом таблица маршрутизации узла 192.168.0.89 не меняется. Почему? Дело в том, что не каждая операционная система по умолчанию принимает к сведению сообщения о перенаправлении. Windows Server, настроенный по умолчанию игнорирует подобные сообщения, а Windows Professional, напротив, по умолчанию принимает такие сообщения. Каким образом происходит конфигурация? В графическом интерфейсе пользователя или с помощью консольных утилит этого сделать нельзя, но можно исправлением значения ключа реестра:

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableICMPRedirect

Значение 0 – отказ от обработки сообщений о перенаправлении, значение 1 – принимать сообщения о перенаправлении к сведению. Для того чтобы изменения данного параметра вступили в силу необходимо перезагрузить Windows. 

Работа протокола IP после описанных переконфигураций на узле  192.168.0.89 имеет вид (файл REDIRECT2.cap):

В данном случае маршрутизатор слева посылает только один redirect, после чего станция 192.168.0.89 все пакеты для 5.0.0.100 перенаправляет на маршрутизатор справа. При этом таблица маршрутизации узла 192.168.0.89 изменяется после получения сообщения о перенаправлении:

C:\>route print

===========================================================================

Список интерфейсов

0x1 ........................... MS TCP Loopback interface

0x2 ...00 02 44 08 ef 7e ...... Realtek RTL8139 Family PCI Fast Ethernet NIC

===========================================================================

===========================================================================

Активные маршруты:

Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика

         0.0.0.0          0.0.0.0    192.168.0.253    192.168.0.89       20

       5.0.0.100  255.255.255.255    192.168.0.254    192.168.0.89       1

       127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1

     192.168.0.0    255.255.255.0     192.168.0.89    192.168.0.89       20

    192.168.0.89  255.255.255.255        127.0.0.1       127.0.0.1       20

   192.168.0.255  255.255.255.255     192.168.0.89    192.168.0.89       20

       224.0.0.0        240.0.0.0     192.168.0.89    192.168.0.89       20

 255.255.255.255  255.255.255.255     192.168.0.89    192.168.0.89       1

Основной шлюз:       192.168.0.253

===========================================================================

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

Сообщения Тип 9, Тип 10.

Сообщения типа 9 и 10 представляют собой пару сообщений, используемых совместно, и называются Router Advertisement (объявления маршрутизаторов) и Router Solicitation (обнаружение маршрутизаторов) и описаны в RFC1256.

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

Для каждого маршрутизатора указывается метрика, т.е. уровень предпочтения узлом данного маршрутизатора. А каким образом узел будет понимать, что один из маршрутизаторов вышел из строя и необходимо перейти на использование другого маршрутизатора? Для решения этой задачи узлу необходимо знать, функционирует ли маршрутизатор, однако маршрутизатор в процессе своей работы НЕ отправляет никаких пакетов, подчеркивающих его работоспособности. Решение очевидно – необходимо отправлять через некоторые временные интервалы ICMP эхо запросы на маршрутизатор, и если он отвечает, то он в порядке. К сожалению, такой способ не выдерживает критики: если неисправен маршрутизатор, способ будет работать, а если неисправна сеть, связывающая данный маршрутизатор с внешним миром или, еще хуже, неисправен один из следующих за данным маршрутизаторов – тогда данный способ совершенно лишен смысла. Единственное, что может служить гарантией того, что маршрутизатор работает – это обмен данных через него. Как же убедиться в том, что маршрутизатор и остальные транзитные маршрутизаторы работают? Только штатным обменом данных. Для решения этой задачи предусмотрен специальный протокол FIRP (Fault Isolation Recovery Protocol), описанный в RFC816. Этот протокол  является набором правил поведения узлов (и маршрутизаторов), он не имеет собственного заголовка, а представляет собой лишь способ поведения узла. Протокол поддерживается в Windows и называется Dead Gateway Detection – обнаружение «мертвых» шлюзов. Суть его состоит в том, что узел, у которого настроено использование нескольких маршрутизаторов ведет статистику для TCP соединений об отправленных данных и не пришедших квитанциях. Данный механизм работает ТОЛЬКО для TCP и не работает для UDP и ICMP, и вот почему: TCP – протокол с гарантией доставки, отсутствие квитанций TCP – прямое указание на отказ, в то время как протоколы UDP и ICMP работают без гарантии доставки и вообще говоря потеря пакетов этих протоколов – явление трудно контролируемое.

Протокол FIRP в Windows работает следующим образом: когда в рамках TCP соединения пакеты повторяются более чем 50 % от величины, определяющей максимальное количество попыток повтора, то для ЭТОГО соединения используется второй (следующий) по списку маршрутизатор. Если же более 25 % TCP соединений используют альтернативный маршрутизатор, то в таком случае этот маршрутизатор становится используемым по умолчанию для всех новых передач данных (включая и TCP и UDP и ICMP). Как включить в Windows использование Dead Gateway Detection? Для этого необходимо править ключ реестра:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\EnableDeadGWDetect

Значение ключа = 0  означает отказ от использования этой технологии, значение = 1 включает использование вышеописанного алгоритма.

Какое отношение имеет FIRP к рассматриваемой теме? Дело в том, что FIRP – одно из решений, есть и второе решение проблемы - использования альтернативных шлюзов и это решение базируется на ICMP сообщениях типа 9 и 10.

Положим, что мы вообще не хотим сообщать статически адреса маршрутизаторов узлам, а хотим, чтобы они узнавали актуальные адреса работающих маршрутизаторов от самих маршрутизаторов. Для этого необходимо научить маршрутизаторы заявлять о себе, и для этого используются ICMP сообщения типа 9. Если маршрутизаторы будут периодически широковещательно (или с помощью группового вещания) рассылать подобные сообщения, то узлы, получающие эти сообщения будут узнавать о доступных маршрутизаторах. При этом в пакете ICMP типа 9 предусмотрено объявление уровня предпочтения данного маршрутизатора, на случай, чтобы узлы при доступности нескольких маршрутизаторов выбирали тот, который хотел бы использовать администратор, конфигурирующий заранее уровень предпочтений каждого маршрутизатора. Кроме того, должны существовать механизмы обновления сведений о доступности маршрутизатора и устаревания сведений о маршрутизаторе.

Например: маршрутизатор доступен, но одно его объявление потерялось – это не должно приводить к тому, что узлы перестают пользоваться данным маршрутизатором, однако если маршрутизатор не объявляет о себе в течение длительного времени, узлы должны переставать использовать данный маршрутизатор. Это реализуется следующим образом: при конфигурировании маршрутизатора администратор указывает ему частоту, с которой он сообщает о себе в сети, а так же указывает время жизни объявления данного маршрутизатора, которое маршрутизатор включает в ICMP сообщение типа 9. Таким образом, узел, получая от маршрутизатора ICMP сообщение типа 9 узнает из этого сообщения адрес маршрутизатора (IP адрес отправителя сообщения из IP заголовка, в ICMP заголовке не указывается), уровень предпочтения (т.е. какой маршрутизатор использовать, если заявляют о себе несколько маршрутизаторов) и время жизни данного объявления, т.е. как долго можно пользоваться данным маршрутизатором. И если маршрутизатор будет продолжать оставаться исправен, то он будет слать новые объявления, которые снова будут запускать новый таймер времени жизни). Рассмотрим формат ICMP сообщения типа 9:

Type = 9

Code  = 0

Checksum

Num Addrs

Addr Entry Size

Lifetime            

Router Address[1]

Preference Level[1]

Router Address[2]

Preference Level[2]

И так далее …

Поле Num Addrs показывает количество объявлений в данном ICMP сообщении.

Поле Addr Entry Size показывает длину одного объявления в четырехбайтовых словах, в текущей реализации протокола это поле равно 2.

Поле Lifetime показывает время жизни данного объявления.

Поле Router Address[Х] показываем IP адрес соответствующего объявляемого маршрутизатора.

Поле Preference Level[Х] показывает уровень предпочтения соответствующего маршрутизатора.

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

Type = 10

Code  = 0

Checksum

Не используется

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

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

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

Пример включения объявления маршрутизатора в Windows:

Вместо одного времени объявление применяется два времени: минимальное и максимальное (для того, чтобы не было резонанса объявлений и сильного трафика в момент объявлений).

По умолчанию Windows НЕ использует клиентскую часть этой технологии, т.е. если у узла не указан шлюз по умолчанию и в сети есть маршрутизаторы, поддерживающие Router Advertisement, то узел не станет пользоваться этими объявлениями. Если убрать в настройках узла адрес шлюза по умолчанию и включить на маршрутизаторе объявления маршрутизатора, то узел не использует этих объявлений.

Для включения на узле поддержки поиска маршрутизаторов с помощью ICMP, необходимо править ключ реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<interface>PerformRouterDiscovery

Значение ключа = 1 означает использование узлами технологии поиска маршрутизаторов, значение = 0 – отказ от использования данной технологии и игнорирование обнаружения маршрутизаторов.  

Станция, настроенная на использование динамического поиска маршрутизатора, не имея статически настроенного адреса шлюза по умолчанию, тем не менее, имеет этот адрес, полученный динамически. Рассмотрим трафик в анализаторе, из которого видно, что маршрутизатор объявляет о себе (файл RA.cap) и в ответ на пакет Router Solicitation маршрутизатор отвечает пакетом Router Advertisement (файл RS.cap):

Обмен данными в рамках ICMP типа 9 и 10 происходит с использованием групповых IP адресов (класса D). Сообщение типа 9 (Объявление маршрутизатора) посылаются по групповому адресу 224.0.0.1, который используется всеми узлами сети, а сообщения типа 10 (Обнаружение маршрутизатора) отсылается по групповому адресу 224.0.0.2 – все маршрутизаторы сети.

Совокупность ICMP сообщений типа 9 и 10 так же называют протоколом IRDP (Internet Router Discovery Protocol) и под таким названием эта технология может использоваться в маршрутизаторах и операционных системах.

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

Далее рассмотрим сообщения типа 11. Такие ICMP сообщения называются Time Exceeded и сообщают отправителю пакета об истечении времени жизни  отправленного пакета. Формат данного сообщения:

Type = 11

Code  

Checksum

Не используется, равно 00 00

IP заголовок уничтоженного пакета и первые 8 байт данных этого пакета.

Всего от 28 до 68 байт данных

Сообщения типа 11 могут иметь два различных значения поля Код:

0 - Time to live exceeded in transit (Время жизни пакета истекло при транспортировке). Такое сообщение посылают только маршрутизаторы в том случае, если у полученного для перенаправления пакета TTL становиться равным нулю. В таком случае маршрутизатор уничтожает пакет, и с помощью ICMP сообщения с типом 11 и кодом 0 уведомляет об этой ситуации отравителя пакета, цитируя в сообщении заголовок и первые 8 байт уничтоженного пакета. Поле TTL используется для предотвращения зацикливания пакетов при образовании маршрутных петель.

1 - Fragment reassembly time exceeded (Истекло время жизни пакета при попытке сборки пакета из фрагментов). Так как собирают пакеты из фрагментов только узлы и никогда маршрутизаторы, такое ICMP сообщение могут посылать только конечные узлы получатели пакета. Когда станция получает фрагменты одного пакета, она складывает их в буфер и пытается собрать фрагментированный пакет. Однако если некоторых фрагментов недостает, станция, очевидно, не будет ждать прихода недостающих фрагментов вечно, занимая память под хранение фрагментов неполного пакета. При этом станция ожидает в течение некоторого времени, зависящего от реализации стека TCP/IP, на станции и если возможности собрать пакет нет, то фрагменты уничтожаются и отправителю пакета посылается ICMP сообщение.

Наибольший диагностический интерес представляет именно сообщение об истечение времени жизни в транзите вследствие истечения TTL пакета, так как с помощью этого сообщения можно провести диагностику маршрутных петель. Рассмотрим работу ICMP сообщения типа 11 с кодом 0:

На маршрутизаторе R1 должна быть запись о маршруте в сеть 5.0.0.0 вида:

Network  Mask   Gateway

5.0.0.0   255.0.0.0  1.0.0.2

На маршрутизаторе R2 должна быть запись о маршруте в сеть 5.0.0.0 вида:

Network  Mask   Gateway

5.0.0.0   255.0.0.0  1.0.0.1

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

Network  Mask   Gateway

5.0.0.0   255.0.0.0  2.0.0.2

В таком случае если на маршрутизатор R1 поступит пакет в сеть 5.0.0.0, то этот пакет будет перенаправлен на маршрутизатор R2, а тот в свою очередь снова передаст его маршрутизатору R1. И так будет продолжаться до тех пор, пока у пакета не истечет TTL.

Рассмотрим  ICMP сообщения об истечении времени жизни в транзите (файл TEiT.cap).

В  цитируемом пакете TTL всегда будет равен 1, так как именно это и является причиной для уничтожения пакета.

Однако практическое применение данного ICMP сообщения не ограничивается диагностикой маршрутных петель. Рассмотрим следующий пример:

Что будет, если станция пошлет другой станции пакет (например, эхо запрос), при этом установит в данном пакете поле TTL = 1. Разумеется, первый же маршрутизатор уничтожит данный пакет и пошлет отправителю пакета ICMP сообщение об уничтожении пакета вследствие истечения TTL (разумеется, это не буде сигнализировать о реальной маршрутной петле) от своего имени. Из данного пакета станция, пославшая исходный пакет может получить крайне полезную информацию, а именно, IP адрес ПЕРВОГО маршрутизатора по пути следования к станции, к которой был послан исходный пакет. Затем, станция отправитель пакетов, выяснив адрес первого маршрутизатора может послать пакет той же станции, но с полем TTL в заголовке IP равном 2. Тогда пакет пройдет первый маршрутизатор и будет уничтожен вторым, который пошлет отправителю ICMP сообщение типа 11, но, в этом случае - от СВОЕГО имени, и таким образом станция отправитель узнает адрес второго маршрутизатора в направлении той станции, которой послан исходный пакет. Посылая пакеты, с увеличивающимся на единицу TTL, станция может из IP заголовков ICMP пакетов узнать все адреса всех портов маршрутизаторов, которое должен пересечь пакет, посланный в направлении некоторой станции. Сигналом к тому, что все маршрутизаторы узнаны, будет служить приход в ответ на посланный эхо запрос эхо ответа, а не сообщения ICMP типа 11. При этом, разумеется, маршрутизатор в этом случае отправляет сообщения ICMP от адреса того порта, которым принял пакет – действительно, зачем искать выходной порт, если пакет не нуждается в маршрутизации?

Подобное исследование сети производится при помощи утилиты ping.exe, которая позволяет устанавливать произвольный TTL у отправляемых пакетов. Рассмотрим пример выяснение нескольких ближайших портов в направлении некоторого узла:

C:\>ping -n 1 -i 1 mail.alkar.net

Обмен пакетами с mail.alkar.net [195.248.191.95] по 32 байт:

Ответ от 192.168.0.1: Превышен срок жизни (TTL) при передаче пакета.

C:\>ping -n 1 -i 2 mail.alkar.net

Обмен пакетами с mail.alkar.net [195.248.191.95] по 32 байт:

Ответ от 212.86.234.25: Превышен срок жизни (TTL) при передаче пакета.

C:\>ping -n 1 -i 3 mail.alkar.net

Обмен пакетами с mail.alkar.net [195.248.191.95] по 32 байт:

Ответ от 212.86.227.110: Превышен срок жизни (TTL) при передаче пакета.

C:\>ping -n 1 -i 4 mail.alkar.net

Обмен пакетами с mail.alkar.net [195.248.191.95] по 32 байт:

Ответ от 212.86.227.98: Превышен срок жизни (TTL) при передаче пакета.

Однако такой способ достаточно громоздкий и явно требует автоматизации. Для решения этой задачи без постоянного участия пользователя, в Windows (как в почти в любой операционной системе, поддерживающей TCP/IP) существует специальная утилита, причем в MS Windows их две: tracert.exe и pathping.exe. Рассмотрим для начала работу утилиты tracert.exe:

C:\>tracert mail.alkar.net

Трассировка маршрута к mail.alkar.net [195.248.191.95]

с максимальным числом прыжков 30:

 1    <1 мс    <1 мс    <1 мс  192.168.0.1

 2    11 ms    13 ms    21 ms  neo-tele.com [212.86.234.25]

 3    38 ms    11 ms    30 ms  ww1-od.alkar.net [212.86.227.110]

 4    13 ms    13 ms    21 ms  FC1-OD.alkar.net [212.86.227.98]

 5    22 ms    24 ms    37 ms  SE1-2.FC1-DP.alkar.net [212.86.227.69]

 6   114 ms    63 ms    92 ms  psie-gw.a-teleport.com [212.86.227.37]

 7   102 ms    92 ms    64 ms  EM0.WW1-DP.alkar.net [195.248.191.129]

 8    67 ms    84 ms    81 ms  mail.alkar.net [195.248.191.95]

Трассировка завершена.

Изучим вышеприведенный трафик в анализаторе (tracert1.cap):

Утилита tracert.exe  в MS Windows посылает в «трассирующих» IP пакетах эхо запросы, при этом, сигналом к окончанию трассировки служит приход эхо ответа вместо сообщения типа 11. Однако возможны и другие реализации, например, можно посылать UDP пакета на произвольный порт, тогда сигналом к окончанию трассировки будет приход ICMP Destination Unreachable, Port  Unreachable. Пакеты посылаются с каждым значением TTL по три раза, кроме того, программа пытается выяснить символьные имена маршрутизаторов. Для того чтобы не выяснять символьных имен, необходимо использовать ключ –d:

C:\>tracert -d mail.alkar.net

Трассировка маршрута к mail.alkar.net [195.248.191.95]

с максимальным числом прыжков 30:

 1    <1 мс    <1 мс    <1 мс  192.168.0.1

 2    16 ms    11 ms    14 ms  212.86.234.25

 3    15 ms    12 ms    12 ms  212.86.227.110

 4    15 ms    25 ms    22 ms  212.86.227.98

 5    29 ms    42 ms    25 ms  195.248.160.253

 6   120 ms   115 ms    70 ms  212.86.227.37

 7    44 ms    36 ms    73 ms  195.248.191.129

 8    36 ms    77 ms    66 ms  195.248.191.95

Трассировка завершена.

Сравнивая эти две трассировки маршрута видно, что пакеты не всегда передаются по одному и тому же маршруту – так как маршрутизаторы в списках отличаются. По умолчанию, tracert.exe делает попытки выяснить лишь первые 30 маршрутизаторов, но с помощью ключа –h можно установить желаемое значение, хоть и 255. Послав эхо запрос, tracert.exe ждет ответа оговоренное количество времени, это время можно регулировать ключом –w. Так же возможно с помощью tracert.exe посылать пакеты с опцией LSRR, используя ключ –j (посылать пакеты с опцией SSRR нет смысла – в этом случае маршрут и так жестко определен и известен отправителю).   

Недостаток утилиты tracert.exe:

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

В качестве альтернативы данной утилите в Windows есть еще одна утилита pathping.exe :

C:\Documents and Settings\Администратор>pathping mail.alkar.net

Трассировка маршрута к mail.alkar.net [195.248.191.95]

с максимальным числом прыжков 30:

 0  caesar [192.168.0.89]

 1  192.168.0.1

 2  neo-tele.com [212.86.234.25]

 3  ww1-od.alkar.net [212.86.227.110]

 4  FC1-OD.alkar.net [212.86.227.98]

 5  SE1-1.CORE1-KV.alkar.net [195.248.160.253]

 6  psie-gw.a-teleport.com [212.86.227.37]

 7  EM0.WW1-DP.alkar.net [195.248.191.129]

 8  mail.alkar.net [195.248.191.95]

Подсчет статистики за: 200 сек. ...

          Исходный узел     Маршрутный узел

Прыжок  RTT   Утер./Отпр.   %   Утер./Отпр.  %   Адрес

 0                                           caesar [192.168.0.89]

                               0/ 100 =  0%   |

 1    0мс     0/ 100 =  0%     0/ 100 =  0%  192.168.0.1

                               0/ 100 =  0%   |

 2   32мс     3/ 100 =  3%     3/ 100 =  3%  neo-tele.com [212.86.234.25]

                               0/ 100 =  0%   |

 3   32мс     3/ 100 =  3%     3/ 100 =  3%  ww1-od.alkar.net [212.86.227.110]

                               0/ 100 =  0%   |

 4   41мс     2/ 100 =  2%     2/ 100 =  2%  FC1-OD.alkar.net [212.86.227.98]

                               0/ 100 =  0%   |

 5   56мс     3/ 100 =  3%     3/ 100 =  3%  SE1-1.CORE1-KV.alkar.net [195.248.

160.253]

                               0/ 100 =  0%   |

 6  107мс     0/ 100 =  0%     0/ 100 =  0%  psie-gw.a-teleport.com [212.86.227.37]

                               2/ 100 =  2%   |

 7  276мс    44/ 100 = 44%    42/ 100 = 42%  EM0.WW1-DP.alkar.net [195.248.191.129]

                               0/ 100 =  0%   |

 8  103мс     2/ 100 =  2%     0/ 100 =  0%  mail.alkar.net [195.248.191.95]

Трассировка завершена.

Изучим трафик в анализаторе (path1.cap):

Метод трассировки маршрута тот же, что и в tracert.exe – с помощью ICMP сообщений типа 11.

Обратите внимание на следующие особенности:

  •  pathping.exe гораздо быстрее показываем список маршрутизаторов, так как не отправляет фиксировано 3 пакета с одним и тем же TTL, а, получив хотя бы один ответ, увеличивает TTL на единицу.
  •  pathping.exe после нахождения всех маршрутизаторов проверяет вероятность потери пакетов для каждого из них, обмениваясь с каждым из транзитных маршрутизаторов большим количеством эхо пакетов и собирая статистику о потерянных пакетах. С одной стороны это – мощное и полезное диагностическое средство, с другой стороны сбор такой статистики, особенно учитывая длительность этой операции – не самая желательная процедура при каждой трассировке маршрута.

Ключ –q задает желаемое количество посылаемых пакетов, что позволяет уменьшить время ожидания до минимума.

Ключ –n выключает разрешения ip адреса в имя узла.

C:\>pathping mail.alkar.net -n

Tracing route to mail.alkar.net [195.248.191.95]

over a maximum of 30 hops:

 0  10.1.12.1

 1  10.1.0.160

 2  193.109.166.33

 3  193.109.164.171

 4  193.109.166.118

 5  195.128.226.250

 6  212.86.224.17

 7  195.248.191.33

 8  195.248.191.95

Computing statistics for 200 seconds...

Ключ –w задает таймаут для ожидаемых ответов.

Недостаток утилиты pathping.exe:

  •  при трассировке маршрута, если какой то маршрутизатор не ответил за три попытки (а их число, как для tracert.exe) нельзя менять, то pathping.exe вообще прекращает дальнейшую трассировку, что весьма неудобно.

Сравним методы выяснения транзитных маршрутизаторов по пути следования пакетов с помощью опции RR и с помощью ICMP типа 11.

  •  с помощью RR обычно узнают «дальние» от отправителя порты маршрутизатора (хотя мы рассматривали, как с помощью RR узнавать адреса и «ближних» портов, с помощью ICMP можно узнать лишь только адреса «ближних» портов.
  •  С помощью RR можно узнать адреса длишь ограниченного количества маршрутизаторов (не более 9), с помощью ICMP – до 255 маршрутизаторов (а больше и не может быть из-за ограничения длины поля TTL).
  •  С помощью RR вся информация о маршрутизаторах сосредоточена в одном пакете, при использовании ICMP адрес каждого маршрутизатора приходится узнавать отдельным пакетом.
  •  С помощью RR не возможно узнать маршрут к не отвечающему узлу, с помощью ICMP – можно.

Два вышеописанных инструмента могут взаимно дополнят друг друга при выяснении маршрута следования пакетов. Чаще бывают ситуации, когда пользуются ICMP типа 11, но при необходимости выяснить адреса «дальних» от отправителя портов маршрутизаторов RR – единственный инструмент. Кроме того, два этих инструмента можно употребить для частичной взаимной проверки, например, если некоторый маршрутизатор, вписывает два адреса в RR вместо одного, это можно легко выяснить с помощью ICMP, так же бывают ситуации, когда, например, ICMP сообщения типа 11 запрещены администратором сети и тогда остается пользоваться RR. Приведенный выше пример, говорит о том, что важно уметь пользоваться обоими средствами с целью сетевой диагностики в различных ситуациях.

Переходим к сообщениям следующего типа - Тип 12.

Сообщения этого типа посылаются в ответ на пакеты, имеющие ошибки в заголовке и называются Parameter Problem.

Формат данной опции:

Type = 12

Code  

Checksum

Pointer

Не используется

IP заголовок уничтоженного пакета и первые 8 байт данных этого пакета.

Всего от 28 до 68 байт данных

В RFC792 описан только один код при значении типа = 12, этот код = 0 и означает, что в заголовке есть некоторая ошибка. При этом однобайтовое поле Pointer (указатель) показывает номер байта, в котором произошла ошибка. Во многих случаях стек TCP/IP не отправляет ICMP сообщения типа 12 в ответ на ошибочные пакеты, например, при неверном значении поля контрольной суммы, неверном значение поля Total Length и т.п. Посылать ли в ответ на такие пакеты сообщение ICMP об ошибке обычно решает автор стека – в RFC нет четких указаний, в ответ на какие именно ошибки необходимо посылать ICMP сообщения типа 12. В конечном счете, решение о том, посылать или не посылать ICMP пакет типа 12 принимается исходя из текущих условий – станция может послать сообщение типа 12 на пакет вполне нормальный с очки зрения других станций, но не подходящий для данной станции.

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

Начнем с начала: поле Version, как мы знаем, это поле предназначено для указания версии используемого протокола IP и, не смотря на то, что мы занимаемся только лишь IP версии 4, тем не менее, это поле может принимать и другие значения. Поле IHL не может принимать значение меньше 5, однако в ответ на IP пакеты с полем IHL <5 большинство операционных систем не посылает ICMP сообщений типа 12. Поле TOS может принимать лишь ограниченный набор значений, однако, в новых RFC могут появиться новые интерпретации комбинаций флагов (как, например, появилась интерпретация комбинации DTRC как максимизация безопасности передачи). Поле Total Length может принимать любые значения, но не менее 20 байт (заголовок IP), однако при ошибках в этом поле так же, обычно, ICMP сообщения типа 12 не посылаются. Поле ID может принимать все возможные значения, как и поле Offset. Анализ возможности ошибок оставшейся стационарной  части заголовка, показывает что особенных явных ошибок в этой части заголовка сделать нельзя (помимо указанных выше). Однако есть еще опции, в которых можно допустить ряд ошибок, самая характерная их ниx – неверное значение поля Pointer. Например, в опции RR поле Pointer не может быть меньше 4.

Рассмотрим пример пакета с опцией RR и установленным значение указателя равным 1 (файл PP1.cap):

В ответ приходит сообщение об ошибке в заголовке, причем, указатель показывает, что ошибка имеет место в 22 байте заголовка (нумерация начинается  с нуля), т.е. байты №№0-19 – стационарная часть заголовка, байт номер 22 – третий байт перовой опции, как раз и есть наш неверный указатель.

Еще один пример: после опции RR, если других опций нет должна следовать опция EOOF, для нужд выравнивания по четырехбайтовой границе. Допустим, в этом последнем байте поля опций указали неверную и неизвестную опцию, например с номером 18. IP умеет пропускать неизвестные опции, но не в данном случае - так как после поля тип, уже никакое поле не может присутствовать в данной опции, так как поле IHL указывает на то, что заголовок уже закончен. И в этом случае посылается ICMP сообщение типа 12 с кодом 0 (файл PP2.cap):

Еще один пример, связанный с опциями: допустим, в заголовке установлено заведомо неверное значение поля длины той или иной опции. Это будет явно противоречить значению поля IHL в заголовке и будет послано (во многих случаях, а точнее - многими системами) сообщение о проблемах с заголовком (файл PP3.cap):

Сообщения типа 12 могут также содержать в поле Код значения 1 и 2. Значение поля код = 1 означает отсутствие в заголовке обязательной опции. Как мы знаем, нет обязательных опций заголовка, однако IP поддерживает еще несколько морально устаревших опций, в частности опцию Security, которая позволяет снабжать IP пакет сведениями о его важности и степени секретности. Если в сети обязательно требуется использование такой опции (но не в Интернет, а скорее в закрытых сетях), то отсутствие этой опции может означать невозможность коммуникаций, и тогда получатель пакета без опции Security (если она была необходима) может послать отправителю ICMP сообщение типа 12 с кодом 1, сообщая об отсутствии необходимой опции, тогда поле Pointer должно содержать значение поля Type отсутствующей опции (RFC1108).

Рассмотрим сообщения тип 13 и тип 14. Данные сообщения называются Timestamp и Timestamp Reply. С помощью данной пары ICMP сообщений станция может запросить у другой станции значение временного штампа (Тип 13) и получить ответ (Тип 14). Принцип работы данной пары сообщений напоминает принцип работы эхо запросов и эхо ответов: одна станция посылает запрос на временной штамп, другая станция отправляет ответ, в котором указывает требуемые значения. Фактически, с помощью данного сообщения так же можно проверить возможность обмена IP пакетами между станциями – если  ответ приходит, значит, обмен пакетами возможен. Однако, данные сообщения предназначены для решения несколько другой задачи, а задачу о проверке возможности обмениваться пакетами решают хуже, чем эхо запрос и эхо ответ, так как в сообщениях о временном штампе нельзя передать произвольные данные и проверит прохождение по сети пакетов произвольной длины.

Формат заголовка ICMP сообщений типа 13 и 14 совпадает с заголовком сообщений типа 8 и 0, т.е. зарезервированное поле снова содержит два поля:   Identifier и Sequence Number. Эти поля выполняют те же самые задачи: позволяют отличить приложение, пославшее запрос и отличить один посланный конкретным приложением запрос от другого. В поле данных запроса о временном штампе указывается временной штамп отправителя (в первом четырехбайтовом слове), два следующих четырехбайтовых поля заполняются нулями. Станция или маршрутизатор, получившие данный запрос, формируют ответ, в котором меняют местами отправителя и получателя IP пакета, цитируют поля Identifier и Sequence Number, цитируют временной штамп отправителя и заполняют два следующих четырехбайтовых слова следующим образом:  во втором слове устанавливается временной штамп получателя в момент получения запроса, в третьем слове устанавливается временной штамп отправителя в момент генерации ответа.

Type = 13 или 14

Code = 0

Checksum

Identifier

Sequence Number

Временной штамп отправителя

Временной штамп в момент получения запроса

Временной штамп в момент генерации ответа

Таким образом, отправитель запроса получает ответ, в котором фигурируют два временных штампа отвечающей станции, предполагалось, что отправитель пакета, таким образом, может измерить задержку, связанную с обработкой пакета самим стеком TCP/IP получателя. Если сопоставить эту информацию с изученными с помощью опции TS задержками передачи данных в отдельных сетях (использование опции TS номер 01000100bin = 68dec  с флагом 0011 позволяет регистрировать интервалы между указанными маршрутизаторами), можно разделить задержку при передаче пакета в сети на задержку на обработки самом узле и задержку распространения по исследуемой сети. Однако сегодня компьютеры столь быстры, что обычно временной штамп в момент получения запроса совпадает с временным штампом в момент получения ответа, что делает данные сообщения малополезными при работе с современными узлами и маршрутизаторами. Тем не менее, данное сообщение может оставаться полезным для проверки возможности обмениваться пакетами с некоторой станцией, если, например, администратор станции или маршрутизатора запретил обрабатывать эхо-запросы, но забыл запретить обрабатывать временные штампы.

В Windows нет встроенной утилиты для  посылки временных штампов, приведенный ниже пример, содержит созданный вручную пакет запроса временного штампа (Тип 13 код 0), и полученного от стека TCP/IP операционной системы Windows 2000 Server ответа (Тип 14 код 0):

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

Следующие сообщения имеют значения поля тип 15 и 16 и называются Information Request (Информационный запрос) и Information Reply (информационный ответ). Данные сообщения работают следующим образом: если станция не знает номера сети, в которой она находится, то она может послать информационный запрос некоторой станции своей сети в надежде получить информационный ответ. Для этого станция шлет сообщение типа 15 (Информационный запрос) при чем в поле адрес отправителя заголовка IP пакета записывает свой IP адрес следующим образом: в той части IP адреса, которая отвечает за номер сети, все биты устанавливаются равными нулю. Такой стиль использования IP адреса сам по себе сегодня является устаревшим, но в старых реализациях IP, адрес, в котором все биты, отвечающие за номер узла равны нулям, назывался адресом «в своей сети» и относился к особым адресам, как, например, номер сети. Получатель такого информационного запроса должен сгенерировать ответ, при чем в IP заголовке он должен заполнить номера сетей так, где отправитель установил нули. Формат ICMP заголовка:

Type = 15 или 16

Code = 0

Checksum

Identifier

Sequence Number

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

Следующие и последние типы сообщений, представленные к рассмотрению в уроке, это сообщения типов 17 и 18. Эти сообщения называются Address Mask Request (запрос маски) и Address Mask Reply (ответ на запрос маски) и описаны в более позднем RFC950.

С помощью этих сообщений узел, не знающий своей маски подсети, знающий или не знающий свой IP адрес может спросить у маршрутизатора или другого узла маску подсети. Так как все узлы одной подсети должны иметь одинаковую маску, то, выяснив маску одного из узлов или маршрутизаторов в своей сети, узел может сопоставить со своим IP адресом такую же маску. Данное сообщение полезно применять вместе в с протоколом RARP. RARP – это устаревший протокол, с помощью которого станция, не имеющая при старте IP адреса может получить адрес с помощью специального RARP сервера, однако с применением масок такая техника утратила смысл, так как знания только своего адреса без знания своей маски не позволяет станции работать в составной сети. Данные ICMP сообщения позволяли решить эту задачу: получив с помощью протокола RARP IP адрес, станция узнает и IP адрес RARP сервера, затем с помощью ICMP типа 17 станция может запросить у RARP сервера его маску, и, получив ответ типа 18, назначить себе такую же маску. Протокол RARP сегодня считается устаревшим, вследствие ограниченной функциональности, т.е. из-за того, что с его помощью узлу можно назначить только IP адрес и все, и даже поддержка назначения узлам масок с помощью ICMP – не достаточное решение проблемы. Сегодня применяются более совершенные протоколы для автоматизации конфигурирования IP адреса и других параметров, которые мы будем изучать в дальнейшем. Поэтому узлы и маршрутизаторы обычно не поддерживают ICMP типа 17 и 18, данные сообщения имеют скорее историческое значение.

Рассмотрим пример использования ICMP пакетов типа 17 и 18 созданный вручную, (файл AM.cap). Обратите внимание, что отправитель запроса заполняет поле маски нулями, отвечающая сторона заполняет данное поле свое маской. Но, не смотря на вышесказанное ряд узлов и маршрутизаторов, могут поддерживать ответы на запросы типа 17, что может приносить вред с точки зрения безопасности (если известна маска и хотя бы один адрес в IP сети – то можно вычислить диапазон адресов всей IP сети).

Практические задания:

  1.  Используя VMWare, отправить с помощью утилиты ping.exe сообщение типа 8 и получить в ответ сообщение типа 0. Проанализировать значения полей ID и Sequence Number запроса и ответа, убедиться в том, что значения этих полей цитируются в ответах. Убедиться, что значения поля  Sequence Number отличается от запроса к запросу. Убедиться в том, что передаваемые в  запросе данные являются произвольными и цитируются полностью в ответах.
  2.  Построить сеть, в которой можно получить сообщения о недостижимости узла и/или сети, используя VMWare. Убедиться, что маршрутизатор в Windows не посылает сообщения о недостижимости узла в случае, если узел не отвечает на ARP запросы, и посылает сообщения о недостижимости узла в случае недостижимости сети (вспомнить, почему именно так и нужно поступать). Убедиться, что при уничтожении пакета вследствие недостижимости узла в пакете типа 3 цитируется заголовок уничтоженного пакета, из анализа которого станция отправитель исходного пакета делает выводы о том, какой именно узел недостижим.
  3.  Сгенерировать с помощью произвольного генератора пакет, в ответ на который будет отправлено сообщение о недостижимости протокола. Проанализировать полученное сообщение.
  4.  Сгенерировать с помощью произвольного генератора пакет, в ответ на который будет отправлено сообщение о недостижимости порта. Проанализировать полученное сообщение.
  5.  Построить сеть, в которой могут использоваться сообщения о перенаправлении, используя VMWare. Сконфигурировать узел, отправляющий пакеты (в ответ на которые мы ждем сообщений о перенаправлении) таким образом, чтобы он не принимал к сведению этих сообщений, проанализировать трафик. Сконфигурировать узел, отправляющий пакеты (в ответ на которые мы ждем сообщений о перенаправлении) таким образом, чтобы он использовал сообщения о перенаправлении, проанализировать трафик, проанализировать таблицу маршрутизации узла.
  6.  Используя VMWare, сконфигурировать маршрутизатор таким образом, чтобы он работал с сообщением типа 9 Объявления маршрутизаторов. Сконфигурировать станцию таким образом, чтобы она не принимала объявлений маршрутизаторов и не имела адреса шлюза по умолчанию. Убедится в невозможности станции иметь коммуникации с удаленными узлами. Проанализировать формат сообщения типа 9 о перенаправлении. Переконфигурировать станцию так, чтобы она использовала технику IRDP, убедиться в том, что станция получает динамически адрес шлюза по умолчанию. Проанализировать формат пакета типа 10, проанализировать, как в ответ на сообщения типа 10 маршрутизатор отвечает сообщениями типа 9.
  7.  Используя VMWare, построить сеть, в которой сконфигурировать маршрутизатор таким образом, чтобы получилась маршрутная петля. Захватив трафик в петле, убедиться в ее наличии, захватить трафик, содержащий сообщения типа 11 от маршрутизатора, информирующий узел о наличии маршрутной петли. При выполнении задания использовать утилиту ping c ключом –I следующим образом.

Пример со стороны Клиента:

C:\>ping 12.0.0.1 –i 3

Т.е. после флага -i указывается любое нечетное число, тогда Сервер отвечает об уничтожении пакета в связи с истечением времени жизни. Если же указать четное число – то сигнализировать будет Клиент

  1.  Используя утилиты tracert.exe и pathping.exe проанализировать принцип их работы по определению маршрута к удаленному хосту в Интернет. Провести сравнительный анализ утилит tracert.exe и pathping.exe, сделать выводы об областях применения этих утилит. Провести исследование сети провайдера, используя ICMP сообщения типа 11 и опцию RR, идентифицировать адреса портов маршрутизаторов провайдера, построить примерную схему сетей провайдера. Сравнить диагностические возможности, предоставляемые  ICMP сообщениями типа 11 и опцией RR.
  2.  Сгенерировать с помощью произвольного генератора пакетов ошибочные пакеты вида:
  •  Неверная длина опции
  •  Неверный указатель в опции
  •  Опция с неверным форматом

Проанализировать полученные ICMP сообщения типа 12, проанализировать использование поля Указатель в этих пакетах.

  1.  Сгенерировать с помощью произвольного генератора пакетов ICMP сообщение типа 13 Запрос временного штампа, получить ответ от станции, проанализировать трафик, проанализировать, для чего сегодня могут быть полезны такие сообщения.


 

А также другие работы, которые могут Вас заинтересовать

51203. Аналитическое моделирование дискретно-стохастической СМО 241.97 KB
  Цель: Построить граф состояний СМО . Смысл кодировки состояний раскрыть (время до выдачи заявки, число заявок в накопителе и т.д.). На схеме условно обозначены
51204. Построение аналитической и имитационной модели одноканальной СМО с неограниченной очередью и ее исследование 56.42 KB
  Цель: Имеется n-канальная СМО с неограниченной очередью. Входной поток и поток обслуживаний - простейшие с интенсивностями и соответственно. Время пребывания в очереди ограничено случайным сроком , распределенным по показательному закону с математическим ожиданием...
51206. Построение синтаксического дерева 53.35 KB
  Включить в синтаксический анализатор из лабораторной работы №.3 построение синтаксического дерева. Использовать атрибутный метод Кнута, т.е. преобразовать КС–грамматику из лабораторной работы № 3 в атрибутную грамматику добавлением атрибутов и правил построения синтаксического дерева. Расширить программу синтаксического анализатора из лабораторной работы...
51207. Разработка контекстного анализатора 48.83 KB
  Для предложенного преподавателем варианта контекстного условия расширить атрибутную грамматику из лабораторной работы № 4 добавлением атрибутов, правил их вычисления, правил вычисления контекстных условий. Включить в программу синтаксического анализатора из лабораторной работы № 4 действия по вычислению атрибутов и проверки контекстных условий.
51210. Побудова багаточлена Лагранжа. Складання програми 41.21 KB
  Мета. Навчитися будувати багаточлен Лагранжа, скласти програму. Обладнання. Лист формату А4, ручка, ПК, програмне забезпечення С++. Хід роботи Правила ТБ Теоретичні відомості Індивідуальне завдання
51211. Сетевое планирование производственных процессов 156 KB
  Цель работы Изучение сетевого планирования процессов на основе построения и расчета сетевого графа. Постановка задачи Построить сетевой граф процесса, 10-15 работ. Провести расчет графа и анализ планируемого процесса. Разработать программу реализации.