Разберемся с теорией
Как правило, производительность сетевого оборудования тестируется по методике RFC2544. В рамках такого тестирования определяется пропускная способность, задержки, потери трафика и некоторые другие параметры. Тестирование проходит на фреймах размером 64, 128, 256, 512, 1024, 1280, 1518 байт. Единая методология тестирования позволяет сопоставить между собой оборудование различных производителей, а пакеты различной длины – оценить возможности для отличающихся типов трафика. Хорошим тоном является дополнительный тест на смешанном трафике IMIX (Internet MIX) – пакетах разного размера в среднестатистическом соотношении.
Это соотношение не является истиной в последней инстанции. Существует несколько версий профиля, и они периодически меняются. Некоторые заказчики собирают статистику внутри своей сети и формируют «корпоративный» IMIX.
Производительность криптошлюза в общем случае зависит от множества факторов:
· Тип трафика
В большинстве случаев производительность зависит от размера передаваемых пакетов. Тут прямая зависимость: чем больше пакет передаваемых данных, тем выше производительность, и наоборот.
· Функционал
У различных вендоров есть различные режимы работы, а также дополнительные сервисы на борту (МСЭ, NAT и т.д.). Если «включить всё», то с большой долей вероятности производительность устройства в целом уменьшится.
· Параметры железа и софта
Объединим эти параметры в один пункт, так как чаще всего криптошлюзы поставляются именно в виде программно-аппаратного комплекса. Бутылочным горлышком может стать какой-либо компонент платформы (процессор, сетевая карта, внутренняя шина) или софт (неполное использование всех ресурсов платформы, неоптимизированные алгоритмы работы продукта).
Вендоры и реализация
После предыдущего раздела, наверняка возникли сомнения: разве всегда производительность зависит от размера пакета? Конечно, тут есть свои нюансы и зависят они от конкретной реализации.
Программная реализация
Если СКЗИ реализовано программно и установлено на совершенно стандартную x86 аппаратную платформу, то указанное выше абсолютно верно. Современные процессоры не содержат инструкций по ускорению ГОСТ-алгоритмов (в отличие от AES ☹).
В таком случае шифрование и большинство других фич производятся с каждым пакетом индивидуально на программном уровне. Итого: получаем высокую производительность на больших пакетах и весьма скромную – на маленьких. Это актуально как для работы криптошлюза на сетевом уровне L3, так и на канальном L2.
Размер пакета |
Производительность, Мбит/c |
64 |
100 |
512 |
250 |
1500 |
400 |
IMIX |
245 |
Каждый производитель по-разному подходит к публикации этих данных.
«ИнфоТеКС» и «Код Безопасности» размер пакета не называют, по нашему опыту, указанные цифры получены на пакетах близких к 1500 байт, с учётом инкапсуляций и протоколов вендоров:
· ViPNet Coordinator HW 4 (вкладка «Модификации»);
· АПКШ Континент (в описании каждой модели).
У С-Терра указаны две цифры – на больших пакетах (по аналогии с конкурентами) и на смешанном трафике, который позволяет более точно подойти к выбору.
Самая полная информация по тестам на пакетах разного размера есть у ТСС.
Также нужно отметить, что для программной реализации, независимо от вендора, характерна высокая задержка – несколько миллисекунд.
Программно-аппаратная реализация
В этом случае производительность шифрования существенно выше, так как платформа оптимизирована под ГОСТ. Но дополнительные возможности ограничены, а при их включении производительность значительно снижается. Зато задержка у таких решений минимальна и измеряется в микросекундах.
Первый пример в этой категории – Квазар от «СПБ», который в этом году перешагнул с 10 на 100 Гбит/c. Указанная производительность достигается на любом типе трафика. Но это устройство только для шифрования, без дополнительных возможностей. Обычно его обозначают термином «поточный шифратор».
Также стоит обратить внимание на еще один важный параметр: Квазар работает на физическом уровне L1, оборудование нужно соединять оптикой напрямую. С одной стороны, это ограничение по расстоянию между объектами, с другой – отсутствует overhead на заголовки/служебную информацию шифрования, что позволяет полностью использовать емкость канала.
Далее переходим к Континенту с криптоускорителем (обозначается Континент 3.9 IPC-3000FC). Это Континент, в котором шифрование реализуется на отдельной FPGA-плате (это как майнить на видеокарте;).
Продукт выпускается в двух вариациях – под 20 и 40 Гбит/c, детальную информацию можно получить по запросу у производителя. Продукт работает в режиме криптокоммутатора, т.е. для конечных устройств это L2VPN через сети L3.
И в заключении – Dcrypt XG от ТСС с производительностью 100Гбит/c.
В отличии от Квазара продукт работает на канальном уровне и добавляет трафику overhead. Поэтому на маленьких пакетах производительность проседает.
Но это уже не поточный шифратор, есть возможности для реализации более сложных схем и архитектур.
Заказчик
Теория и уловки вендоров закончились. Теперь посмотрим на всё это глазами заказчика.
Допустим, у заказчика есть канал связи от провайдера – 100 Мбит/c. Первично нужно определиться с профилем трафика. Хорошо, если сетевое оборудование заказчика может сделать анализ трафика, например, с помощью Netflow. Если статистику собрать нельзя, то можно предположить, что трафик соответствует IMIX и занимает весь канал.
Далее следует выбор криптошлюза по полученным параметрам. Если предыдущий шаг с профилем трафика пропущен, то есть существенный риск ошибиться в выборе. Обещанная вендором производительность криптошлюза в 100 Мбит/c, конечно, будет достигаться, но на больших пакетах. А трафик из небольших пакетов, например, условная IP-телефония, может остановиться на отметке в 10 Мбит/c. А поскольку trade-in для криптошлюзов – явление весьма редкое, то купленную «железку» придется оставить для решения других задач и под 100 Мбит/c реального трафика купить уже новую.
Чтобы не допускать таких ошибок, перед приобретением в обязательном порядке запрашивайте характеристики оборудования с привязкой к вашему трафику и планируемому функционалу.
Другой вариант – не приобретать оборудование вообще, а пользоваться услугами провайдеров по подписке.
Операторы
Операторы связи (в том числе и мы) предоставляют защищенные каналы связи по сервисной модели.
При добавлении криптошлюзов в инфраструктуру провайдеру необходимо ориентироваться на максимально негативный профиль трафика пользователя – вдруг он будет состоять из огромного числа мелких пакетов.
Дополнительно оператору следует руководствоваться Приказом Министерства информационных технологий и связи РФ от 27 сентября 2007 г. N 113 «Об утверждении Требований к организационно-техническому обеспечению устойчивого функционирования сети связи общего пользования», который выдвигает дополнительные требования к показателям потерь и задержкам.
Для удовлетворения требований оператору следует либо покрыть все свои линии связи поточными шифраторами, либо устанавливать оборудование под каждого клиента с предварительным согласованием требуемой производительности. Для массовой реализации первого варианта рынок пока не готов, но отдельные задачи решаемы (например, для организации связи между выделенными ЦОДами). В большинстве случаев мы идем вторым путем.
В целом в своей практике мы ориентируемся на верифицированные собственной лабораторией производительности оборудования на трафике вида IMIX. И тут есть своя особенность: указанная вендором оборудования производительность обычно делится на два, так как трафик в канале может быть двусторонним (т.е. криптошлюзу надо шифровать в одном направлении и расшифровывать – в обратном).
Зачастую для клиента это выглядит странно: на сайте вендора указана производительность оборудования - 100 Мбит/c, а провайдер услуг предлагает поставить его на канал не выше 20 Мбит/c. А все дело в том, что производительность этого оборудования на пакетах 1500 составляет 100 Мбит/c, а на IMIX – чуть больше 40 (с учетом двустороннего трафика получаем уже 20).
Рассмотрим это на примере ТСС (без укора вендору, ведь данные публичны!):
Еще у операторов при организации наложенной VPN есть правило хорошего тона – увеличить MTU на размер overhead СКЗИ при наличии технической возможности. Без этого неизбежно снижение MTU и возможна фрагментация пакетов, которая снижает производительность, а для некоторых приложений в принципе неприемлема.
Итого
Выбор СКЗИ «на глазок» чреват для пользователя либо недостаточной производительностью, либо переплатой. Предварительный анализ вашего трафика и полная информация от производителя СКЗИ поможет сделать правильный выбор.
Провайдеры подходят к сайзингу при выборе оборудования пессимистично, чтобы минимизировать кейсы с недостаточной производительностью. Но согласовать уменьшение производительности всегда возможно.
Источник: Хабр