Почему рвётся IPsec: overhead, MTU и настоящий пример на 98 байт

IPsec-туннель поднялся, /ip ipsec показывает установленный SA — а у пользователей периодически рвутся скачивания, зависают тяжёлые страницы, RDP подвисает на передаче экрана. Мелкие пакеты (пинги, DNS) при этом летают без проблем. Если SA установлен, но пропадают именно большие пакеты, одна из первых проверок — MTU и работа PMTUD.

Почему это не «просто ещё один протокол»

IPsec заворачивает исходный IP-пакет в новые заголовки: сам ESP, часто плюс GRE (если строится GRE over IPsec для динамической маршрутизации внутри туннеля), плюс UDP-заголовок NAT-T, если хотя бы один конец туннеля сидит за NAT. Каждый из них — это реальные дополнительные байты поверх исходного пакета. Если исходный пакет уже близок к MTU канала (обычно 1500), после инкапсуляции он этот MTU превышает — и дальше либо фрагментируется, либо, если где-то по пути заблокирован ICMP Fragmentation Needed, зависает по классической схеме PMTUD blackhole: маленькие пакеты проходят, большие — молча теряются.

Overhead — это не оценка на глаз, это сумма конкретных заголовков

Разница между «наверное, надо уменьшить MTU на всякий случай» и «уменьшить MTU на 98 байт» — это разница между гаданием и расчётом. Посчитать overhead можно руками или инструментом (Cisco TAC IPsec Overhead Calculator — бесплатный и считает именно то, что нужно). Для конкретной комбинации — GRE over IPsec, NAT-Traversal включён, ESP-AES-128/192/256 + ESP-SHA-256 — на исходном пакете 1390 байт раскладка такая, как на графике выше: семь служебных полей суммарно дают 98 байт. Это результат именно выбранного профиля и размера пакета, а не универсальная константа IPsec: при другой инкапсуляции, алгоритме или длине исходного пакета изменятся padding, ICV и итоговый overhead.

Итог: исходный IPv4-пакет 1390 байт → 1488 байт на проводе. Ни одного байта полезной нагрузки в этих 98 байтах нет — это то, что съедает MTU ещё до данных пользователя.

Как это лечится на MikroTik

Зная overhead, дальше — механика, а не подбор:

1. Уменьшить MTU туннельного интерфейса на величину overhead (с запасом на округление):

/interface gre
set gre-tunnel1 mtu=1400

2. Clamp TCP MSS. В исходной конфигурации 2020 года MSS подрезали отдельным правилом mangle. Для IPv4 без TCP options MSS обычно берут как MTU минус 40 байт:

/ip firewall mangle
add chain=forward tcp-flags=syn protocol=tcp tcp-mss=!0-1360 \
    action=change-mss new-mss=1360 out-interface=gre-tunnel1 \
    comment="clamp MSS for GRE over IPsec"

Обновление от 31 июля 2026 года. В актуальном RouterOS у GRE-интерфейса есть штатное свойство clamp-tcp-mss=yes, включённое по умолчанию. В новой конфигурации сначала проверьте его; рабочий встроенный clamp не нужно дублировать приведённым выше правилом mangle. Историческую команду оставляем, потому что именно такой способ использовался в конфигурации 2020 года.

MSS clamping помогает TCP-сессиям договориться о безопасном размере сегмента при установке соединения, не упираясь в сломанный PMTUD. Для IPv6 расчёт другой: базовые заголовки IPv6 + TCP занимают 60 байт, а не 40.

Итог

Если IPsec SA установлен, но через туннель пропадают пакеты ближе к MTU, стоит проверить размер пакета на проводе и PMTUD. Overhead GRE + ESP + NAT-T — не абстрактная цифра «на всякий случай», а сумма заголовков для конкретной комбинации алгоритмов и размера пакета. Дальше — обоснованный MTU и MSS clamping на MikroTik, а не угадывание значения методом «поставим 1400 и посмотрим».