Накладные расходы IPsec: режим, NAT-T и алгоритмы всё меняют
Одна опубликованная цифра накладных расходов описывает одну инкапсуляцию на одном пути. Сложите заголовки, о которых ваш туннель действительно договаривается, и затем измерьте путь.
Где-то в руководстве есть число, обычно от шестидесяти до восьмидесяти байт, которое кто-то вычел из 1500, чтобы получить MTU интерфейса. Это число описывает одну конкретную инкапсуляцию на одном конкретном пути. Измените режим, внешнее семейство адресов, шифр или наличие NAT, и арифметика больше не относится к вашему туннелю.
Число пришло из другого туннеля
Накладные расходы не свойство IPsec в отвлечённом смысле. Это свойство пакета, который действительно строится: согласованный режим, внешний заголовок, заголовок защиты, заполнение, поле целостности и, возможно, дополнительная обёртка UDP.
Число, которое приводят для транспортного режима с IPv4 и без NAT, описывает пакет меньше, чем туннельный режим с IPv6 при прохождении NAT. Оба верны для своего случая. Копирование любого из них в другое развёртывание это и есть способ получить MTU, который ломает большие передачи. Сбой тихий, потому что небольшие запросы продолжают работать.
Сложите слои, которые действительно есть
Начните с внешнего заголовка IP и двигайтесь внутрь. В туннельном режиме исходный пакет находится внутри, поэтому внешний заголовок это добавление, а не замена. RFC 4303 описывает заголовок ESP, заполнение и данные целостности, которые за ним следуют.
| Layer | What it adds | When it applies |
|---|---|---|
| Outer IP header | 20 bytes for IPv4, 40 for IPv6 | Always, and 40 rather than 20 if the outer path is v6 |
| ESP header | 8 bytes of SPI and sequence number | Always |
| Block cipher IV | 8 to 16 bytes depending on the transform | When the negotiated cipher uses one |
| Padding and trailer | Padding to the block size, plus two trailer bytes | Always, and the amount varies with payload length |
| Integrity data | 12 to 16 bytes for common authenticated ciphers | When integrity protection is negotiated |
| UDP encapsulation | 8 bytes | NAT traversal on port 4500, which is common for clients behind NAT |
Ни одна из этих строк не постоянна между развёртываниями, а строка заполнения не постоянна даже внутри одного развёртывания. В этом вся причина, по которой одна опубликованная цифра накладных расходов разочаровывает.
Два сайта могут не согласиться насчёт одного и того же туннеля
Защищённому пакету всё равно нужно пересечь внешний путь, а внешний путь не везде одинаков. Линия доступа PPPoE несёт меньше, чем чистый сегмент Ethernet. Мобильная сеть может сжаться ещё сильнее, а провайдер, который туннелирует собственный трафик, добавляет ещё одну инкапсуляцию, о которой никто не упомянул. Туннель, который работает на одной линии и отказывает на другой, описывает вторую линию, а не протокол.
Оба направления тоже могут различаться. Асимметричный маршрут может дать работающую выгрузку и застрявшую загрузку, что читается как проблема приложения, пока не посмотришь на размеры пакетов, а не на доступность. Успешный маленький ping доказывает очень мало о полноразмерном ответе.
Измеряйте, а не вычитайте
Найдите наибольшую дейтаграмму, которая проходит путь. Затем сравните её со значением, которое сообщает интерфейс:
ip link show eth0 | grep -o 'mtu [0-9]*' ip xfrm state list ping -M do -s 1400 198.51.100.7 ping -M do -s 1372 198.51.100.7 tcpdump -ni any -c 20 'esp or udp port 4500'
Понижайте размер ping, пока не начнут приходить ответы, и считайте наибольшее работающее значение бюджетом этого пути. Вывод xfrm говорит, какой режим и какие алгоритмы согласованы, и это вход для любого честного расчёта. Захват подтверждает, что именно идёт по проводу, ESP или ESP в обёртке UDP, и это решает вопрос с NAT без догадок.
Оставьте одно значение и для плоскости управления. Пакеты рукопожатия IKE имеют другую структуру, чем пакеты данных, поэтому размер, выведенный из захвата рукопожатия, это не MTU плоскости данных.
Поставьте число туда, где ему место
Для TCP через туннель ограничение MSS часто является наименее инвазивным средством, потому что уменьшает то, что отправляют конечные точки, не меняя сам туннель. Для туннеля на основе маршрутов задайте MTU туннельного интерфейса осознанно и задокументируйте почему. Сделать и то и другое сразу, а потом измерять не даст никакой информации о том, что помогло.
Держите вместе в заявке согласованный режим, внешнее семейство, состояние NAT и воспроизводимый симптом. Записанный набор из четырёх фактов лучше запомненной константы, и это единственный вариант, который переживёт следующее обновление клиента.