IPsec
Слой IPsec в объекте Библиотека → Сетевые туннели защищает трафик плагина (HTTP, PCAP Replay, Flood и др.) с помощью IKE и ESP. Создайте профиль с нужными слоями (при необходимости VLAN, VXLAN, GRE или IP-IP + IPsec), затем выберите его в группе Сетевые туннели клиентского или серверного плагина.
Основные параметры
Табл. – Параметры профиля IPsec
| Название | Описание |
|---|---|
| Тип туннеля | Выберите IPsec. |
| Source IP или пул | Внешний source IP для IKE/ESP. Поддерживаются один IPv4-адрес, один CIDR или один непрерывный диапазон. |
| Адреса концов туннеля | Обязательные внешние IP-адреса удалённых пиров. Поддерживаются CIDR, диапазоны и списки через запятую. |
| Метод аутентификации | PSK или RSA-сертификат. |
| Pre-Shared Key | Общий секрет при выборе PSK. |
| Сертификат и ключ | Объекты сертификата и закрытого ключа при выборе RSA. |
| Алгоритмы IKE и ESP | Согласованный с удалённым устройством набор шифрования, DH, PRF и аутентификации. |
| Traffic Selectors | Защищаемые внутренние диапазоны Source и Destination. |
| SA Lifetime и Rekey Time | Время жизни SA и интервал пересогласования. Значение 0 отключает соответствующее ограничение. |
| DPD | Интервал и таймаут Dead Peer Detection. |
| Multi P2 over P1 | Количество Child SA на один IKE SA. |
| NAT-T | Передача ESP в UDP/4500 при прохождении через NAT. |
| PFS | Отдельное DH-согласование ключей Child SA при необходимости. |
Source IP или пул — внешний адрес пакетов IKE/ESP. Source TSi — внутренний адрес защищаемого трафика, который согласуется как Traffic Selector. Внешний пул не заменяет диапазон TSi и наоборот.
Массовое создание туннелей
После выбора профиля IPsec в конструкторе задачи доступны параметры массового сценария.
Табл. – Параметры массового сценария
| Название | Описание |
|---|---|
| Количество IPsec-туннелей | Количество независимых туннелей из выбранного профиля: от 1 до 2 000 000. |
| Скорость открытия | Общая скорость запуска IKE-согласований по всей задаче, а не скорость на каждое ядро. Значение 0 снимает пользовательское ограничение. |
| Уникальный TSi для каждого туннеля | Назначает каждому туннелю отдельный Source TSi /32 из указанного диапазона. По умолчанию выключено. |
| Первый Source TSi / Последний Source TSi | Границы диапазона внутренних адресов. Диапазон должен содержать не меньше адресов, чем создаётся туннелей. |
Для нескольких туннелей укажите в поле Source IP или пул достаточное количество внешних адресов. Адреса распределяются по туннелям последовательно. В обычном CIDR не используются адрес сети и broadcast; в /31 и /32 используются все адреса. Непрерывный диапазон включает обе границы. Например, сеть 192.168.200.0/21 содержит 2046 доступных адресов и подходит максимум для 2046 туннелей.
Пул внешних source IP должен содержать не меньше доступных адресов, чем задано туннелей. На тестируемом устройстве должны быть настроены приём IKE/ESP и обратная маршрутизация для всего внешнего пула.
Если все туннели устанавливаются до одного шлюза, в поле Адреса концов туннеля достаточно указать один адрес: он будет общим удалённым endpoint, а туннели получат разные адреса из внешнего source-пула.
Когда включать уникальный TSi
Включите Уникальный TSi для каждого туннеля, если тестируемое устройство:
- считает Child SA с одинаковыми Traffic Selectors дубликатами и удаляет предыдущую SA как коллизию;
- требует отдельной политики или отдельного защищаемого адреса для каждого туннеля;
- должно однозначно сопоставлять каждый туннель с внутренним источником.
Каждый туннель получит отдельный Source TSi /32, а Destination TSi останется заданным в профиле. Диапазон Source TSi должен соответствовать плану внутренних адресов и политикам на удалённом устройстве. Если устройство допускает несколько SA с одинаковыми selectors, этот переключатель можно оставить выключенным.
Распределение нагрузки
Внутренний трафик направляется только в уже установленные SA.
- Для stateful-трафика число сессий и скорость их открытия пропорционально распределяются по вычислительным потокам. Каждая TCP-, TLS- или stateful UDP-сессия закрепляется за одним готовым туннелем на всё время жизни.
- Для stateless-трафика общая PPS-нагрузка распределяется по вычислительным потокам, а пакеты равномерно чередуются между готовыми туннелями.
Генерация внутреннего трафика начинается, как только готовы первые туннели. Поэтому во время IKE-разгона нагрузка временно приходится на уже установленную часть SA. Измеряйте установившуюся пропускную способность после того, как график Established tunnels вышел на заданный уровень.
Как достичь максимальной производительности
Количество туннелей и CPU
IPsec-туннели распределяются между ядрами агента. При этом число одновременно задействованных ядер не может быть больше числа туннелей: например, 10 туннелей не смогут загрузить больше 10 ядер, даже если агенту выделено больше CPU. Для масштабирования ESP увеличивайте количество независимых туннелей вместе с количеством доступных ядер.
Рекомендуемый порядок настройки:
- Укажите количество туннелей, достаточное для использования нужного числа ядер. Для теста предельной пропускной способности оставьте запас по туннелям и CPU.
- Задайте Скорость открытия ниже измеренной ёмкости стенда, если нужна ровная полка IKE-согласований. Значение
0открывает туннели без пользовательского ограничения и может давать кратковременные всплески. - Дождитесь установления всех туннелей и только после этого оценивайте RPS, PPS и L1 throughput.
HTTP: RPS и количество сессий
Для HTTP целевая скорость определяется произведением:
общий RPS = количество сессий × RPS на одну сессию
В HTTP/1.1 следующая операция в сессии зависит от завершения предыдущего ответа. Если полный ответ занимает больше интервала 1 / RPS на сессию, заданный общий RPS не будет достигнут даже при нулевых счётчиках потерь. Для того же общего RPS увеличьте количество параллельных сессий и уменьшите RPS на одну сессию. Например, вместо 1000 сессий × 100 RPS используйте 2000 сессий × 50 RPS.
Размер HTTP-ответа и целевой L1 throughput
Размер тела HTTP-ответа нельзя вычислять только делением требуемой скорости на RPS: на линии также передаются Ethernet/IP/TCP, HTTP, ESP и, при наличии, UDP NAT-T/VLAN-заголовки. При MTU 1500 большой ответ разбивается на несколько пакетов, и служебные данные добавляются к каждому пакету.
Сначала вычислите доступный бюджет на один ответ на линии:
байт на линии на один ответ = целевой L1 bps / (8 × целевой RPS)
размер тела ≈ байт на линии на один ответ − служебные данные стека
Для 100 000 RPS и 90 Гбит/с L1 бюджет составляет 112 500 байт на линии на один ответ. Для типового IPv4 + TCP + HTTP/1.1 + ESP при MTU 1500 начните с тела 102 400 байт (100 KiB), а затем скорректируйте значение по фактическим графикам. Точный результат зависит от набора заголовков, MSS, алгоритма ESP, NAT-T и VLAN.
Если RPS уже стабилен, фактические служебные данные можно оценить по измерению:
фактические байты на линии на ответ = измеренный L1 bps / (8 × измеренный RPS)
служебные данные ≈ фактические байты на линии на ответ − текущее тело HTTP
Проверка результата
Перед фиксацией результата проверьте:
- Requested, Slots и Established tunnels соответствуют ожидаемому количеству туннелей;
- Failed и IKE timeouts не растут;
- RPS/PPS и L1 throughput оцениваются после завершения IKE-разгона;
- отсутствуют TCP drops/retransmits, ESP no-SA/oversize/PMTU и ошибки или потери на сетевых интерфейсах;
- нагрузка достаточно равномерно распределена по ядрам и RX-очередям.
Если RPS и Гбит/с синхронно колеблются ниже цели, а счётчики ошибок остаются нулевыми, это обычно указывает не на потерю пакетов, а на ограничение параллелизма: недостаточное число туннелей, сессий или задействованных ядер либо неравномерный RSS. Счётчики аномалий подтверждают корректность обработки, но сами по себе не подтверждают достижение заданной производительности.
Остановка задачи
При обычной остановке stateful-задачи сначала прекращается создание новых сессий и закрываются уже открытые внутренние сессии на всех агентах. Затем отправляются IKE/Child SA DELETE с заданной скоростью открытия туннелей. В stateless-задаче генерация пакетов прекращается сразу, после опустошения очередей начинается удаление туннелей. Подробный порядок и отличие от принудительной остановки описаны в разделе Жизненный цикл задачи.
Опубликованные результаты производительности доступны в разделе Benchmarks.