Linux: Полное руководство
Шрифт:
27.1.2. Структура пакетов IP и TCP
Протокол IP не ориентирован на соединение, поэтому не обеспечивает надежную доставку данных. Поля, описание которых приведено в таблице 27.4, представляют собой IP-заголовок и добавляются к пакету при его получении с транспортного уровня.
Структура заголовка IP-пакета Таблица 27.4
| Поле | Описание |
|---|---|
| Source IP-address | IP-адрес отправителя пакета |
| Destination IP-address | IP-адрес получателя пакета |
| Protocol | Протокол: TCP или UDP |
| Checksum | Контрольная сумма для проверки целостности пакета |
| TTL (Time to Live) | Время жизни пакета: определяет,
|
| Version | Версии протокола IP — 4 или 6 (4 бита) |
| Header Length | Длина заголовка пакета (4 бита). Минимальный размер заголовка — 20 байтов |
| Type of Service | Тип обслуживания; обозначение требуемого для этого пакета качества обслуживания при доставке через маршрутизаторы IP-сети. Здесь определяются приоритет, задержки, пропускная способность (8 битов) |
| Total Length | Длина дейтаграммы IP-протокола (16 битов) |
| Identification | Идентификатор пакета. Если пакет фрагментирован (разбит на части), то все фрагменты имеют одинаковый идентификатор (15 битов) |
| Fragmentation Rags | 3 бита для флагов фрагментации и 2 бита для текущего использования |
| Fragmentation Offset | Смещение фрагмента: указывает на положение фрагментов относительно начала поля данных IP-пакета. Если фрагментации нет, смещение равно 0x0 (13 битов) |
| Options and Padding | Опции |
Протокол TCP в отличие от протокола IP ориентирован на установление соединения и обеспечивает надежную доставку данных. Структура TCP-пакета описана в таблице 27.5.
Структура заголовка TCP-пакета Таблица 27.5
| Поле | Описание |
|---|---|
| Source port | Порт TCP узла-отправителя |
| Destination Port | Порт TCP узла-получателя |
| Sequence Number | Номер последовательности пакетов |
| Acknowledgement Number | Номер подтверждения: порядковый номер байта, который локальный узел рассчитывает получить следующим |
| Data Length | Длина TCP-пакета |
| Reserved | Зарезервировано для будущего использования |
| Hags | Флаги: описание содержимого сегмента |
| Window | Показывает доступное место в окне протокола TCP |
| Checksum | Контрольная сумма для проверки целостности пакета |
| Urgent Pointer | Указатель срочности: при отправке срочных данных (поле Flags) в этом поле задается граница области срочных данных |
27.2 Протокол ICMP
27.2.1. Для чего используется протокол ICMP
Протокол межсетевых управляющих сообщений используется для диагностических целей. Например, система А передала системе Б неверный пакет. Система Б с помощью протокола ICMP может «сказать» системе А, что посланный ею пакет некорректен. Также по этому протоколу производится диагностика сети. Многие из вас используют утилиту ping, чтобы определить, доходят ли отправленные вами пакеты до какой-то определенной машины, даже не подозревая о том, что ping использует как раз протокол ICMP.
С помощью протокола ICMP можно определить не только тип неисправности, но и максимально уточнить ее причину. Например, тип сообщения 3 («Адресат недостижим») свидетельствует о том, что посланный нам пакет не может «добраться» до адресата. Кроме типа сообщения, возвращается его код, позволяющий детализировать неисправность. Например, код 0 означает, что сеть недоступна, 1 — узел недоступен. 2 — протокол недоступен и т.д. В таблице 27.8 ниже перечислены типы и коды сообщений ICMP.
Обязательно ли посылать сообщение об ошибке, получив некорректный пакет? Нет, из главы 19 вы узнали, что такие пакеты (например, отправленные на запрещенный для доступа извне порт) можно просто игнорировать. Первый подход «вежливее», второй безопаснее. Представьте, что злоумышленник отправляет с 1000 машин 1000 пакетов с указанием неверного порта на вашу систему. Тогда ваша система только тем и будет заниматься, что отправлять сообщения об ошибках. Это называется атакой на отказ. Конечно, современные брандмауэры позволяют избавиться от этого неприятного явления, но не у всех они установлены и настроены должным образом.
27.2.2.
Структура ICMP-пакетаДля лучшей диагностики ошибки вместе с ICMP-пакетом передается заголовок исходного пакета, вызвавшего ошибку. Также передается специальный указатель на позицию заголовка, позволяющий определить, что именно вызвала ошибку. В случае с неправильным номером порта указатель будет установлен на поле, содержащее номер порта. Благодаря этому система-источник может вычислить процесс и сокет, вызвавшие ошибку.
Структуры различных ICMP-пакетов отличаются друг от друга в зависимости от типа пакета. Например, пакет, сообщающий о недоступности адресата (Destination Unreachable Message), выглядит так:
Сообщение Destination Unreachable Message Таблица 27.6
| Тип | Код | Контрольная сумма |
|---|---|---|
| Не используется | ||
| Интернет-заголовок плюс первые 64 бита оригинального сообщения (пакета) |
Что такое тип и код, вы уже знаете, с контрольной суммой тоже все ясно. А последнее поле необходимо, поскольку оно поможет идентифицировать процесс, вызвавший ошибку.
Точно такую же структуру имеют сообщение об истечении лимита времени (Time Exceeded Message) и сообщение об обрыве источника Source Quench Message (тип 4).
А вот сообщение о неверном параметре (например, указан неверный номер порта) выглядит уже по-другому (таблица 27.7).
Сообщение Parameter Problem Message Таблица 27.7
| Тип | Код | Контрольная сумма |
|---|---|---|
| Указатель | Не используется | |
| Интернет-заголовок плюс первые 64 бита оригинального сообщения (пакета) |
Поле Указатель в сообщении о неверном параметре (Parameter Problem Message) указывает на то место в заголовке, которое вызвало ошибку.
Сообщение о переадресации (Redirect Message) имеет следующую структуру:
Сообщение Redirect Message Таблица 27.8
| Тип | Код | Контрольная сумма |
|---|---|---|
| Адрес шлюза | ||
| Интернет-заголовок плюс первые 64 бита оригинального сообщений (пакета) |
Чтобы понять, что такое сообщение о переадресации, рассмотрим следующий пример. Система Б определяет, что посланный системой А пакет некорректен. Системе Б нужно отправить системе А сообщение об ошибке. Система Б определяет, что единственным маршрутом назад для данного пакета является маршрут через систему А. Тогда система Б посылает системе А два пакета: первый с сообщением о некорректном пакете, а второе — сообщение переадресации, докладывающее, что у системы А проблемы с таблицей маршрутизации, которая, возможно, содержит ошибку.
Сообщения типа эхо-запрос (ping, тип 8) и эхо-ответ (pong, тип 0) имеют следующую структуру:
Сообщения Echo или Echo Reply Message Таблица 27.9
| Тип | Код | Контрольная сумма |
|---|---|---|
| Идентификатор | Последовательность | |
| Данные |
Поля Идентификатор и Последовательность могут использоваться источником эха для передачи вспомогательной информации. Например, идентификатор может использоваться как порт при использовании протоколов TCP/UDP для идентификации службы, а номер последовательности может увеличивается на единицу при отправке каждого запроса (то есть выступать в роли счетчика).
27.2.3. Тип и код ICMP-сообщения
В следующей таблице перечислены все типы ICMP-сообшений. Об их структуре вы можете прочитать в документе RFC 792. Типы 17 и 18 описаны в документе RFC 950.
Типы IСМР-сообщений Таблица 27.8
| Тип | Код | Название сообщения | Описание |
|---|---|---|---|
| 0 | Echo Reply Message | Эхо-ответ | |
| 0 | Код всегда равен 0 | ||
| 3 | Destination Unreachable Message | Адресат недоступен | |
| 0 | Сеть недоступна | ||
| 1 | Узел недоступен — что-то случилось с компьютером возможно, он просто выключен | ||
| 2 | Протокол недоступен — запрашиваемый протокол ни поддерживается | ||
| 3 | Порт недоступен — на машине ни одна служба не связана с указанным номером порта | ||
| 4 | Длина пакета слишком велика, а в его заголовке установлен флаг DF (Don't Fragment), то есть не фрагментировать. Для передачи большого пакета его нужно фрагментировать (разбить на части), а так как установлен флаг DF, фрагментация, а следовательно, и передача пакета невозможна |