Основные понятия, стандарты и организации, действующие в области ИС.
Взаимодействие открытых систем(Open Systems Interconnection (OSI ))
Взаимодействие открытых систем - правила сопряжения систем с открытой архитектурой от различных производителей.
Архитектура безопасности(Security architecture)
Архитектура безопасности - официальное дополнение ISO к модели OSI, определяющее меры безопасности в информационной сети.
Архитектура безопасности предполагает:
Предотвращение чтения сообщений любыми лицами;
Защиту трафика от его анализа посторонними;
Обнаружение изменений потоков сообщений;
Определение искажений блоков данных.
В зависимости от используемых методов различают:
Сети со слабой защитой, в которых усилия нарушителя пропорциональны затратам отправителя;
Сети с сильной защитой, требующие резкого увеличения затрат нарушителя.
Базовая эталонная модель взаимодействия открытых систем (Модель OSI)
(Стандарт ISO 7498 (Open systems interconnection basic reference model))
Базовая эталонная модель взаимодействия открытых систем - стандарт ISO, определяющий процесс информационного взаимодействия двух или более систем, в виде совокупность информационных взаимодействий уровневых подсистем.
Система обработки сообщений (Message Handling System (MHS ))
Система обработки сообщений - в модели OSI - система агентов сообщений пользователя, агентов передачи сообщений, хранения сообщений и устройств доступа, обеспечивающая работу электронной почты.
Уровень (Layer)
Уровень - в модели OSI - набор структур и программ, обеспечивающих обработку определенного класса событий.
Уровень выступает единицей декомпозиции совокупности функций, обеспечивающих информационное взаимодействие прикладных процессов.
В модели OSI выделяют семь уровней информационного взаимодействия:
7- прикладной уровень: передача информации между программами;
6- уровень представления: шифрование, кодирование и сжатие данных;
5- сеансовый уровень: установка, поддержка и разрыв соединения;
4- транспортный уровень: точность доставки, уровень качества услуг;
3- сетевой уровень: маршруты передачи, обработка и передача сообщений;
2- канальный уровень: управление каналом связи, доступ к среде передачи и адресация;
1- физический уровень: cвязь на уровне аппаратуры.
Уровни не зависят друг от друга и состоят из активных объектов, которые:
Взаимодействуют с другими объектами того же уровня;
Предоставляют сервис смежному с ним верхнему уровню;
Получают сервис от смежного с ним нижнего уровня;
Обмениваются блоками данных с целью выполнения возложенных на них задач.
Семиуровневая модель ВОС.
Модель Взаимодействия Открытых Систем (OSI).
Эталонная модель OSI, иногда называемая стеком OSI представляет собой 7-уровневую сетевую иерархию, разработанную Международной организацией по стандартам (International Standardization Organization - ISO). Эта модель содержит в себе по сути 2 различных модели:
Горизонтальную модель на базе протоколов, обеспечивающую механизм взаимодействия программ и процессов на различных машинах
Вертикальную модель на основе услуг, обеспечиваемых соседними уровнями друг другу на одной машине
В горизонтальной модели двум программам требуется общий протокол для обмена данными. В вертикальной - соседние уровни обмениваются данными с использованием интерфейсов API.
Уровень 7, прикладной
Прикладной уровень отвечает за доступ приложений в сеть. Задачами этого уровня является перенос файлов, обмен почтовыми сообщениями и управление сетью. (FTP, Telnet,…)
Уровень 6, представления
Этот уровень обеспечивает преобразование данных (кодирование, компрессия и т.п.). Обеспечивает независимость прикладных процессов от различных форм представления данных.
Уровень 5, сеансовый
Обеспечивает механизм организации и формирования структуры взаимодействия между прикладными процессами.
Уровень 4, транспортный
Транспортный уровень делит потоки информации на достаточно малые фрагменты (пакеты) для передачи их на сетевой уровень. В стеке TCP/IP происзодит контроль целостности передачи данных. (TCP).
Уровень 3, сетевой
На этом уровне происходит маршрутизация пакетов на основе преобразования MAC-адресов в сетевые адреса. Сетевой уровень обеспечивает также прозрачную передачу пакетов на транспортный уровень. (IP).
Уровень 2, канальный
Канальный уровень обеспечивает создание, передачу и прием кадров данных. Этот уровень обслуживает запросы сетевого уровня и использует сервис физического уровня для приема и передачи пакетов. Спецификации IEEE 802.x делят канальный уровень на два подуровня: управление логическим каналом (LLC) и управление доступом к среде (MAC). LLC обеспечивает обслуживание сетевого уровня, а подуровень MAC регулирует доступ к разделяемой физической среде. (Ethernet).
Уровень 1, физический
Физический уровень получает пакеты данных от вышележащего канального уровня и преобразует их в оптические или электрические сигналы, соответствующие 0 и 1 бинарного потока. Эти сигналы посылаются через среду передачи на приемный узел. Механические и электрические/оптические свойства среды передачи определяются на физическом уровне и включают:
· Тип кабелей и разъемов
· Разводку контактов в разъемах
· Схему кодирования сигналов для значений 0 и 1
На сетевом уровне формируется IP-пакет: DATA|IP-заголовок
На канальном уровне формируется кадр: DATA|IP-заголовок|Ethernet-заголовок:
· 1 IP-паке в один кадр
· 1 IP-пакет разбивается на несколько кадров
· Несколько IP-пакетов помещаются в 1 кадр
3. TCP/IP, распределение протоколов по уровням ВОС.
Transmission Control Protocol/Internet Protocol (TCP/IP) - это промышленный стандарт стека протоколов, разработанный для глобальных сетей.
Стандарты TCP/IP опубликованы в серии документов, названных Request for Comment (RFC). Документы RFC описывают внутреннюю работу сети Internet. Некоторые RFC описывают сетевые сервисы или протоколы и их реализацию, в то время как другие обобщают условия применения.
Так как стек TCP/IP был разработан до появления модели взаимодействия открытых систем ISO/OSI, то, хотя он также имеет многоуровневую структуру, соответствие уровней стека TCP/IP уровням модели OSI достаточно условно.
Структура протоколов TCP/IP приведена на рисунке 2.1. Протоколы TCP/IP делятся на 4 уровня.
Рис. 2.1. Стек TCP/IP
(уровень IV ) соответствует физическому и канальному уровням модели OSI. Этот уровень в протоколах TCP/IP не регламентируется, но поддерживает все популярные стандарты физического и канального уровня: Ethernet, Token Ring, FDDI, Fast Ethernet, PPP и т.д..
(уровень III ) - уровень межсетевого взаимодействия, который занимается передачей пакетов с использованием различных транспортных технологий локальных сетей, территориальных сетей, линий специальной связи и т. п. В качестве основного протокола сетевого уровня (в терминах модели OSI) в стеке используется протокол IP . Протокол IP является дейтаграммным протоколом, то есть он не гарантирует доставку пакетов до узла назначения. Также протоколы RIP, OSPF, ICMP и др.
(уровень II ) называется основным. На этом уровне функционируют протокол управления передачейTCP (Transmission Control Protocol) и протокол дейтаграмм пользователя UDP (User Datagram Protocol). Протокол TCP обеспечивает надежную передачу сообщений между удаленными прикладными процессами за счет образования виртуальных соединений. Протокол UDP обеспечивает передачу прикладных пакетов дейтаграммным способом, как и IP, и выполняет только функции связующего звена между сетевым протоколом и многочисленными прикладными процессами.
(уровень I ) называется прикладным. WWW, Telnet, SMTP и т.д..
Протоколы IP, ARP, RARP.
Основу транспортных средств стека протоколов TCP/IP составляет протокол межсетевого взаимодействия - Internet Protocol (IP). Документ – RFC 791. К основным функциям протокола IP относятся:
· перенос между сетями различных типов адресной информации в унифицированной форме,
· сборка и разборка пакетов при передаче их между сетями с различным максимальным значением длины пакета.
Состав IP-кадра:
· Заголовок 20байт
· внутри заголовка 2 блока по 32бита для IP-адресов источника и назначения
· Поле данных
В большинстве типов локальных и глобальных сетей определяется такое понятие как максимальный размер поля данных кадра или пакета, в которые должен инкапсулировать свой пакет протокол IP. Эту величину обычно называют максимальной единицей транспортировки - Maximum Transfer Unit, MTU. Сети Ethernet имеют значение MTU, равное 1500 байт
ARP (Address Resolution Protocol) протокол служит для установления соответствия между IP и MAC адресом (ARP – когда изв. IP, RARP – когда изв. MAC). MAC-адрес – 48бит, прошит в каждой железке (байта – производитель, ещё 3 байта – уникальный номер железки).
В сетях используется IP-адресация, как более гибкая. IP-адрес не привязан к железу.
С помощью ARP заполняется специальная таблица – ARP-кэш, с динамическими записями.
2 узла – А и Б, А знает IP Б и хочет отправить ему данные:
1) А посылает широковещательный ARP запрос с IP адресом Б
2) Б видит свой IP и посылает широковещательный ответ со своим MACом
3) A получает MAC Б, помещает его в ARP-кэш и формиреут Ethernet-кадр (данные|IP-заголовок(IP-адреса)|Ethernet-заголовок(MAC адреса))
Для дальнейшей передачи ARP-запросы не нужны.
RARP – Reverse ARP. Одно из применений – старт бездисковых станций, не знающих в начальный момент своего IP-адреса.
Протоколы TCP , ICMP , UDP.
Transmission Control Protocol (TCP) (протокол управления передачей) - один из основных сетевых протоколов Интернета, предназначенный для управления передачей данных в сетях и подсетях TCP/IP.
Выполняет функции протокола транспортного уровня модели OSI.
TCP - это транспортный механизм, предоставляющий поток данных, с предварительной установкой соединения, за счёт этого дающий уверенность в достоверности получаемых данных, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета.
Единицей данных протокола TCP является сегмент. Информация, поступающая к протоколу TCP в рамках логического соединения от протоколов более высокого уровня, рассматривается протоколом TCP как неструктурированный поток байт. Поступающие данные буферизуются средствами TCP. Для передачи на сетевой уровень из буфера "вырезается" некоторая непрерывная часть данных, называемая сегментом.
Соединение в протоколе TCP идентифицируется парой полных адресов обоих взаимодействующих процессов (оконечных точек). Адрес каждой из оконечных точек включает IP-адрес (номер сети и номер компьютера) и номер порта (FTP – 21, HTTP – 80 и т.д.). Одна оконечная точка может участвовать в нескольких соединениях.
Установление соединения выполняется в следующей последовательности:
· При установлении соединения одна из сторон является инициатором. Она посылает запрос к протоколу TCP на открытие порта для передачи (active open).
· После открытия порта протокол TCP на стороне процесса-инициатора посылает запрос процессу, с которым требуется установить соединение.
· Протокол TCP на приемной стороне открывает порт для приема данных (passive open) и возвращает квитанцию, подтверждающую прием запроса.
· Для того чтобы передача могла вестись в обе стороны, протокол на приемной стороне также открывает порт для передачи (active port) и также передает запрос к противоположной стороне.
· Сторона-инициатор открывает порт для приема и возвращает квитанцию. Соединение считается установленным. Далее происходит обмен данными в рамках данного соединения.
Используется квитирование (подтверждение передачи данных)
ICMP (Internet Control Message Protocol - межсетевой протокол управляющих сообщений) - сетевой протокол, входящий в стек протоколов TCP/IP. В основном ICMP используется для передачи сообщений об ошибках и других исключительных ситуациях, возникших при передаче данных, например, запрашиваемая услуга недоступна, или хост, или маршрутизатор не отвечают. Также на ICMP возлагаются некоторые сервисные функции.
Каждое сообщение протокола ICMP передается по сети внутри пакета IP. Пакеты IP с сообщениями ICMP маршрутизируются точно так же, как и любые другие пакеты, без приоритетов, поэтому они также могут теряться. Кроме того, в загруженной сети они могут вызывать дополнительную загрузку маршрутизаторов. Для того, чтобы не вызывать лавины сообщения об ошибках, потери пакетов IP, переносящие сообщения ICMP об ошибках, не могут порождать новые сообщения ICMP.
Существует несколько типов сообщений ICMP. Каждый тип сообщения имеет свой формат, при этом все они начинаются с общих трех полей: 8-битного целого числа, обозначающего тип сообщения (TYPE), 8-битного поля кода (CODE), который конкретизирует назначение сообщения, и 16-битного поля контрольной суммы (CHECKSUM). Кроме того, сообщение ICMP всегда содержит заголовок и первые 64 бита данных пакета IP, который вызвал ошибку.
UDP (User Datagram Protocol - протокол пользовательских датаграмм) - это транспортный протокол для передачи данных в сетях IP без установления соединения. Он является одним из самых простых протоколов транспортного уровня модели OSI. В отличие от TCP, UDP не гарантирует доставку пакета. Это позволяет ему гораздо быстрее и эффективнее доставлять данные для приложений, которым требуется большая пропускная способность линий связи, либо требуется малое время доставки данных.
ICMP (ang. Internet Control Message Protocol) - это один из протоколов сетевого уровня в модели ISO/OSI. Его задачей является обслуживание функции контроля правильности работы сети. С его помощью передаются всякого рода, низкоуровневые сводки, с раскроенными неправильностями во время сетевых связей. Практически целая коммуникация между данными компьютерами или другими устройствами при употреблении протокола ICMP происходит незаметным для конечнего пользователя образом. Единичными исключениями являются здесь инструменты ping и traceroute.
Коммуникация, ицпользующая протокол ICMP, состоит в пересылке подходящих информаций об ошибках, раскроенных во время связи между двумя устройствами. Одиночная информация существует в виде пакета, сформированного надлежащим образом (ang. Datagram), который следовательно будет подвергнутый инкапсуляции в рамке протокола IP. Протокол ICMP, вопреки всеобщему мнению, не использует в своей работе протоколы TCP, ни UDP. Итак, не пользуется никакими сетевыми портами.
Устройство пакета ICMP следующее:
Заголовок в 4 байтов - первый байт определяет тип пакета, второй - код операции, третий и четвёртый представляют собой контрольную сумму.
. Поле данных с долготой зависимой от типа пакета и его функции. В некоторых случаях может быть установленным с уровня инструмента, напр. догадливая команда ping в Виндоуз устанавливает размер данных пакета ECHO_REQUEST на 32 байта, а версия, встречающаяся в системах Юникс на 56 байтов.
Список некоторых типов сводок протокола ICMP:
Тип Значение
0 Echo Reply (поворот эха - "ответ на ping")
1 - 2 Забронированные
3 Destination Unreachable (недостожимость места предназначения)
4 Source Quench (сдержание отправителя)
5 Redirect Message (измени трассирование)
6 Alternate Host Address (альтернативный адрес хоста)
7 Забронированные
8 Echo Request (требование эха)
9 Router Advertisement (объявление маршрутизатора (рутера))
10 Router Solicitation (выбор рутера)
11 Time Exceeded (превышение лимита времени)
12 Parameter Problem (проблема с параметром)
13 Timestamp (требование временного шифра)
14 Timestamp Reply (поворот временного шифра)
15 Information Request (требование информации)
16 Information Reply (поворот информации)
17 Address Mask Request (требование адресной маски)
18 Address Mask Reply (поворот адресной маски)
19 Забронированные для безопасности
20 - 29 Забронированные
30 Traceroute (слежка трассы)
31 Datagram Conversion Error (ошибка конверсии дейтаграммы)
32 Mobile Host Redirect (изменение адреса мобильного узла)
33 IPv6 Where-Are-You (вопрос IPv6 "где ты")
34 IPv6 Here-I-Am (ответ IPv6 "я здесь")
35 Mobile Registration Request (просьба регистрировать мобильный узел)
36 Mobile Registration Reply (ответ на проьбу регистрировать мобильный узел)
37 Domain Name Request (требование названия домена)
38 Domain Name Reply (поворот названия домена)
39 SKIP Algorithm Discovery Protocol
40 Photuris, Security failures
41-255 Забронированные
Поле кода операции в заголовке пакета ICMP определяет вид содержания в сообщении, зависимого от его типа. Например, пакет типа 3, то есть Destination Unreachable может заключать следующие коды операции во втором байте заголовка:
0 Целевая сеть недостижимая
1 Целевое устройство (хост) недостижимое
2 Целевой протокол недостижимый (или необслуживаемый)
3 Целевой порт недостижимый
4 Пакет должен быть подвергнутый фрагментации, а установили флаг DF (не фрагментируй)
5 Traceroute неправильная
6 Неизвестная целевая сеть
7 Целевое устройство (хост) неизвестное
8 Хост отправителя недоступный
9 Доступ в сеть воспрещённый
10 Доступ в устройство воспрещённый
11 Установка поля Type of Service (в заголовке IP) делает невозможным доступ в целевую сеть
12 Установка поля Type of Service (в заголовке IP) делает невозможным доступ в целевую сеть
13 Коммуникация воспрещённая
Примеры работы протокола ICMP:
Ping - один из инструментов, выступающих практически в каждой операционной системе, обслуживающей протокол TCP/IP. С его помощью пакеты ICMP ECHO_REQUEST отправляются в целевой компьютер. Дистанционная машина, после получения такого сообщения должна ответить при помощи ECHO_REPLY. Поэтому можно определить следующее: Конфигурация сети делает возможной связь с дистанционной машиной, и оценку её нагрузки на основании информаций, касающихся количества потерянных пакетов и времени ответа.
. Traceroute - инструмент, делающий возможным определение, через какие маршрутизаторы проходит пакет по дороге к дистанционному компьютеру. Сначала, локальный компьютер посылает пакет ECHO_REQUEST в дистанционное устройство, с параметром ТТЛ (TTL -Time to Live), установленным на 1. Первый рутер уменьшает ТТЛ на один, значит до нуля, удаляет пакет и отсылает адресату сообщение ICMP TIME_EXCEEDED. Целевой компьютер, после получения такой информации, возобновляет высылку ECHO_REQUEST, но ц ТТЛ установленным на стоимость 2. Первый рутер уменьшает ТТЛ на 1, второй сделает то же самое, устанавливая 0, и вновь удалит пакет, и отошлёт сообщение TIME_EXCEEDED. Такая ситуация повтаряется так долго, что даже пакет доберётся до дистанционного комньютера, который тогда отошлёт отправителю сообщение ECHO_REPLY.
Протокол обмена управляющими сообщениями ICMP (Internet Control Message Protocol) играет в сети вспомогательную роль, а именно позволяет маршрутизатору сообщить конечному узлу об ошибках, с которыми он столкнулся при передаче какого-либо IP-пакета от данного конечного узла.
Управляющие сообщения ICMP не могут направляться промежуточному маршрутизатору, который участвовал в передаче пакета, с которым возникли проблемы, так как для такой посылки нет адресной информации – пакет несет в себе только адрес источника и адрес назначения, не фиксируя адреса промежуточных маршрутизаторов.
Протокол ICMP – это протокол сообщения об ошибках , а не протокол коррекции ошибок . Конечный узел может предпринять некоторые действия для того, чтобы ошибка больше не возникала, но эти действия протоколом ICMP не регламентируются.
Каждое сообщение протокола ICMP передается по сети внутри пакета IP. Пакеты IP с сообщениями ICMP маршрутизируются точно так же, как и любые другие пакеты, без приоритетов, поэтому они тоже могут теряться. Кроме того, в загруженной сети они могут вызывать дополнительную загрузку маршрутизаторов. При потере IP-пакетов, переносящих сообщения ICMP, маршрутизаторы не должны порождать новые пакеты, чтобы не вызвать массу сообщений об ошибках.
Существует несколько типов сообщений ICMP, каждый из которых имеет свой формат, хотя при этом все они начинаются с общих трех полей: 8-битного целого числа, обозначающего тип сообщения (Type), 8-битного поля кода (Code), который конкретизирует назначение сообщения, и 16-битного поля контрольной суммы (Checksum). Кроме того, сообщение ICMP всегда содержит заголовок и первые 64 бита данных пакета IP, который вызвал ошибку. Это делается для того, чтобы узел-отправитель смог более точно проанализировать причину ошибки, так как все протоколы прикладного уровня стека TCP/IP содержат наиболее важную информацию для анализа в первых 64 битах своих сообщений. Поле Тип сообщения может иметь значения, представленные в табл. 2.14 .
Протокол ICMP предоставляет сетевым администраторам средства для тестирования достижимости узлов сети. Эти средства представляют собой очень простой эхо-протокол, включающий обмен двумя типами сообщений: эхо-запросом и эхо-ответом .
Компьютер или маршрутизатор посылают по интерсети эхо-запрос, в котором указывают IP-адрес узла, достижимость которого нужно проверить. Узел, который получает эхо-запрос, формирует и отправляет эхо-ответ и возвращает сообщение узлу-отправителю запроса. В запросе могут содержаться некоторые данные, которые должны быть возвращены в ответе.
Так как эхо-запрос и эхо-ответ передаются по сети внутри IP-пакетов, то их успешная доставка означает нормальное функционирование всей транспортной системы сети.
Таблица 2.14 – Значения поля Тип сообщения
Протокол IP имеет ясную и элегантную структуру. В нормальных ситуациях IP очень эффективно использует для пересылки память и ресурсы. Однако что произойдет в нестандартной ситуации? Что может прервать бесцельное блуждание датаграммы до завершения ее времени жизни после краха маршрутизатора и неисправности в сети? Кто предупредит приложение о прекращении отправки датаграмм в недостижимую точку назначения?
Средства для лечения таких неисправностей предоставляет протокол управляющих сообщений Интернета (Internet Control Message Protocol - ICMP). Он выполняет роль сетевого помощника, способствуя маршрутизации в хостах и обеспечивая сетевого администратора средствами определения состояния сетевых узлов. Функции ICMP являются важной частью IP. Все хосты и маршрутизаторы должны быть способны генерировать и обрабатывать сообщения ICMP. При правильном использовании эти сообщения могут улучшить выполнение сетевых операций.
Сообщения ICMP пересылаются в датаграммах IP с обычным заголовком IP (см. рис. 7.1), имея в поле протокола значение 1.
Рис. 7.1. Пакетирование сообщения ICMP
Бывают ситуации, приводящие к отбрасыванию (удалению из сети) датаграммы IP. Например, точка назначения может стать недоступной из-за обрыва связи. Или может завершиться время жизни датаграммы. Маршрутизатор не сможет переслать длинную датаграмму при запрещении фрагментации.
При отбрасывании датаграммы по адресу ее источника направляется сообщение ICMP, указывающее на возникшую проблему. На рис. 7.2 показано сообщение ICMP, направленное к источнику датаграммы.
Рис. 7.2. Сообщение ICMP направляется по пути трафика.
ICMP быстро сообщит системе о выявленной проблеме. Это очень надежный протокол, поскольку указание на ошибки не зависит от наличия сетевого центра управления.
Однако в использовании сообщений ICMP имеются некоторые недостатки. Например, если недостижима точка назначения, то сообщение будет распространяться до источника по всей сети, а не на станцию сетевого управления.
Реально ICMP не имеет средств предоставить отчет об ошибках выделенному операционному центру. Для этого служит протокол SNMP (см. главу 20).
На рис. 7.3 показаны обобщенные сообщения, формируемые маршрутизатором и хостом назначения для отчета о возникшей проблеме. В таблице 7.1 перечислены формальные имена сообщений об ошибках ICMP.
Рис. 7.3. Типы сообщений об ошибках ICMP
Таблица 7.1 Сообщения об ошибках ICMP
| Сообщение | Описание |
|---|---|
| Destination Unreachable (недостижимая точка назначения) | Датаграмма не может достичь хоста назначения, утилиты или приложения. |
| Time Exceeded (время закончилось) | Маршрутизатор определил завершение времени жизни, или закончилось время на сборку фрагментов в хосте назначения. |
| Parameter Problem (проблема с параметром) | В заголовке IP неверный параметр. |
| Source Quench (подавление источника) | Перегружен маршрутизатор или система назначения (системам рекомендуется не отправлять это сообщение). |
| Redirect (перенаправление) | Хост направил датаграмму на неверный локальный маршрутизатор. |
Протокол ICMP определяет, что сообщения могут или должны быть посланы в каждом случае, но он не требует выдавать сообщения ICMP о каждой ошибке.
В этом есть здравый смысл. Основным назначением маршрутизатора в сети является пересылка датаграмм. Перегруженный хост назначения должен уделять больше времени доставке датаграмм в приложения, а не указанию на ошибки удаленному хосту. Именно поэтому не формируются сообщения о случайном отбрасывании датаграммы.
Что происходит при получении хостом сообщения ICMP? Рассмотрим пример, когда производится попытка обращения по зарезервированному (и, следовательно, недостижимому) адресу сети:
telnet: connect: Host is unreachable
Произошло то, что и должно было произойти,- в сообщении указано на недостижимость хоста (Host is unreachable).
Чтобы определить, какой из маршрутизаторов послал сообщение ICMP, можно использовать команду traceroute :
traceroute to 10.1.1.1 (10.1.1.1), 30 hops max, 40 byte packets
> nomad-gateway (128.121.50.50) 2 ms 2 ms 2 ms
> liberty-gateway (130.94.40.250) 91 ms 11 ms 78 ms
border2-hssi2-0.NewYork.mci.net (204.70.45.9) !H !H !H
Маршрутизатор New York послал сообщение Destination Unreachable , которое отображается на экране как!Н.
Функции traceroute основаны на ICMP-сообщении Time Expired и формируются следующим образом:
■ Создается короткое сообщение UDP, которое имеет заголовок IP с установленным в 1 полем TTL.
■ Трижды отправляется датаграмма.
■ Первый маршрутизатор (в примере - nomad-gateway ) устанавливает значение Time-to-Live (время жизни) в 0, отбрасывает датаграмму и отправляет источнику ICMP-сообщение Time Expired .
■ Функция traceroute идентифицирует пославший сообщение маршрутизатор и трижды выводит само сообщение.
■ Значение Time-to-Live устанавливается в 2, и сообщение посылается дальше.
■ Процесс повторяется с увеличением Time-to-Live на каждом шаге.
Если можно достичь точки назначения, то в итоге можно получить полный путь до него.
Напомним, что ICMP-сообщение об ошибке посылается, когда в сети не все благополучно. Важно обеспечить, чтобы трафик ICMP не перегружал сети, делая ситуацию еще хуже. Для этого протокола, требуется ввести несколько очевидных ограничений. ICMP не должен формировать сообщения о:
■ Маршрутизации и доставке ICMP-сообщений messages
■ Широковещательных и многоадресных датаграммах
■ Фрагментах датаграмм, кроме первых
■ Сообщениях, чей адрес источника не идентифицирует уникальный хост (например, IP-адреса источников 127.0.0.1 или 0.0.0.0)
Сообщение ICMP переносится в части данных датаграммы IP. Каждое сообщение ICMP начинается тремя одинаковыми полями: полем типа (Type), полем кода (Code), обеспечивающим более подробное описание ошибки, и полем контрольной суммы (Checksum). Формат оставшейся части сообщения определяется типом сообщения.
Сообщение об ошибке ICMP обрамляется заголовком IP. Добавляются первые 8 октетов датаграммы, которая привела к ошибке. Эти сведения позволяют проанализировать причину ошибки, поскольку содержат информацию о предполагаемом назначении датаграммы и целевом протоколе четвертого уровня. Дополнительные 8 байт позволяют определить коммуникационный элемент приложения (более подробно об этом см. в разделе о протоколах TCP и UDP).
В сообщение включается и контрольная сумма ICMP, начиная от поля Type .
Существует много причин прекращения доставки датаграммы. Разорванная связь физически не позволит маршрутизатору достичь подсети назначения или выполнить пересылку в точку следующего попадания. Хост назначения может стать недоступным при отключении его для проведения профилактики.
Как уже отмечалось в главе 6, современные маршрутизаторы имеют хорошие средства обеспечения безопасности. Они могут быть сконфигурированы для просмотра входящего в сеть трафика. При запрещении сетевым администратором доступа к точке назначения датаграмма также не может быть доставлена.
Рис. 7.4. Формат ICMP-сообщения Destination Unreachable
Формат сообщения Destination Unreachable показан на рис. 7.4. Поле Type (в нашем случае 3) идентифицирует именно этот тип сообщения. Поле Code отражает причину отправки сообщения. Полный список кодов этого поля представлен в таблице 7.2.
Таблица 7.2 Коды ошибок сообщения Destination Unreachable
| Код | Смысл |
|---|---|
| 0 | Сеть недостижима. |
| 1 | Хост недостижим. |
| 2 | Запрашиваемый протокол не поддерживается в точке назначения. |
| 3 | Порт недостижим (недоступно удалённое приложение). |
| 4 | Необходима фрагментация, но установлен флаг "Не фрагментировать". |
| 5 | Неверен маршрут от источника. |
| 6 | Неизвестна сеть назначения. |
| 7 | Неизвестен хост назначения. |
| 8 | Хост источника изолирован. |
| 9 | Административно запрещены коммуникации с сетью назначения. |
| 10 | Административно запрещены коммуникации с хостом назначения. |
| 11 | Сеть недостижима для заданного типа обслуживания. |
| 12 | Хост недостижим для заданного типа обслуживания. |
Пересылаемая датаграмма может быть отброшена по тайм-ауту при уменьшении до нуля ее времени жизни (TTL). Еще один тайм-аут может возникнуть в хосте назначения, когда завершится время, выделенное на сборку, а прибыли еще не все фрагменты датаграммы. В обоих случаях формируется сообщение Time Exceeded для источника датаграммы. Формат этого сообщения показан на рис. 7.5.
Рис. 7.5. Формат ICMP-сообщения Time Exceeded
Значения кодов (см. таблицу 7.3) отражают причину тайм-аута.
Таблица 7.3 Коды сообщения Time Exceeded
ICMP-сообщение Parameter Problem используется для отчета об ошибках, не специфицированных в кодах других сообщений. Например, в полях вариантов может появиться неверная информация, не позволяющая правильно обработать датаграмму, в результате чего датаграмма будет отброшена. Более часто проблемы с параметрами возникают из-за ошибок в реализации, когда система пытается записать параметры в заголовок IP.
Рис. 7.6. Формат ICMP-сообщения Parameter Problem
Поле Pointer (указатель) сообщения Parameter Problem идентифицирует октет, в котором выявлена ошибка. На рис. 7.6 показан формат сообщения Parameter Problem , а в таблице 7.4 - значения кодов ошибок.
Таблица 7.4 Коды сообщения Parameter Problem
Протокол IP очень прост: хост или маршрутизатор обрабатывают датаграмму и посылают ее как можно быстрее. Однако доставка не всегда проходит гладко. Могут возникнуть различные проблемы.
Когда один или несколько хостов отправляют трафик UDP на медленный сервер, то на последнем может возникнуть перегрузка, что приведет к отбрасыванию сервером некоторой части этого трафика.
Маршрутизатор может переполнить свои буферы и далее будет вынужден отбрасывать некоторые поступающие датаграммы. Медленное соединение через региональную сеть (например, на скорости 56 Кбит/с) между двумя скоростными локальными сетями (например, в 10 Мбит/с) может создать затор на пути следования датаграмм. Из-за этого в сети возникнут перегрузки, которые также приведут к отбрасыванию датаграммы и, следовательно, к созданию еще большего трафика.
Сообщение Source Quench (подавление источника) показано на рис. 7.7. Оно позволяет попытаться решить проблему перегрузок, хотя и не всегда успешно. Механизмы для подавления источника перегрузки сети должны создавать разработчики конкретных продуктов, но остается открытым конкретный вопрос:
Когда и кому маршрутизатор или хост должен отправлять сообщение Source Quench? Рис. 7.7. Формат ICMP-сообщения Source Quench
Обычно ICMP-сообщение указывает хосту источника на причину отбрасывания посланной им датаграммы. Однако при перегрузке такое сообщение может не дойти до этого хоста, генерирующего очень напряженный сетевой трафик. Кроме того, очень расплывчаты требования к обработке поступающих сообщений Source Quench .
Текущий документ по требованиям к хостам (RFC 1812) оговаривает в качестве особого пункта, что сообщения Source Quench вовсе не нужно посылать. Работа должна выполняться более совершенным механизмом управления нагрузкой в сети.
К локальной сети может быть подключено более одного маршрутизатора. Когда локальный хост посылает датаграмму не на тот маршрутизатор, последний пересылает ее и отправляет хосту источника ICMP-сообщение Redirect (перенаправление), как показано на рис. 7.8. Хост должен переключить последующий трафик на более короткий путь.
Рис. 7.8 . Коррекция маршрутизации на хосте посредством сообщения Redirect
Сообщение Redirect используется и для выключения маршрутизатора системным администратором. Хост может быть сконфигурирован с единственным маршрутизатором по умолчанию; при этом он будет динамически определять возможности пересылки через другие маршрутизаторы.
Рис. 7.9. Формат ICMP-сообщения Redirect
Формат сообщения о перенаправлении показан на рис. 7.9. Коды этого сообщения перечислены в таблице 7.5. Некоторые протоколы маршрутизации способны выбирать путь доставки на основе содержимого поля типа обслуживания (TOS) датаграммы. Коды 2 и 3 предоставляют некоторые сведения да такого выбора.
Таблица 7.5 Коды перенаправления
Что должен делать хост, получивший сообщение ICMP? Реализации различных разработчиков по-разному отвечают на этот вопрос. В некоторых из них хосты игнорируют все или многие такие сообщения. Стандарты TCP/IP оставляют большую свободу выбора в решении этого вопроса. Для различных типов сообщений ICMP предлагаются следующие рекомендации:
| Destination Unreachable | Доставить ICMP-сообщение на транспортный уровень. Выполняемые действия должны зависеть от того, является ли причина вывода сообщения временной или постоянной (например, административный запрет на пересылку). |
| Redirect | Хост обязан обновить таблицу маршрутизации. |
| Source Quench | Доставить ICMP-сообщение на транспортный уровень или в модуль обработки ICMP. |
| Time Exceeded | Доставить на транспортный уровень. |
| Parameter Problem | Доставить ICMP-сообщение на транспортный уровень с необязательным уведомлением пользователя. |
Иногда ошибки должны обрабатываться совместно операционной системой, коммуникационным программным обеспечением и сетевым приложением.
При пересылке большого объема данных (например, при копировании файлов по сети) с одного хоста на другой размер датаграмм существенно влияет на производительность. Заголовки IP и TCP требуют не менее 40 дополнительных байт.
■ Если данные пересылаются в 80-байтовых датаграммах, дополнительная нагрузка составит 50%.
■ Если данные пересылаются в 400-байтовых датаграммах, дополнительная нагрузка составит 10%.
■ Если данные пересылаются в 4000-байтовых датаграммах, дополнительная нагрузка составит 1%.
Для минимизации дополнительной нагрузки лучше отсылать датаграммы наибольшего размера. Однако этот размер ограничивается значением максимального элемента пересылки (Maximum Transmission Unit - MTU) для каждого из носителей. Если датаграмма будет слишком большой, то она будет фрагментирована, а этот процесс снижает производительность. (С точки зрения пользователя, качество сети определяется двумя параметрами: интервалом пересылки (от начала пересылки до ее завершения) и временем ожидания (задержкой доступа к сети, занятой другими пользователями). Увеличение размера датаграммы приводит к снижению интервала пересылки, но увеличению ожидания для других пользователей. Грубо говоря, нагрузка на сеть будет выглядеть как пиковые импульсы с очень небольшой нагрузкой между ними, что считается самым неудачным вариантом загрузки сети. Гораздо лучше, когда сеть нагружается равномерно. - Прим. пер .)
Многие годы хосты избегали фрагментации, устанавливая эффективное значение MTU для пересылки в 576 октетов для всех нелокальных хостов. Это часто приводило к ненужному снижению производительности.
Гораздо полезнее заранее знать наибольший допустимый размер датаграммы, которую можно переслать по заданному пути. Существует очень простой механизм исследования MTU по пути (Path MTU discovery), позволяющий узнать это значение. Для такого исследования:
■ Флаг "Не фрагментировать" заголовка IP устанавливают в 1.
■ Размер MTU по пути первоначально устанавливают в значение MTU для локального интерфейса.
■ Если датаграмма будет слишком велика для одного из маршрутизаторов, то он пошлет обратно ICMP-сообщение Destination Unreachable с кодом 4.
■ Хост источника уменьшит размер датаграммы и повторит попытку.
Какое же значение нужно выбрать для следующей попытки? Спецификация IP предполагает сохранение значения MTU и его доступность для протоколов транспортного уровня. Если маршрутизатор имеет современное программное обеспечение, то он будет включать в пересылаемое дальше по сети сообщение Destination Unreachable размер MTU (см. рис. 7.10). Иногда средства защиты конфигурируются на полное исключение всех входящих сообщений ICMP, что не позволяет использовать механизм определения MTU по пути следования датаграммы.
Рис. 7.10. Сообщение Destination Unreachable приносит результат исследования размера
Поскольку пути пересылки могут меняться динамически, флажок "Не фрагментировать" нужно устанавливать во всех коммуникационных датаграммах. При необходимости маршрутизатор будут посылать сведения об обновлениях.
Если маршрутизатор использует устаревшее программное обеспечение, он не сможет предоставить значение MTU для следующего попадания. В этом случае значение для следующей попытки будет выбираться из списка стандартных размеров MTU (см. главу 4) с постепенным уменьшением для каждой новой попытки до достижения значения, нужного для коммуникации с удаленным хостом.
Разумеется, изменение пути следования может создать предпосылки для использования большего размера MTU. В этом случае система, согласовавшая небольшой размер MTU, будет пытаться его увеличить, если такое улучшение будет возможно.
Не все сообщения ICMP сигнализируют об ошибках. Некоторые из них извлекают из сети полезные сведения. Работает ли хост X? Не выключен ли хост Y? Как долго движется датаграмма до хоста Z и обратно? Какова маска подсети хоста источника?
Ответы на эти вопросы дают следующие сообщения ICMP:
■ Эхо-запросы и эхо-ответы обеспечивают обмен информацией между хостами и маршрутизаторами.
■ Запросы и ответы о маске адреса позволяют системе исследовать присвоенную интерфейсу маску адреса.
■ Запросы и ответы временной метки служат для извлечения сведений об установке времени на целевой системе. Ответы на такие запросы дают информацию, необходимую для оценки времени обработки датаграмм на хосте.
На рис. 7.11 представлено обслуживание запросов ICMP. Программа Ping посылает эхо-сообщение "Вы в рабочем состоянии?", которое используется в ежедневной работе сетевого администратора. Запросы о маске адреса применяются от случая к случаю, а запросы о временной метке вообще редко.
Рис. 7.11. Сообщение запроса ICMP
Эхо-запросы (Echo Request) и эхо-ответы (Echo Reply) применяются для проверки активности системы. Код типа 8 применяется в запросах, а код 0 - в ответах. Количество октетов в поле данных переменно и может выбираться отправителем.
Отвечающая сторона должна послать обратно те же самые данные, которые были получены. Поле идентификатора служит для сравнения ответа с исходным запросом. Последовательный номер эхо-сообщения может применяться для тестирования, на каком участке произошел обрыв сети, и для вычисления приблизительного времени на путь туда и обратно. При этом идентификатор не меняется, а последовательный номер (начиная от 0) увеличивается на единицу для каждого сообщения. Формат эхо-сообщения показан на рис. 7.12.
Рис. 7.12. Формат ICMP-сообщений Echo Request и Echo Reply
Широко известная команда ping доступна почти во всех системах TCP/IP, а ее работа основана на ICMP-сообщениях для эхо-запросов и эхо-ответов. В приведенном ниже диалоге сначала тестируется хост ring.bell.com . Затем отсылается последовательность из 14 сообщений, содержащих по 64 октета каждое. Отметим, что сообщения 0, 1 и 2 были потеряны. Справа приводятся сведения о пути туда и обратно.
> ping -s ring.bell.com 64 14
64 bytes from ring.bell.com: icmp_seq=3. time = 21. ms
64 bytes from ring.bell.com: icmp_seq=4. time = 18. ms
64 bytes from ring.bell.com: icmp_seq=5. time = 17. ms
64 bytes from ring.bell.com: icmp_seq=6. time = 19. ms
64 bytes from ring.bell.com: icmp_seq=7. time = 17. ms
64 bytes from ring.bell.com: icmp_seq=8. time = 17. ms
64 bytes from ring.bell.com: icmp_seq=9. time = 17. ms
64 bytes from ring.bell.com: icmp_seq=10. time = 18. ms
64 bytes from ring.bell.com: icmp_seq=11. time = 17. ms
64 bytes from ring.bell.com: icmp_seq=12. time = 17. ms
64 bytes from ring.bell.com: icmp_seq=13. time = 17. ms
-ring.bell.com PING Statistics-
14 packets transmitted, 11 packets received, 21% packet loss
round-trip (ms) min/avg/max = 17/17/21
Напомним, что организация может разделить поле своего локального адреса на часть подсети и часть хоста. Когда включается система, она может быть сконфигурирована так, что не будет заранее знать, сколько бит было присвоено полю адреса подсети. Чтобы выяснить этот вопрос, система посылает широковещательный запрос на определение маски адреса (Address Mask Request).
Ответ должен быть получен от сервера, авторизованного для управления маской адреса сервера. Обычно в качестве такого сервера применяется маршрутизатор, но может использоваться и хост. В ответе в полях сети и подсети установлены единицы, определяя 32-разрядное поле маски адреса.
Сервер маски адреса может быть сконфигурирован так, что, даже при отключении от сети на какое-то время, он будет далее передавать широковещательные сообщения Address Mask Reply, как только станет активным. Это предоставляет шанс на получение нужной информации системам, которые были запущены в то время, когда сервер был неактивен.
На рис. 7.13 показан формат запроса маски адреса и ответа на него. Тип 17 применяется для запроса, а тип 18 - для ответа. В общем случае можно игнорировать идентификатор и последовательный номер.
Рис. 7.13. Формат ICMP-сообщений Address Mask
На практике более предпочтительный метод определения маски адреса предоставляют протоколы загрузки, например Dynamic Host Configuration Protocol или BOOTP . Эти протоколы более эффективны, поскольку обеспечивают полный набор конфигурационных параметров. Кроме того, операции выполняются более точно, в том числе и некорректные.
Сообщение с ответом на Timestamp предоставляет сведения о времени в системе. Оно предназначено для оценки буферизации и обработки датаграммы на удаленной системе. Отметим следующие поля:
По возможности, возвращаемое время должно измеряться в миллисекундах относительно полуночи по универсальному времени (Universal Time), которое ранее называлось временем по Гринвичу (Greenwich Mean Time). Большинство реализаций реально возвращает одно и то же время в полях Receive timestamp и Transmit timestamp .
Протокол ICMP обеспечивает очень простой способ синхронизации систем по времени. Однако это несколько грубая синхронизация, поскольку на нее влияют задержки в сети. Существует более совершенный протокол сетевого времени (Network Time Protocol), который был разработан для синхронизации по времени в Интернете.
Тип 13 используется для запросов, а 14 - для ответов. Формат сообщения представлен на рис. 7.14.
Рис. 7.14. Формат сообщений запросов и ответов о временной метке
Ниже показана часть отчета о статистике протоколов команды netstat. Приведенный фрагмент посвящен протоколу ICMP. В отчете отражены операции ICMP, выполненные после последней инициализации.
destination unreachable: 1075
2 messages with bad code fields
destination unreachable: 1269
231 message responses generated
Система отправила 1075 сообщений Destination Unreachable . Был получен 231 запрос Echo Requests , на каждый из которых был отправлен ответ. Было получено 26 ответов Echo Replies .
Локальная система зафиксировала 21 сообщение ICMP, полученное с неверной контрольной суммой ICMP.
Системой было получено 1269 сообщений Destination Unreachable и 2 сообщения Source Quenches .
Следующий далее отчет команды netstat содержит сведения о маршрутизации. Видно, что через сообщения Redirect были динамически обнаружены новые маршрутизаторы. Было 12 отчетов о недостижимости точки назначения (Destination Unreachable). Для выбора маршрута по умолчанию было использовано около 349 подстановочных символов (wildcard).
2 new routers due to redirects
2 destinations found unreachable
Хотя многие локальные сети имеют единственный маршрутизатор по умолчанию, существует достаточное количество сетей, имеющих два или более маршрутизаторов.
Что происходит при подключении маршрутизатора к локальной сети? Сообщения о перенаправлении укажут системам на новые маршрутизаторы. Предположим, что произошел крах маршрутизатора по умолчанию.
Протокол исследования маршрутов (Router Discovery) предоставляет надежный метод, основанный на сообщениях ICMP, для отслеживания маршрутизаторов локальной сети. Основная идея состоит в периодическом объявлении маршрутизаторами о своем присутствии. Хостам нужно прослушивать такие сообщения.
Предпочтительным способом для объявления маршрутизатора о своем присутствии является отправка многоадресной рассылки по адресу для всех систем (224.0.0.1). Однако не все хосты поддерживают прием многоадресных рассылок, поэтому иногда применяется широковещательный адрес (255.255.255.255).
Подключающийся к сети хост может быть не способен к ожиданию при поиске маршрутизаторов локальной сети. Такой хост самостоятельно запрашивает маршрутизаторы об отправке их объявлений о присутствии на собственный адрес. Для этого лучше всего использовать сообщение Router Solicitation (настоятельная просьба к маршрутизаторам) в многоадресной рассылке по адресу "все маршрутизаторы" (224.0.0.2). Поскольку не все системы поддерживают многоадресные рассылки, иногда применяется широковещательная рассылка (255.255.255.255).
Типичный сценарий для маршрутизатора:
■ Каждый интерфейс маршрутизатора конфигурируется с адресом объявления (advertisement address) - 224.0.0.1 или 255.255.255.255 - для локальной сети, подключенной к данному интерфейсу.
■ При инициализации маршрутизатора и использовании многоадресной рассылки маршрутизатор начинает прослушивание адреса многоадресной рассылки для всех маршрутизаторов (224.0.0.2). Кроме того, прослушиваются и широковещательные рассылки.
■ Маршрутизатор объявляет о своем присутствии всем подключенным к локальной сети хостам посредством трансляции сообщения Router Advertisement на адрес объявления такой локальной сети. В объявлении о присутствии перечисляются все IP-адреса маршрутизатора для данного интерфейса.
■ Маршрутизатор напоминает о себе различными периодическими сообщениями Router Advertisement (рекомендуемый период 7–10 мин.).
■ Маршрутизатор посылает объявление о присутствии при запросе об этом от хоста.
Для хоста сценарий выглядит так:
■ Каждый интерфейс хоста конфигурируется с Solicitation Address - 224.0.0.2 или 255.255.255.255.
■ При инициализации хоста начинается прослушивание Router Advertisement .
■ При запуске хост может послать необязательное сообщение Router Solicitation по адресу настоятельных просьб (solicitation address). Маршрутизаторы ответят как по IP-адресу хоста, так и по адресу объявления.
■ Когда хост услышит о новом маршрутизаторе, он добавит маршрут по умолчанию в свою таблицу маршрутизации. Этому элементу таблицы присваивается значение тайм-аута на время жизни (обычно 30 мин), которое указано в Router Advertisement .
■ Тайм-аут на время жизни сбрасывается при получении нового объявления от маршрутизатора. Если время жизни завершается по тайм-ауту, элемент для маршрутизатора удаляется из таблицы маршрутизации хоста.
■ Для объявления всем о корректном отключении от сети маршрутизатор может послать объявления с нулевым значением для времени жизни.
Если имеется более одного маршрутизатора, то как хост определяет тот, которому следует направить данную датаграмму? Каждое объявление маршрутизатора содержит номер предпочтительного уровня (preference level). Если таблица маршрутизации не содержит специальных указаний, выбирается маршрутизатор с наибольшим предпочтительным уровнем. Если он не сможет обеспечить наилучший маршрут, то ответит хосту ICMP-сообщением о перенаправлении.
В ICMP-сообщении Router Advertisement имеет значение типа 9, a Router Solicitation - 10.
Исследование маршрутов (маршрутизаторов) помогает хостам определить крах локального маршрутизатора, однако после достаточно длительного периода времени - возможно, через 30 мин. Реализация TCP/IP для хостов предполагает использование встроенного алгоритма для определения неисправности маршрутизатора. Его достоинства очевидны, например:
■ Существование активного сеанса TCP/IP через маршрутизатор
■ Фиксирование получения от маршрутизатора ICMP-сообщений о перенаправлении.
К числу недостатков можно отнести:
■ Невозможность ответа на запросы ARP
■ Множество последовательных тайм-аутов при повторной пересылке в TCP
IP версии 6 обеспечивает наилучший способ исследования причин приостановки работы локальных хостов или маршрутизаторов.
ICMP определен в RFC 792. RFC 1122 (требования к хостам) и RFC 1812 (требования к маршрутизаторам) содержат несколько очень полезных разъяснений. Исследованию маршрутов посвящен RFC 1256.
Исследование MTU по пути рассмотрено в RFC 1191, а дополнительные рекомендации представлены в RFC 1435.
Протокол передачи команд и сообщений об ошибках ( ICMP - internet control message protocol, RFC-792, - 1256) выполняет различные и не только диагностические функции. При пересылке пакетов промежуточные узлы не информируются о возникших проблемах, поэтому ошибка в маршрутной таблице может восприниматься как неисправность в узле адресата и достоверно диагностироваться не будет. ICMP-протокол сообщает об ошибках в IP-дейтаграммах, но не дает информации об ошибках в самих ICMP-сообщениях. ICMP использует IP, а IP-протокол должен использовать ICMP. В случае ICMP-фрагментации сообщение об ошибке будет выдано только один раз на дейтаграмму, даже если ошибки были в нескольких фрагментах. Подводя итоги, можно сказать, что ICMP -протокол:
ICMP -сообщения об ошибках никогда не выдаются:
Эти правила призваны блокировать потоки дейтаграмм, посылаемые в отклик на мультикастинг- или широковещательные ICMP -сообщения. Особенности протокола ICMPv6 описаны в документе RFC-2463. В IPv6 на протокол ICMP возложены функции управления группами ( IGMP ).
ICMP -сообщения имеют свой формат, а схема их вложения аналогична UDP или TCP и представлена на рис. 3.1 .
Все ICMP пакеты начинаются с 8-битного поля типа ICMP и его кода (15 значений).
Рис.
3.1.
По существу, значения полей типа и кода выполняют почти ту же функцию, что и порт в ТСР и UDP -протоколах.
Код уточняет функцию ICMP -сообщения. Таблица 3.1 этих кодов приведена ниже (символом * помечены сообщения об ошибках, остальные являются запросами).
Процедура "отключение источника" (quench, поле тип ICMP=4 ) позволяет управлять потоками данных в каналах Интернет . Не справляясь с обработкой дейтаграмм, ЭВМадресат (или транзитное сетевое устройство) может послать запрос "отключить источник" отправителю, который может сократить темп посылки пакетов, например, вдвое, или вовсе прервать их посылку. Специальной команды, отменяющей прежние запреты, не существует. Если сообщения об отключении прекращаются, источник может возобновить посылку пакетов или увеличить частоту их отправки. Ниже (на рис. 3.2) представлен формат эхозапроса ( ping ) и отклика для протокола ICMP .
Поля идентификатор (обычно это идентификатор процесса) и номер по порядку (увеличивается на 1 при посылке каждого пакета) служат для того, чтобы отправитель мог связать в пары запросы и отклики.
Поле тип определяет, является ли этот пакет запросом (8) или откликом (0). Поле контрольная сумма представляет собой 16-разрядное дополнение по модулю 1 контрольной суммы всего ICMP -сообщения, начиная с поля тип . Поле данные служит для записи информации, возвращаемой отправителю. При выполнении процедуры ping эхозапрос с временной меткой в поле данные посылается адресату. Если адресат активен, он принимает IP -пакет, меняет адрес отправителя и получателя местами и посылает его обратно. ЭВМ-отправитель, восприняв этот отклик, может сравнить временную метку, записанную им в пакет, с текущим показанием внутренних часов и определить время распространения пакета ( RTT - round trip time ). Размер поля данные не регламентирован и определяется предельным размером IP -пакета.
| ICMP-сообщение | описание сообщения | |
|---|---|---|
| Тип | код | |
| 0 | Эхо-ответ (ping-отклик) | |
| 3 | Адресат недостижим | |
| 0 | * Сеть недостижима | |
| 1 | * ЭВМ недостижима | |
| 2 | * Протокол недоступен | |
| 3 | * Порт недоступен | |
| 4 | * Необходима фрагментация сообщения (установлен флаг DF) | |
| 5 | * Маршрутизация отправителя нереализуема | |
| 6 | * Сеть места назначения неизвестна | |
| 7 | * ЭВМ места назначения неизвестна | |
| 8 | * Исходная ЭВМ изолирована (устарело) | |
| 9 | * Связь с сетью места назначения административно запрещена | |
| 10 | * Связь с ЭВМ места назначения административно запрещена | |
| 11 | * Сеть не доступна для данного вида сервиса (TOS) | |
| 12 | * ЭВМ не доступна для данного вида сервиса (TOS) | |
| 13 | * Связь административно запрещена с помощью фильтра | |
| 14 | * Нарушение старшинства ЭВМ | |
| 15 | * Дискриминация по старшинству | |
| 4 | 0 | * Отключение источника при переполнении очереди (quench) |
| 5 | Переадресовать (изменить маршрут) | |
| 0 | Переадресовать дейтаграмму в сеть (устарело) | |
| 1 | Переадресовать дейтаграмму на ЭВМ | |
| 2 | Переадресовать дейтаграмму для типа сервиса (ToS) и сети | |
| 3 | Переадресовать дейтаграмму для типа сервиса и ЭВМ | |
| 8 | 0 | Эхо запроса (ping-запрос) |
| 9 | 0 | Объявление маршрутизатора |
| 10 | 0 | Запрос маршрутизатора |
| 11 | Для дейтаграммы время жизни истекло (ttl=0): | |
| 0 | *при передаче | |
| 1 | * тайм-аут при сборке (случай фрагментации) | |
| 12 | * Проблема с параметрами дейтаграммы | |
| 0 | * Ошибка в IP-заголовке | |
| 1 | * Отсутствует необходимая опция | |
| 13 | Запрос временной метки | |
| 14 | Временная метка-отклик | |
| 15 | Запрос информации (устарел) | |
| 16 | Информационный отклик (устарел) | |
| 17 | Запрос адресной маски | |
| 18 | Отклик на запрос адресной маски | |
Так как в пакете ICMP нет поля порт , то при запуске нескольких процессов PING одновременно может возникнуть проблема с тем, какому из процессов следует передать тот или иной отклик. Для преодоления этой неопределенности следует использовать уникальные значения полей идентификатор .
Время распространения ICMP -запроса, вообще говоря, не равно времени распространения отклика (ситуация с очередями, например, в маршрутизаторах может быть разной). Это связано не только с возможными изменениями в канале. В общем случае маршруты их движения могут быть различными. Те же запросы используются при выполнении процедуры Traceroute .
Эта процедура позволяет не только диагностировать, но и оптимизировать маршрут . Например, команда traceroute cernvm.cern.ch , выданная в ЭВМ SUN (ИТЭФ), может отобразить на экране (в скобках указаны IP -адреса узлов и значения времени жизни дейтаграмм, значения RTT приводится в миллисекундах) (таблица 3.1.1.):
| traceroute to crnvma cern ch | (128 141 2 4) 30 hops max, 40 byte packets | |
|---|---|---|
| 1 | itep-fddi-bbone | (193.124.224.50) 3 ms 2 ms 3 ms |
| 2 | msu - tower .moscow.ru.radio- msu .net | (193.124.137.13) 3 ms 3 ms 3 ms |
| 3 | npi- msu .moscow.ru.radio- msu .net | (193.124.137.9) 27 ms 3 ms 9 ms |
| 4 | desy.hamburg.de.radio- msu .net | (193.124.137.6) 556 ms 535 ms 535 ms |
| 5 | * 188.1.133.56 | (188.1.133.56) 637ms 670ms |
| 6 | duesseldorf2.empb.net | (193.172.4.12) 740ms(ttl=59!) 839ms(ttl=59!) 2066ms(ttl=59!) |
| 7 | bern3.empb.net | (193.172.4.30) 2135ms (ttl=58!) 1644ms (ttl=58!) 1409ms (ttl=58!) |
| 8 | cernh3.euro-hep.net | (193.172.24.10) 1808ms 1508ms 1830ms |
| 9 | cgate1.cern.ch | (192.65.185.1) 1116ms 1270ms 1278ms |
| 10 | crnvma.cern.ch | (128.141.2.4) 1132ms 1362ms 1524ms |
Отсюда видно, что наиболее узкими участками маршрута (на момент выполнения процедуры) являются Гамбург-Дюссельдорф-Берн-CERN. Следует иметь в виду, что канал МГУ-Гамбург был спутниковым и 500мс задержки здесь вносит удвоенное время распространения сигнала до спутника и обратно. Участок Гамбург-Дюссельдорф (X.25, квота 256кбит/с) был общим для потока данных из Германии в США. Передача IP поверх X.25 также снижает эффективную широкополосность канала. Остальные связи обладают недостаточной пропускной способностью. Программа ping показывает для данных участков в часы пик высокую долю потерянных пакетов. Таким образом, имея карту связей и используя указанные процедуры, вы можете успешно диагностировать ситуацию в сети. Продвинутые же программисты могут легко написать свои диагностические программы, базирующиеся на ICMP , как для локальной сети, так и для "окрестного" Интернет .
Когда маршрутизатор не может доставить дейтаграмму по месту назначения, он посылает отправителю сообщение "адресат недостижим" ( destination unreachable). Формат такого сообщения показан ниже (на рис. 3.3).
Поле код содержит целое число , проясняющее положение дел. Перечень кодов таких сообщений помещен в таблице 3.1 . Поле MTU на следующем этапе характеризует максимальную длину пакетов на очередном шаге пересылки. Эта информация ( MTU ) позволяет выбрать оптимальный размер пакета .
Так как в сообщении содержится Интернет -заголовок и первые 64-бита дейтаграммы, легко понять, какой адрес оказался недостижим. Этот тип ICMP -сообщения посылается и в случае, когда дейтаграмма имеет флаг DF=1 ("не фрагментировать"), а фрагментация необходима. В поле код в этом случае будет записано число 4.
Если буфер приема сообщения переполнен, ЭВМ посылает сообщение типа 4.
Так как собственные часы различных ЭВМ имеют свое представление о времени, протокол ICMP , среди прочего, служит для синхронизации работы различных узлов, если это требуется (запросы временных меток). Протокол синхронизации NTP ( network time protocol ) описан в RFC-1119.
Когда дейтаграммы поступают слишком часто и принимающая сторона не справляется с этим потоком, отправителю может быть послано сообщение с требованием резко сократить информационный поток (quenchзапрос). Снижение потока должно продолжаться до тех пор, пока не прекратятся quenchзапросы. Такое сообщение имеет формат, показанный на рис. 3.4 .
В Internet таблицы маршрутизации остаются без изменений достаточно долгое время, но иногда они все же меняются. Если маршрутизатор обнаружит, что ЭВМ использует неоптимальный маршрут , он может послать ей ICMP - запрос переадресации. При этом следует учитывать, что этой возможностью может воспользоваться и хакер . Формат такого сообщения отображен на рисунке 3.5 .
Поле Internet-адрес маршрутизатора содержит адрес маршрутизатора, который ЭВМ должна использовать, чтобы посланная дейтаграмма достигла места назначения, указанного в ее заголовке. В поле internet -заголовок кроме самого заголовка лежит 64 первых бита дейтаграммы, вызвавшей это сообщение. Поле код специфицирует то, как нужно интерпретировать адрес места назначения (см. табл. 3.1).
Команды переадресации маршрутизатор посылает только ЭВМ и никогда другим маршрутизаторам. Рассмотрим конкретный пример. Пусть некоторая ЭВМ на основе своей маршрутной таблицы посылает пакет маршрутизатору M1. Он, просмотрев свою маршрутную таблицу, находит, что пакет следует переслать маршрутизатору M2. Причем выясняется, что пакет из M1 в M2 следует послать через тот же интерфейс , через который он попал в M1. Это означает, что M2 доступен и непосредственно для ЭВМ-отправителя. В такой ситуации M1 посылает ICMP - запрос переадресации ЭВМ-отправителю указанного пакета с тем, чтобы она внесла соответствующие коррективы в свою маршрутную таблицу (либо чтобы администратор поменял IPадрес или маску ЭВМ).
Маршрутная таблица может загружаться из файла, формироваться менеджером сети, но может создаваться и в результате запросов и объявлений, посылаемых маршрутизаторами. После загрузки системы маршрутизатор посылает широковещательный запрос . Один или более маршрутизаторов посылают в ответ сообщения об имеющейся маршрутной информации. Кроме того, маршрутизаторы периодически (раз в 450600 сек.) широковещательно объявляют о своих маршрутах, что позволяет другим маршрутизаторам скорректировать свои маршрутные таблицы. В RFC-1256 описаны форматы ICMP -сообщений такого рода (см. рис. 3.6). Из--за своей уязвимости данная технология в последнее время практически не используется.
Поле число адресов характеризует количество адресных записей в сообщении. Поле длина адреса содержит число 32-битных слов, необходимых для описания адреса маршрутизатора. Поле время жизни предназначено для записи продолжительности жизни объявленных маршрутов (адресов) в секундах. По умолчанию время жизни равно 30 мин. Поля уровень приоритета представляют собой меру приоритетности маршрута по отношению к другим маршрутам данной подсети. Чем больше этот код, тем выше приоритет. Маршрут по умолчанию имеет уровень приоритета 0. Формат запроса маршрутной информации (8 октетов,
