какие сетевые элементы могут выполнять фрагментацию ip пакетов
Описание и структура IPv4
IP (internet protocol — протокол) — маршрутизируемый сетевой протокол, протокол сетевого уровня семейства («стека») TCP/IP. IPv4 описан в RFC 791 (сентябрь 1981 года).
Основные положения:
Структура IP пакета
Пакет протокола IP состоит из заголовка и поля данных. Максимальная длина пакета 65 535 байт. Заголовок обычно имеет длину 20 байт и содержит информацию о сетевых адресах отправителя и получателя, о параметрах фрагментации, о времени жизни пакета, о контрольной сумме и некоторых других. В поле данных IP- пакета находятся сообщения более высокого уровня.
Рассмотрим поля структуру IP- пакета на конкретном примере. 
IP фрагментация, MTU, MSS, и PMTUD
Фрагментация IP пакетов: MTU, MSS, и PMTUD. PMTUD (Path MTU Discovery) и проблема фрагментации пакетов (network mtu ping packet)
Фрагментация подразумевает разбиение блока данных (пакета) на равные части. Соответственно после фрагментации следующим этапом следует сборка фрагментов. Протокол IP позволяет выполнять фрагментацию только тех пакетов, которые поступают на входные порты маршрутизаторов. Следует различать фрагментацию сообщений в узле-отправителе, и динамическую фрагментацию сообщений в маршрутизаторах. Дело в том, что практически во всех стеках протоколов есть протоколы, которые осуществляют фрагментацию сообщений прикладного уровня на такие части, которые укладываются в кадры канального уровня. В стеке TCP/IP, например, эту задачу решает протокол транспортного уровня TCP. Этот протокол может разбивать поток байтов, передаваемый ему с прикладного уровня на сообщения нужного размера (например, на 1460 байт для протокола Ethernet).
Поэтому протокол IP в узле-отправителе не использует свои возможности по фрагментации пакетов.
А вот при необходимости передать пакет в следующую сеть, для которой размер пакета является слишком большим, IP-фрагментация становится необходимой.
В функции уровня IP входит разбиение слишком длинного для конкретного типа составляющей сети сообщения на более короткие пакеты с созданием соответствующих служебных полей, нужных для последующей сборки фрагментов в исходное сообщение.
В большинстве типов локальных и глобальных сетей значения MTU, то есть максимальный размер поля данных, в которое должен инкапсулировать свой пакет протокол IP, значительно отличается.
Итак, необходимость фрагментации пакетов на уровне IP мы пояснили. Теперь перейдем к самому процессу фрагментации пакетов IP.
Как мы уже выяснили из предыдущего раздела нашего урока, в поле Flags заголовка IP-пакет может быть помечен как не фрагментируемый. Любой пакет, помеченный таким образом, не может быть фрагментирован модулем IP ни при каких условиях.
Даже в том случае, если пакет, помеченный как не фрагментируемый, не может достигнуть получателя без фрагментации, то он просто уничтожается, а узлу-отправителю посылается соответствующее сообщение.
Протокол IP допускает возможность использования в пределах отдельной подсети ее собственных средств фрагментирования, невидимых для протокола IP.
Процедуры фрагментации и сборки протокола IP рассчитаны на то, чтобы пакет мог быть разбит на практически любое количество частей, которые впоследствии могли бы быть вновь собраны.
Для того, чтобы не перепутать фрагмент различных типов, в заголовке IP-пакетов используется поле Identification.
Поле смещения фрагмента (Fragment Offset) сообщает получателю положение фрагмента в исходном пакете. Смещение фрагмента и длина определяют часть исходного пакета, принесенную этим фрагментом. Флаг «more fragments» показывает появление последнего фрагмента. Модуль протокола IP, отправляющий неразбитый на фрагменты пакет, устанавливает в нуль флаг «more fragments» и смещение во фрагменте.
Все эти поля дают достаточное количество информации для сборки пакета.
Итак, чтобы разделить на фрагменты большой пакет, модуль протокола IP, установленный, например, на маршрутизаторе, создает несколько новых пакетов и копирует содержимое полей IP-заголовка из большого пакета в IP-заголовки всех новых пакетов. Данные из старого пакета делятся на соответствующее число частей, размер каждой из которых, кроме самой последней, обязательно должен быть кратным 8 байт.
Размер последней части данных равен полученному остатку.
Каждая из полученных частей данных помещается в новый пакет.
Когда происходит фрагментация, то некоторые параметры IP-заголовка копируются в заголовки всех фрагментов, а другие остаются лишь в заголовке первого фрагмента.
Процесс фрагментации может изменить значения данных, расположенных в поле параметров, и значение контрольной суммы заголовка, изменить значение флага «more fragments» и смещение фрагмента, изменить длину IP-заголовка и общую длину пакета.
В заголовок каждого пакета заносятся соответствующие значения в поле смещения «fragment offset», а в поле общей длины пакета помещается длина каждого пакета.
Теперь давайте рассмотрим процесс сборки фрагментов пакетов.
Чтобы собрать фрагменты пакета, модуль протокола IP объединяет IP-пакеты, имеющие одинаковые значения в полях идентификатора, отправителя, получателя и протокола.
Таким образом, отправитель должен выбрать идентификатор таким образом, чтобы он был уникален для данной пары отправитель-получатель, для данного протокола и в течение того времени, пока данный пакет (или любой его фрагмент) может существовать в составной IP-сети.
Вполне очевидно, что модуль протокола IP, отправляющий пакеты, должен иметь таблицу идентификаторов, где каждая запись соотносится с каждым отдельным получателем, с которым осуществлялась связь, и указывает последнее значение максимального времени жизни пакета в IP-сети.
Однако, поскольку поле идентификатора допускает 65 536 различных значений, некоторые хосты могут использовать просто уникальные идентификаторы, не зависящие от адреса получателя.
В некоторых случаях целесообразно, чтобы идентификаторы IP-пакетов выбирались протоколами более высокого, чем IP, уровня.
Процедура объединения заключается в помещении данных из каждого фрагмента в позицию, указанную в заголовке пакета в поле «fragment offset».
Итак, после длительных объяснений давайте закрепим на примере все, что мы сейчас узнали о фрагментации IP-пакетов.
Рассмотрим процесс фрагментации IP-пакетов при передаче между сетями с разным размером пакетов на примере, который показан на этом рисунке. 
Канальный и физический уровни обозначены, как К1, Ф1, К2, Ф2 соответственно.
Пусть компьютер 1 связан с сетью, имеющей значение MTU в 4096 байт, например с сетью FDDI.
При поступлении на IP-уровень компьютера 1 сообщения от транспортного уровня размером в 5600 байт протокол IP делит его на два IP-пакета. В первом пакете устанавливает признак фрагментации и присваивает пакету уникальный идентификатор, например 486.
Признак фрагментации во втором пакете равен нулю, что показывает, что это последний фрагмент пакета.
Общая величина IP-пакета составляет 2800 плюс 20 (размер IP-заголовка), то есть 2820 байт, что умещается в поле данных кадра FDDI.
Далее модуль IP компьютера 1 передает эти пакеты своему сетевому интерфейсу (образуемому протоколами канального уровня К1 и физического уровня Ф1)
Сетевой интерфейс отправляет кадры следующему маршрутизатору.
После того, как кадры пройдут уровень сетевого интерфейса маршрутизатора (К1 и Ф1) и освободятся от заголовков FDDI, модуль IP по сетевому адресу определяет, что прибывшие два пакета нужно передать в сеть 2, которая является сетью Ethernet и имеет значение MTU, равное 1500.
Следовательно, прибывшие IP-пакеты необходимо фрагментировать.
Маршрутизатор извлекает поле данных из каждого пакета и делит его еще пополам, чтобы каждая часть уместилась в поле данных кадра Ethernet.
Затем он формирует новые IP-пакеты, каждый из которых имеет длину 1400 + 20 = 1420 байт, что меньше 1500 байт, поэтому они нормально помещаются в поле данных кадров Ethernet.
В результате в компьютер 2 по сети Ethernet приходят четыре IP-пакета с общим идентификатором 486.
Протокол IP, работающий в компьютере 2, должен правильно собрать исходное сообщение.
Если пакеты пришли не в том порядке, в котором были посланы, то смещение укажет правильный порядок их объединения.
Отметим, что IP-маршрутизаторы не собирают фрагменты пакетов в более крупные пакеты, даже если на пути встречается сеть, допускающая такое укрупнение. Это связано с тем, что отдельные фрагменты сообщения могут перемещаться по интерсети по различным маршрутам, поэтому нет гарантии, что все фрагменты проходят через какой-либо промежуточный маршрутизатор на их пути.
При приходе первого фрагмента пакета узел назначения запускает таймер, который определяет максимально допустимое время ожидания прихода остальных фрагментов этого пакета.
Таймер устанавливается на максимальное из двух значений: первоначальное установочное время ожидания и время жизни, указанное в принятом фрагменте.
Таким образом, первоначальная установка таймера является нижней границей для времени ожидания при c6opке. Если таймер истекает раньше прибытия последнего фрагмента, то все ресурсы сборки, связанные с данным пакетом, освобождаются, все полученные к этому моменту фрагменты пакета отбрасываются, а в узел, пославший исходный пакет, направляется сообщение об ошибке.
Для системного администратора
IP Фрагментация
В данном документе мы рассмотрим, что такое IP фрагментация, как она происходит и почему является нежелательным явлением в сетях, а также рассмотрим пару сценариев как ее предотвратить.
IP Фрагментация и Реассемблирование
IP Протокол был спроектирован для использования на широком разнообразии каналов передачи данных. Хотя максимальная длина датаграммы IP – 64 КБ, большинство каналов передачи данных устанавливают максимальный предел длины пакета, названный MTU.
Значение MTU зависит от типа канала передачи данных. Дизайн IP протокола приспосабливается к различным MTU, разрешая маршрутизаторам фрагментировать IP датаграммы по мере необходимости. За сборку (реассемблирование) фрагментов обратно в оригинальную IP датаграмму полного размера ответственна принимающая сторона.
IP Фрагментация это разбиение датаграммы на множество частей, которые могут быть повторно собраны позже. Для IP фрагментации и повторной сборки используются такие поля из IP заголовка как источник, адресат, идентификация, полная длина, и смещение фрагмента, наряду с флажками “больше фрагментов” (MF) и “не фрагментировать” (DF).
Изображение ниже изображает расположение IP заголовка
Идентификация это 16 битовое поле и есть значение, назначенное отправителем IP датаграммы. Используется для последующей сборки фрагментов датаграммы.
Смещение фрагмента это поле 13 битов и указывает, какому месту принадлежит фрагмент в оригинальной IP датаграмме. Это значение всегда кратно восьми байтам.
В области флажков заголовка IP, есть три бита для флажков управления. Важно отметить, что бит “не фрагментировать” (DF) играет основную роль во фрагментации, потому что он определяет, можно ли фрагментировать пакет.
Бит 0 – зарезервирован и всегда сброшен в 0. Бит 1 – это бит DF (0 – можно фрагментировать, 1 – нельзя). Бит 2 – это бит MF (0 – это последний фрагмент, 1 = есть еще фрагменты)
На график ниже показ пример фрагментации.
Если вы сложите все длины IP фрагментов, то полученное значение превысит оригинальную длину IP датаграммы на 60 байт. Причина,такого увеличения состоит в том, что были созданы три дополнительных IP заголовка, по одному для каждого фрагмента после первого.
Первый фрагмент имеет смещение 0, длина этого фрагмента – 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, созданный для этого фрагмента.
Только, когда получен последний фрагмент, может быть определен размер оригинальной IP датаграммы. Смещение фрагмента в последнем фрагменте (555) дает смещение данных в 4440 байтов в оригинальной IP датаграмме. Если вы добавите байты данных от последнего фрагмента (680 = 700 – 20), это даст вам 5120 байтов, что является порцией данных оригинальной IP датаграммы. Затем, добавляя 20 байтов для IP заголовка мы получим размер оригинальной IP датаграммы (4440 + 680 + 20 = 5140).
Проблемы IP фрагментации
Существуют несколько проблем, когда IP фрагментация нежелательна. Чтобы фрагментировать IP датаграмму требуются больше ресурсов CPU и памяти. Это справедливо как для отправителя так и для маршрутизатора между отправителем и получателем. Создание фрагментов просто влечет за собой создание заголовков для IP фрагментов и копирование оригинальной датаграммы во фрагменты. Это может быть сделано достаточно эффективно, потому что вся информация для создания фрагментов уже доступна.
Фрагментация накладывает больше расходов для получателя, когда он повторно собирает фрагменты, потому что получатель должен выделять память для прибывающих фрагментов и соединять их обратно в одну датаграмму после того, как получены все фрагменты. Реассемблирование на хосте это не проблема, потому что хост имеет время и ресурсы памяти, чтобы посвятить их этой задаче.
Но, реассемблирование очень неэффективно на маршрутизаторе, основная работа которого – пересылать пакеты как можно быстрее. Маршрутизатор не спроектирован, чтобы удерживать пакеты в течение любого отрезка времени. Также маршрутизатор, делающий реассемблирование выбирает наибольший доступный буфер (18 КБ), для этой работы, потому что это у него нет никакого способа узнать размер оригинального IP пакета, пока не получен последний фрагмент.
Другая проблема фрагментации это обработка отброшенных фрагментов. Если один фрагмент IP датаграммы отброшен, то вся оригинальная датаграмма должна быть послана повторно, и она будет также фрагментирована. В качестве примера, можно посмотреть на NFS. NFS, по умолчанию, читает и пишет блоки данных по 8192 байт, таким образом NFS IP/UDP датаграмма будет приблизительно 8500 байтов (включая NFS, UDP, и IP заголовки). Станция отправитель, связанная с Сетью Ethernet (MTU 1500) должна будет фрагментировать 8500-байтовую датаграмму на шесть частей; пять 1500-байтовых фрагментов и один 1100-байтовый фрагмент. Если любой из этих шести фрагментов будет отброшен из-за перегрузки канала связи, полная оригинальная датаграмма должна быть повторно передана, а это означает, что еще должны быть созданы шесть фрагментов. Если снова один из шести пакетов потеряется в канале, то вероятнось того, что любые данные NFS могут быть переданы по этому каналу связи стремится к нулю, так как по крайней мере будет отброшен один IP фрагмент от каждой 8500-байтовая NFS датаграммы.
У межсетевых экранов, которые фильтруют или управляют пакетами, основываясь на информации уровня 4 (L4) до уровеня 7 (L7), могут возникать трудности с корректной обработкой IP фрагментов. Если IP фрагменты – не упорядочены, межсетевая защита может блокировать не начальные фрагменты, потому что они не несут информацию, которая соответствовала бы фильтру пакета. Это означает, что оригинальная IP датаграмма не может быть повторно собрана хостом при получении. Если межсетевой экран конфигурирован так, чтобы разрешать прохождение неначальных фрагментов с недостаточной информацией, которая не соответствует правилам фильтрации должным образом, то межсетевой экран может пропустить атаку, основанную на неначальных фрагментах. Кроме того, некоторые сетевые устройства (типа Контентных Движков) направляют пакеты, основываясь на информации уровней L4 – L7, и если пакет состоит из нескольких фрагментов, то у устройства могут возникнуть трудности с применением своих политик к таким пакетам.
Предотвращение IP фрагментации. Что такое TCP MSS и как оно работает
Максимальный Размер TCP Сегмента (MSS) определяет максимальное количество данных, которые хост желает принимать в единственной TCP/IP датаграмме. Эта TCP/IP датаграмма может быть фрагментирована в уровне IP. Значение MSS посылают как опциию TCP заголовка только в сегменте TCP SYN. Каждая сторона на TCP соединении сообщает свое значение MSS другой стороне. Хост отправитель обязан ограничивать размер данных в единственном TCP сегменте в значение, меньшем или равном MSS, о котором сообщает хост получатель.
Первоначально, значение MSS означало, сколько памяти нужно выделить (больше или равной 65496 КБ) на станции получателя, чтобы в состоянии хранить TCP данные, содержавшиеся в пределах единственной IP датаграммы. MSS был максимальным сегментом (кусочком) данных, которые желал принимать TCP получатель. Этот TCP сегмент мог быть огромным, примерно до 64 КБ (максимальный размер IP датаграммы), и его необходимо было фрагментировать на уровне IP, чтобы передать по сети к хосту получателю. Принимающий хост повторно должен был собрать IP датаграмму прежде, чем передать полный TCP сегмент на уровень TCP.
Рассмотрим ниже несколько показательных сценариев, от том как установливаются и используются значения MSS, чтобы ограничить размеры TCP сегмента, и соотвественно, размеры IP датаграммы.
Сценарий 1 иллюстрирует способ, которым реализовывлся MSS ранее. Хост A имеет буфер 16 КБ а Хост B – буфер 8 КБ. Они посылают и получают свои МSS значения и корректируют их чтобы послать данные друг другу. Заметьте, что Хост A и Хост B должны фрагментировать IP датаграммы, которые по размеру больше чем MTU интерфейса, но все еще меньше чем посылаемый MSS, потому что стек TCP может передать 16 КБ или 8 КБ данных в IP стек. В случае Хоста B, пакеты могут быть фрагментированы дважды, один раз, чтобы дойти до Token Ring LAN и еще раз, чтобы добраться до сети Ethernet.
Для того, чтобы уйти от IP фрагментации, на конечных точках TCP соединения, выбранные значения MSS были изменены на минимальный размер буфера и MTU исходящего интерфейса (-40). Значение MSS на 40 байт меньше чем значение MTU, потому что MSS это только размер TCP данных, который не включает 20-байтовый заголовок IP и 20-байтовый заголовок TCP. MSS основан на значениях размера заголовков по умолчанию; стек отправителя должен вычесть соответствующие значения для IP заголовка и TCP заголовка в зависимости от того, какая используется TCP или IP опция.
Способ которым теперь работает MSS это то, что каждый хост сначала сравнивает свой MTU исходящего интерфейса с его собственным буфером и выберет самое низкое значение в качестве MSS, для посылки. Затем хосты сравнят полученный размер MSS, с их собственным MTU интерфейса и снова выберут меньшее из двух значений.
Сценарий 2 иллюстрирует этот дополнительный шаг, сделанный отправителем, чтобы избежать фрагментации на локальных и удаленных каналах. Посмотрите, как принимается во внимание MTU исходящего интерфейса каждым хостом (прежде, чем хосты пошлют друг другу свои значения MSS), и как это помогает избежать фрагментации.
1460 это значение, выбранное обоими хостами как МSS посылка друг для друга. Часто посылаемое значение MSS будет тем же самым на каждой стороне TCP соединения.
В Сценарии 2, фрагментация не происходит, потому что хостами были приняты во внимание MTU обоих интерфейсов. Пакеты могут все еще фрагментироваться в сети между Router A и Router B, если они встретят линк с более низким MTU.
В следующих статьях мы рассмотрим, что такое PMTUD, а также вопросы прохождения пакетов в туннелях когда GRE и IPSEC работают вместе.
Понятия IP фрагментация, MTU, MSS, PMTUD и их связь
Данный пост написан по мотивам статьи «Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC» c сайта Cisco, рассказывающей про работу механизма Path Maximum Unit Discovery (PMTUD) в связке с разными механизмами туннелирования IP.
IP фрагментация и обратная сборка
Длина IP пакета может достигать 64 Кбайтов, что может превышать размер фрейма (MTU) протокола нижнего уровня, в который инкапсулируется IP. Поскольку IP может передаваться по средам с разными значениями MTU, в него был встроен механизм фрагментации. Задача принимающей стороны обратно собрать фрагменты в оригинальный IP пакет.
При IP фрагментации IP пакет делится на несколько кусочков (фрагментов), оформленных таким образом, чтобы у принимающей машины была возможность их собрать в оригинальный IP пакет. Для ее работы в заголовке IP пакета используются сл. поля: адрес источника и получателя, идентификационный номер, размер пакета, смещение фрагмента и флаги: «не фрагментировать» (DF) и «у пакета еще есть фрагменты»(MF).
Проблемы с IP фрагментацией
При работе с IP фрагментацией следует помнить о нескольких особенностях.
Обход IP фрагментации путем использования TCP MSS.
TCP Maximum Segment Size (MSS) определяет максимальный размер данных, который машина готова получить через один TCP сегмент. Сам TCP сегмент инкапсулируется в IP пакет. Значение MSS передается в заголовке TCP SYN при установлении соединения между двумя узлами (через механизм трехэтапного установления соединения). Обе стороны соединения передают значение своего MSS. В отличие от популярного заблуждения, принимаемое значение MSS не несет характер переговоров. Отправляющий хост обязан ограничить размер своих исходящих TCP сегментов значением равным или меньшим значению, сообщенному ему принимающим хостом.
Значение MSS выбирается таким образом, чтобы предотвратить IP фрагментацию. Механизм работы MSS следующий: при создании TCP соединения, машина определяет размер буфера исходящего интерфейса и MTU этого интерфейса. Дальше эти два числа сравниваются и выбирается наименьшее. Тут следует оговориться, что за MTU выбирается число по формуле MTU минус 40 байт, для учета TCP и IP заголовков. Затем выбранное число сравнивается с размером MSS, переданным принимающей стороной, и снова выберется наименьшее значение.
Пример работы MSS:
Таким образом MSS на обеих сторонах установлено равным 1460 байтам, это наиболее частая ситуация.
В данном примере IP фрагментация не будет происходить, поскольку в процессе установления TCP соединения, размер TCP сегментов был взят с расчетом на вмещение в MTU низлежащей сети. Однако, если IP пакет пойдет через сети с меньшим MTU, то может потребоваться фрагментация.
Что такое PMTUD?
В предыдущем примере TCP MSS выполнил работу по избавлению от IP фрагментации. Однако такая ситуация возможна только если MTU сети на пути между двумя хостами будет не ниже MTU исходящих интерфейсов этих машин. На случай различных значений MTU между двумя узлами был создан PMTUD.
Стоит отметить, что PMTUD поддерживается только TCP протоколом, UDP и другие протоколы его не поддерживают. Если машина поддерживает PMTUD, то все TCP IP пакеты помечаются флагом DF («не фрагментировать»).
Когда машина отправляет пакет с DF флагом, работа PMTUD заключается в том, чтобы уменьшать значение MSS в исходящем TCP сегменте, если будет получена информация о том, что пакет нуждается в фрагментации. Машина запоминает значение MTU создавая строчку в таблице маршрутизации до соответствующего получателя.
Если маршрутизатор получает IP пакет, с установленным флагом DF, который он не может передать дальше из-за малого значения MTU исходящего интерфейса, он сбрасывает пакет и отправляет ICMP сообщение «Destination Unreachable» к источнику этого IP пакета указывая «fragmentation needed and DF set» как код ошибки (type 3, code 4). Когда машина, отправлявшая IP пакет, получит данное сообщение, она уменьшит значение MSS, в последующем TCP сегменте.
В соответствии с RFC 1191, маршрутизатор отправляющий ICMP сообщение «fragmentation needed and DF set», должен указать значение MTU исходящего интерфейса.
Механизм PMTUD работает постоянно, поскольку путь от одной машины к другой может измениться. Получив сообщение «Can’t Fragment» он обновляет таблицу маршрутизации машины.
PMTUD выполняется для обоих направлений TCP независимо, т.к. пути входящего и исходящего трафика могут различаться.
Проблемы PMTUD
В процессе работы PMTUD могут произойти три проблемы:
Из описанных выше проблем, вторая является наиболее частой. Все ICMP пакеты просто отфильтровываются межсетевым экраном и не доходят до отправителя отброшенного пакета.
Если возможности пропускать ICMP сообщения нет, то могут применяться другие способы.
С распространением различного вида туннелирования трафика проблема IP фрагментации стала более насущной. Из-за появления допольнительных заголовков размер IP пакета увеличивался и уже не влезал в MTU сети. Например, GRE добавляет 24 байта к пакету, что может привести к IP фрагментации из-за того, что MTU исходящего интерфейса не способно передать пакет целиком.
Что такое туннель?
Туннель представляет из себя виртуальный интерфейс, который позволяет инкапсулировать пассажирский пакет в транспортный протокол. Этот механизм используется в схемах инкапсуляции типа точка-точка.
Туннель состоит из следующих частей:
Инкапсуляция трафика при работе туннеля используется, в частности, для связи географически разнесенных сетей (VPN).
Роль маршрутизатора при работе PMTUD на концах туннеля
Маршрутизатор может играть две роли при работе PMTUD на концах туннеля
Общая последовательность действий маршрутизатора при работе с инкапсуляцией.
Стоит отметить что ICMP сообщения передаются между двумя адресатами, и не передаются дальше, увеличивая кол-во шагов.
Чистый IPsec в туннельном режиме
IPsec позволяет осуществлять подтверждение подлинности (аутентификацию), проверку целостности и/или шифрование IP-пакетов, включая данную информацию в IP пакеты, увеличивая тем самым их размер. Получившийся размер варьируется в зависимости от используемых протоколов.
IPsec может работать в двух режимах:
IPsec также поддерживает механизмы PMTUD и изменения флага DF у своих пакетов.
Пример.
Совместная работа GRE и IPsec
Несколько сложнее дела обстоят, когда IPsec используется для шифрования GRE туннелей. Совместная работа этих технологий необходима, поскольку IPsec не поддерживает IP мультикаст, на котором основываются протоколы динамической маршрутизации, которые могут использоваться в VPN сети. GRE с другой стороны поддерживает мультикаст и может быть использован, для того чтобы сначала инкапсулировать мультикастовый пакет протокола динамической маршрутизации в юникастовый пакет GRE, который затем шифруется IPsec. В данной связке IPsec обычно используется в транспортном режиме, поскольку точки туннеля GRE и пиры IPsec одни и те же, что позволит сохранить 20 байт на излишней IPsec информации.
Может так случиться, что IP пакет разделен на два фрагмента, каждый из которых инкапсулирован GRE. В таком случае IPsec зашифрует каждый из пакетов по отдельности. Получившееся после шифрования пакеты, могут быть слишком большими и потребовать повторной фрагментации. Такая «двойная фрагментация» уменьшает эффективность работы маршрутизаторов и снижает пропускную способность.
Для того, чтобы избежать данной ситуации можно вручную указать MTU виртуального туннельного интерфейса GRE, чтобы нивелировать размер дополнительной информации, добавляемой GRE и IPsec в пакет. Рекомендуемое значение MTU для GRE в таком случае составляет 1400 байт, для ситуаций, когда MTU исходящего интерфейса равно 1500 байтам.
Пример.
Вывод
Суммируя вышенаписанное можно подвести некоторые итоги: