Боевой путь. Как реализовался функционал статической и динамической маршрутизации в CoreBit.NGFW

Любой современный межсетевой экран, а тем более многофункциональный межсетевой экран уровня сети, не может нести гордое имя NGFW без функций статической и динамической маршрутизации сетевого трафика. Поэтому перед нашей командой разработки CoreBit.NGFW встали задачи исследования и реализации данных функциональных блоков.

Основной проблемой было то, что задачи необходимо было решать в существующем ядре системы. На момент проработки этого вопроса ядро системы представляло собой инструмент глубокого анализа пакетов (DPI), позволяющий выстроить высокопроизводительный и масштабируемый конвейер фильтрации пакетной и сессионной нагрузки на всех уровнях МВОС. 

DPDK — КРАЕУГОЛЬНЫЙ КАМЕНЬ

Когда мы разрабатывали ядро системы, то сразу отказались от использования стандартного сетевого стека Linux. Основных причин было две: это недостаточная пропускная способность (through put), приводящая к потерям сетевых пакетов, а также большие задержки при прохождении сетевых пакетов (latency). Механизмы пакетирования на разных уровнях сетевого стека частично решали проблему с пропускной способностью, но не решали, а даже усугубляли проблему с задержками. К счастью, для преодоления этих трудностей стали появляться специализированные API обхода ядра сетевого стека Linux (kernel by pass). Одно из таких решений — DPDK, которое и стало краеугольным камнем при разработке архитектуры системы.

Благодаря DPDK мы смогли исключить указанные недостатки за счёт значительного уменьшения количества системных вызовов, изоляции ядер процессора, использования процессорного кеша, RSS-балансировки, а также разделения программной архитектуры на две плоскости — управления и передачи данных. В плоскости передачи данных нами были разработаны специализированные блоки принятия решения, построенные на основе работы не с самими сетевыми пакетами, а с их метаданными, что позволило существенно увеличить скорость принятия решения о фильтрации пакетной и сессионной нагрузки. 

ОПТИМИЗИРОВАННЫЕ СБОРЩИКИ

Для работы с метаданными пакетов разработаны собственные оптимизированные сборщики, используемые нами для обработки протоколов уровней L2–L4. Алгоритмы принятия решений о маршрутах прохождения пакетов, разработаны с использованием структур DPDK, позволяющих хранить данные в хеш-таблицах RTE_HASH. Поиск данных осуществляется с использованием алгоритма LPM (Longest prefix match), реализованного в API «RTE_FIB».

МЕХАНИЗМЫ ЗАЩИТЫ

При имплементации протоколов сетевого взаимодействия ARP и ICMP возникла необходимость разработки механизмов защиты сети от известных сетевых атак, таких как ARP-poisoning и ICMP-flood.

В дополнение к основным функциям межсетевого экрана в него были также включены инструменты проверки целостности и качества соединения (аналог утилиты Ping), а также функционал записи сетевых дампов, которые разрабатывались для внутренних процессов отладки. Мы посчитали, что было бы полезно добавить эти функции в качестве диагностических инструментов для наших клиентов.

АЛГОРИТМЫ АГРЕГАЦИИ И БАЛАНСИРОВКИ

В ходе выполнения проекта была проведена значительная работа по разработке механизмов преобразования и обратного преобразования IP-адресов, а также проброса портов протоколов транспортного уровня в локальную сеть и из неё. С использованием Generic flow API был разработан алгоритм агрегации прямого сетевого потока из локальной сети и алгоритм балансировки обратного сетевого потока в локальную сеть с использованием технологии Receive Side Scaling. Предложенный подход позволил внедрить механизмы NAT без снижения производительности функционала маршрутизации сетевых потоков. 

СИСТЕМНЫЕ ПРЕРЫВАНИЯ

Благодаря использованию аппаратных возможностей сетевых адаптеров в задачах снятия/добавления идентификаторов VLAN, подсчёта контрольных сумм протоколов транспортного уровня и протоколов межсетевого взаимодействия удалось исключить системные прерывания, вызываемые в программных блоках ядра системы для выполнения указанных операций. 

ИМПЛЕМЕНТАЦИЯ АЛГОРИТМОВ

Учитывая, что весь функционал, связанный с обработкой сетевого трафика, разработан в плоскости передачи данных, нам пришлось имплементировать алгоритмы DHCP-клиента и DHCP-сервера, не забыв при этом разработать механизмы защиты от атак, направленных на этот протокол, таких как DHCP-starvation и DHCP-spoofing. 

ВЫБОР API «FRR»

Мы не стали повторять подвиг реализации алгоритмов статической маршрутизации для протоколов динамической маршрутизации. Проведя анализ существующих открытых API, мы остановили свой выбор на API «FRR». Интеграция FRR осуществлялась с использованием DPDK kernel NIC (KNI) с доступом к сетевому трафику через плоскость управления Linux,непосредственно используя разделяемую FIFO-память. Это позволило получить более высокие показатели за счёт сокращения количества системных вызовов и возможностей нулевого копирования пакета из разделяемой памяти.

Особенность работы API «FRR» с KNI заключается в том, что для приёма и передачи сетевого трафика по протоколам BGP и OSPF создаются отдельные виртуальные интерфейсы (VIF). В тот момент, когда API «FRR» получает данные о маршруте, он отправляет их на интерфейс FIB push, а VIF прослушивает этот интерфейс на предмет обновлений маршрутов и заносит изменённые данные в таблицу маршрутизации. Обновления маршрутов предписывают ядру плоскости данных (Data plane) перенаправлять трафик в соответствующий VIF. Благодаря этому сигнализация протоколов маршрутизации следует по медленному пути через KNI к API «FRR», но при этом весь сетевой трафик передаётся по быстрому пути через плоскость управления данных. Интеграция API «FRR» позволила реализовать функционал динамической маршрутизации сетевых потоков по протоколам BGP и OSPF без ухудшения ключевых показателей эффективности функционирования нашего продукта (рис.).

Рисунок. Схема взаимодействия DPDK и FRR

ОЦЕНКА РЕАЛИЗАЦИИ АЛГОРИТМОВ

Стоит отметить, что все оценки практических реализаций наших алгоритмов, используемых при разработке статической и динамической маршрутизаций, мы проводим по собственным методикам нагрузочного и стресс-тестирования с применением ПО IxNetwork и нагрузочных карт тест-центра IXIA с сетевыми интерфейсами 100 GE, а также на трафике реальных вторичных сетей передачи данных.

Мы готовы предоставлять решение на пилот нашим заказчикам уже с IV квартала 2024 года.

Реклама. ООО ГК «ИНФОТАКТИКА», ИНН: 7825382385, Erid: 2Vfnxw8LfKn