Решение проблем, связанных с фрагментацией IP, а также с MTU, MSS и PMTUD, при помощи протоколов GRE и IPSEC

Решение проблем, связанных с фрагментацией IP, а также с MTU, MSS и PMTUD, при помощи протоколов GRE и IPSEC Содержание Введение Фрагментация и сборка IP Проблемы, связанные с IP-фрагментацией Как избежать использования IP-фрагментации: что такое максимальный размер сегмента протокола TCP и как это работает Что такое PMTUD? Проблемы, связанные с PMTUD Типичные топологии сетей, требующие использования PMTUD Что такое туннель?

Соображения относительно туннельных интерфейсов Маршрутизатор как PMTUD-участник в конечной точке туннеля «Чистый» режим туннелирования IPsec Совместное использование GRE и IPsec Дополнительные рекомендации Дополнительная информация Введение Цель этого документа – описать, как работает IP-фрагментация и алгоритм PMTUD, а также рассмотреть ряд сценариев, включая поведение алгоритма PMTUD с различными комбинациями IP-туннелей. В результате широкого распространения IP-туннелей в Интернете на передний план вышли проблемы IP-фрагментации и PMTUD. Фрагментация и сборка IP Семейство протоколов IP было создано для использования в самых различных каналах передачи данных.

Несмотря на то что максимальная длинна IP-датаграммы равна 64 Кбайт, в большинстве каналов передачи данных используется меньшее значение. Это значение называется «максимально допустимый размер пакета» (maximum transmission unit – MTU). Величина MTU зависит от типа канала связи. Структура IP учитывает эти различия, позволяя маршрутизаторам фрагментировать IP-датаграммы в соответствии с требованиями канала связи. Приемная станция отвечает за восстановление исходной IP-датаграммы (сборку фрагментов). Процедура фрагментации заключается в разбивке единой датаграммы на несколько частей, которые позже будут собраны вместе. При IP-фрагментации и сборке используются следующие параметры:

источник IP, назначение, идентификация, общая длина и поля смещений фрагментов, а также флаги в заголовке IP – more fragments (еще фрагменты) и don't fragment (не фрагментировать). Более подробно о процессах IP-фрагментации и повторной сборки см. в документе RFC 791 . На рисунке ниже показана схема IP-заголовка.

Стр. 1

Идентификация представляет собой 16-битовое значение, присвоенное отправителем IP-датаграммы для помощи в повторной сборке фрагментов датаграммы. Поле смещения фрагмента составляет 13 бит и указывает область, к которой принадлежит фрагмент в исходной IP-датаграмме. Это значение является кратным восьми байтам. Во флаговых полях IP-заголовка три бита используются под управляющие флаги. Здесь необходимо отметить, что флаг DF (don't fragment – не фрагментировать) играет главную роль в алгоритме PMTUD: он сообщает о том, можно ли фрагментировать пакет или нет. Бит 0 зарезервирован. Его значение всегда равно 0. Бит 1 – это флаг DF (0 = фрагментация разрешена, 1 = фрагментация запрещена).

Бит 2 – это флаг MF (0 = последний фрагмент, 1 = еще фрагменты). На следующем рисунке показан пример фрагментации. При сложении всех величин IP-фрагментов конечное значение будет больше исходной величины IP-датаграммы на 60 байт. Такое увеличение связано с тем, что в ходе фрагментации были созданы три дополнительных IP-заголовка, по одному для каждого фрагмента, который следует после первого фрагмента. Первый фрагмент имеет нулевое смещение и длину 1500 (сюда входят 20 байт, добавившихся в связи с незначительной модификацией исходного IP-заголовка). Смещение второго фрагмента составляет 185 (185 x 8 = 1480).

Это означает, что блок данных этого фрагмента начинается с 1480 байта исходной IP-датаграммы. Данный фрагмент имеет длину равную 1500 (сюда также входит дополнительный IP-заголовок, созданный для этого фрагмента). Смещение третьего фрагмента – 370 (370 x 8 = 2960), что означает, что блок данных этого фрагмента начинается с 2960 байта исходной IP-датаграммы. Данный фрагмент имеет длину равную 1500 (сюда также входит дополнительный IP-заголовок, созданный для этого фрагмента). Четвертый фрагмент имеет смещение 555 (555 x 8 = 4440), что означает, что порция данных этого фрагмента начинается с 4440 байта исходной IP-датаграммы.

Данный фрагмент имеет длину равную 700 (сюда также входит дополнительный IP-заголовок, созданный для этого фрагмента). Значение Бит 0 (зарезервирован) Бит 1 DF Бит 2 MF 0 0 Разрешено Последний 1 0 Запрещено Не последний

Стр. 2

Определить размер исходной датаграммы можно только тогда, когда получен последний фрагмент. Значение смещения последнего фрагмента (555) дает смещение, равное 4440 байтам, относительно исходной IP-датаграммы. Если к этом значению добавить байты данных из последнего фрагмента (680 = 700 - 20), то мы получим 5120 байт, это длина исходной IP- датаграммы. В этом случае при добавлении 20 байтов к заголовку IP получается IP-датаграмма исходного размера (4440 + 680 + 20 = 5140). Проблемы фрагментации IP Существует ряд проблем, которые делают нежелательным использование IP-фрагментации. При разбивке IP-датаграммы нагрузка на ЦП и память несколько возрастает.

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

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

Другая проблема, связанная с фрагментацией, относится к обработке «выпавших» фрагментов. При выпадении (утрате) одного из фрагментов IP-датаграммы требуется повторная отправка всей датаграммы, которая также должна пройти фрагментирование. Рассмотрим эту проблему на примере сетевой операционной системы NFS (Network File System). По умолчанию размер блока чтения и записи данных в NFS равен 8192 байт. Таким образом, в NFS размер IP/UDP-датаграммы приблизительно составит 8500 байт, включая NFS-, UDP- и IP-заголовки.

Отправляющая станция, которая подключена к сети Ethernet (MTU = 1500 байт), должна будет разбить датаграмму размером в 8500 байт на шесть частей (пять фрагментов по 1500 байт и один фрагмент – 1100 байт). Если из-за перегрузки канала данных какой-либо фрагмент будет утерян, то отправитель будет вынужден повторно отправить всю исходную датаграмму, а это означает, что потребуется повторная разбивка этой датаграммы на шесть частей. Если из шести пакетов канал сбрасывает один, то вероятность того, что по этому каналу можно передать какие-либо NFS-данные, очень мала, поскольку по крайней мере один IP- фрагмент будет сбрасываться из каждой исходной 8500-байтововой IP-датаграммы.

У брандмауэров, которые фильтруют пакеты или манипулируют ими, используя для этого данные с 4 по 7 уровень (L4 – L7) модели OSI, могут возникнуть проблемы с корректной обработкой IP-фрагментов. При наличии повреждений в IP-фрагментах брандмауэр может заблокировать непервоначальные фрагменты, поскольку в них не содержится информация, которая соответствует установкам пакетного фильтра. Это означает, что принимающий узел не сможет собрать исходную IP-датаграмму. Если брандмауэр настроен таким образом, что он позволяет неначальным фрагментам, имеющим достаточное количество информации, должным образом проходить через фильтр, тогда создается угроза атаки, использующей неначальные пакеты.

Кроме того, некоторые сетевые устройства

Стр. 3

(например устройства распределения нагрузки – Content Switch Engines) распределяют пакеты на основе данных с 4-го по 7-й уровень. Соответственно, если пакет разбит на множественные фрагменты, у получающего устройства могут возникнуть проблемы с реализацией политик. Как избежать использования IP-фрагментации: что такое максимальный размер сегмента протокола TCP и как это работает Максимальный размер сегмента TCP (MSS) определяет максимальный объем данных, который узел намеревается принять в одной TCP/IP-датаграмме. Эта TCP/IP-датаграмма может быть фрагментирована на уровне IP. Значение MSS может передаваться в качестве опции TCP-заголовка только в сегментах SYN.

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

Размер данного сегмента TCP мог достигать 64 кбайт (максимальный размер IP- датаграммы) и мог фрагментироваться на уровне IP для последующей передачи через сеть принимающему узлу. Перед передачей полного сегмента TCP на уровень TCP узел-получатель пересобирал IP-датаграмму. Ниже приводятся несколько примеров, демонстрирующих, каким образом используются значения MSS для того, чтобы ограничить размер TCP-сегментов и, соответственно, размер IP-датаграмм. Пример 1 иллюстрирует первоначальное применение MSS. Размер буфера узла А составляет 16 кбайт, а размер буфера узла В – 8 кбайт. Узлы отправляют и получают значения MSS и настраивают собственные отправляемые MSS для передачи данных друг другу.

Обратите внимание, что узла А и узла В придется фрагментировать IP-датаграммы, размер которых больше размера блока MTU на интерфейсе, но меньше отправленного значения MSS, потому что TCP-стек может передавать данные размеров в 16 кбайт или 8 кбайт вниз на стек IP. В случае узла В пакеты придется фрагментировать дважды: один раз – перед передачей в сеть Token Ring и второй раз – перед передачей в сеть Ethernet. Сценарий 1 Узел A отправляет свое значение MSS (16 кбайт) узлу B. 1. Узел B получает от узла А значение MSS равное 16 кбайт. 2. Узел B устанавливает значение MSS для отправки равное 16 кбайт. 3. Узел B отправляет узлу А значение MSS равное 8 кбайт. 4.

Узел А получает от узла В значение MSS равное 8 кбайт. 5. Узел А устанавливает значение MSS для отправки равное 8 кбайт. 6. Для того чтобы избежать IP-фрагментации на конечных точках TCP-соединения, значение MSS было установлено равным минимальному размеру буфера и размеру MTU исходящего интерфейса (-40). Числовые значения MSS обычно на 40 байт меньше

Стр. 4