IPSec и фрагментация пакетов

Отличная статья про фрагментацию пакетов и PMTUD

При использовании IPSec необходима инкапсуляция пакетов, что ведет к увеличению их размеров.

 

Если размеры получившегося пакета превышают MTU, то маршрутизатор шифрует пакет, а затем его фрагментирует.  Таким образом, принимающий маршрутизатор, должен сначала собрать все фрагменты воедино, а затем расшифровать получившийся пакет. Процесс сборки обычно происходит на process level, что серьезно влияет на производительность. По этой причине фрагментации пакетов желательно избегать, где это возможно. Существуют несколько способов решения данной проблемы. Некторые требуют настройки маршрутизаторов, другие предполагают изменение настроек на конечных клиентах и серверах.

1.       Изменение MTU на конечных станциях. Возможно установить значение MTU на клиентах и серверах меньше, чем стандартное 1500 байт. Рекомендуемое в таком случае значение MTU равно 1300 байт.  К сожалению, масштабы сети часто не позволяют легко и непринужденно поменять настройки на всех машинах. В таком случае, можно попробовать ограничиться серверами, т.к. по большей части именно они являются генераторами больших пакетов.

2.       Path MTU Discovery

Эта фича была придумана, чтобы избежать необходимости фрагментации в принципе.  Она позволяет узлам определить самое маленькое MTU на пути следования пакетов и использовать его в дальнейшем. В этом случае конечная станция шлет пакеты с выставленным битом DF (запрет на фрагментирование).  Если на пути пакета попадается маршрутизатор, чей MTU меньше размеров пакетов, то этот маршрутизатор отсылает ICMP сообщение  type 3, code 4 Fragmentation needed and DF set. В неиспользуемой части ICMP пакета содержится значение MTU, используемое маршрутизатором.  Передающий хост может использовать это значение для корректировки собственного MTU. К сожалению, очень часто маршрутизаторы настроены подавлять отсылку ICMP сообщений type 3, например, с помощью популярной команды настройки интерфейса no ip unreachables. Лучше этого не делать, а если очень хочется, то использовать ip local route-map (разрешив отправку ICMP type 3, code 4). Если, конечно, IOS поддерживает cef switching для route-map (и если cef для local route-map возможен в принципе?).

3.       VPN Interface MTU

Можно подкорректировать, выставить значение 1300 на туннельном интерфейсе

ip mtu 1300

4.       Look Ahead Fragmentation

Фундаментально решает проблемы фрагментации, изменив порядок фрагментации и шифрования. Получив пакет, маршрутизатор просчитывает размер пакета после инкапсуляции, и в случае превышения MTU сначала  фрагментирует пакет, а затем шифрует получившиеся пакетики. Фича доступна с версии IOS 122(13)T и включена по умолчанию.

5.       TCP Maximum Fragment Size

Единственный способ повлиять на размер входящего пакета в условиях, когда не удается договориться с админами на втором конце. TSP MSS определяет максимальный размер TCP сегмента, что, в конечном итоге, определяет размер пакета. Влияет, естественно, только на TCP трафик.  UDP пакеты в основном не превышают  300  байт  за исключением видео.

По историческим причинам (до изобретения PMTUD) MTU для хостов за пределами локальной сети был равен 1300 байт. Отсюда взялось ограничение TCP MSS в 1260 байт (1300 – 20-byte-IP-header – 20-byte-TCP-header).  После внедрения PMTUD это ограничение было снято.

Каждый  из хостов при установлении TCP соединения анонсирует свой MSS в SYN пакетах(необязательно совпадающие).

Команда конфигурирования интерфейса

ip tcp adjust-mss 1260

принудительно переводит поведение TCP сессий в до-PMTUD эпоху. При использовании этой команды на интерфейсе  маршрутизатор переписывает значения MSS в TCP SYN пакетах, полученных на этом интерфейсе. Что, впрочем, заметно нагружает маршрутизатор.