Узкие места классификации пакетов: почему программные фильтры не справляются на 100G

Высокопроизводительные шлюзы VPN и магистральные узлы агрегации обрабатывают колоссальные объемы сетевого трафика. При скорости соединений 25 Гбит/с, 40 Гбит/с или 100 Гбит/с частота поступления пакетов регулярно превышает десятки миллионов единиц в секунду (Mpps). В таких условиях классификация пакетов — анализ полей заголовков для принятия решений о маршрутизации, фильтрации, ограничении полосы и передаче в туннель — становится главным узким местом системы.

Исторически инженеры Linux настраивали правила проверки пакетов с помощью цепочек iptables или базовых таблиц nftables. Несмотря на эффективность на стандартных маршрутизаторах, эти программные решения наталкиваются на фундаментальные физические барьеры:

  1. Линейный перебор правил в контексте программных прерываний: Программные межсетевые экраны проверяют фильтры строго последовательно. Когда миллионы пакетов поступают в стек через обработчики ksoftirqd, перебор сотен правил забирает практически все такты процессора. Если на порт VPN обрушивается неавторизованный поток UDP, процессорные ядра перегружаются еще до того, как смогут проверить полезную нагрузку.
  2. Ошибки побитового смещения в классификаторах старого поколения: Классический классификатор u32 в подсистеме Linux Traffic Control требовал ручных расчетов побитовых смещений. Переменная длина опций IPv4, расширенные заголовки IPv6 и вложенные туннели часто приводят к неверному расчету смещений u32.
  3. Перегрузка системной шины памяти и вытеснение кэша: При чисто программной обработке каждый входящий пакет должен пересечь шину PCIe и выделить буфер sk_buff в оперативной памяти. Под высокой нагрузкой кэш-память L2/L3 процессора непрерывно сбрасывается, лишая криптографические конвейеры ChaCha20-Poly1305 и AES-GCM ресурсов для своевременных вычислений.

Для обеспечения передачи на полной скорости канала и исключения перегрузок ksoftirqd современным шлюзам VPN необходим структурированный классификатор, способный переносить логику проверок напрямую в кремниевые чипы сетевых адаптеров: Linux TC Flower (cls_flower).

Архитектура классификатора потоков Linux TC Flower (cls_flower)

Интегрированный в современные версии ядра Linux, классификатор Flower (cls_flower) превращает подсистему Linux Traffic Control (tc) в производительный механизм разбора потоков. В отличие от низкоуровневых смещений u32, Flower задействует встроенный в ядро анализатор протоколов (net/core/flow_dissector.c) для структурированного чтения полей на уровнях L2, L3 и L4.

+-------------------------------------------------------------------------+
|                        Входящий кадр Ethernet (Ingress)                 |
+-------------------------------------------------------------------------+
                                    |
                                    v
+-------------------------------------------------------------------------+
|                  Механизм анализа потоков (Flow Dissector)              |
|     - Разбор L2: MAC-адреса, идентификатор VLAN, EtherType              |
|     - Разбор L3: Адреса источника и назначения IPv4/IPv6, DSCP          |
|     - Разбор L4: Порты UDP/TCP, флаги состояния TCP, типы ICMP          |
|     - Разбор идентификаторов инкапсуляции туннелей (VNI, Tunnel ID)     |
+-------------------------------------------------------------------------+
                                    |
                                    v
+-------------------------------------------------------------------------+
|                   Хэш-таблица масок Flower (Mask-and-Match)             |
|   - Поиск за фиксированное время O(1) по сконфигурированным кортежам   |
+-------------------------------------------------------------------------+
         |                                  |
   Правило совпало                    Правило не совпало
         |                                  |
         v                                  v
+-----------------------+          +-----------------------+
|  Назначенное действие |          | Стандартная обработка |
|  - drop (сброс пакета)|          | Обычный стек IP ядра  |
|  - mirred redirect    |          +-----------------------+
|  - police (лимит)     |
|  - skbedit priority   |
+-----------------------+

Главные архитектурные преимущества TC Flower

  • Хэш-таблицы масок (Mask-and-Match): Flower объединяет правила по битовым шаблонам. Вместо линейного сканирования входящий пакет единожды хэшируется по заданным полям заголовков, обеспечивая классификацию со скоростью O(1) независимо от общего числа правил в системе.
  • Глубокая поддержка сетевых параметров: Flower распознает сложные атрибуты пакетов без ручных вычислений, включая теги VLAN (vlan_id, vlan_prio), приоритеты DSCP (ip_tos), флаги установки соединений TCP (tcp_flags syn) и сигнатуры портов UDP.
  • Модульные цепочки действий: При совпадении критериев Flower активирует специализированные команды: немедленный сброс (action drop), перенаправление на уровне оборудования (action mirred egress redirect), ограничение полосы (action police) или назначение приоритета в буфере сокета (action skbedit).

Для включения Flower на сетевом интерфейсе предварительно создается дисциплина очередей ingress:

# Добавление входящей дисциплины на физический интерфейс enp1s0f0
tc qdisc add dev enp1s0f0 ingress

# Фильтрация и сброс нежелательных пакетов UDP на внутренние порты
tc filter add dev enp1s0f0 ingress protocol ip prio 10 flower \
    ip_proto udp \
    dst_port 53 \
    action drop

Достижение предельной скорости с аппаратной разгрузкой ASIC

Хотя Flower обеспечивает высокую скорость программной обработки в ядре, его ключевое преимущество заключается в прямой поддержке аппаратной разгрузки ASIC (Hardware Offload) на базе подсистемы switchdev.

Сетевые платы корпоративного сегмента (такие как Intel Columbiaville E810 или Mellanox ConnectX-5/6/7) содержат программируемые процессоры обработки пакетов с памятью TCAM (Ternary Content Addressable Memory). При установке флагов аппаратной разгрузки ядро транслирует правила Flower в микрокод и записывает их непосредственно во внутренние таблицы коммутации сетевого адаптера.

+-------------------------------------------------------------------+
|               Физический оптический канал связи                   |
+-------------------------------------------------------------------+
                                  |
                                  v
+-------------------------------------------------------------------+
|               Оптический трансивер и уровень MAC/PHY              |
+-------------------------------------------------------------------+
                                  |
                                  v
+-------------------------------------------------------------------+
|          Аппаратный процессор и таблицы TCAM сетевой платы        |
|                  (Правила TC Flower в кремнии карты)              |
|                                                                   |
|   Правило: Сброс UDP-флуда (skip_sw)    --> [СБРОС В КРЕМНИИ]     |
|   Правило: Порт 51820 RiceGuard         --> [ПРЯМОЙ DMA В ЯДРА CPU|
+-------------------------------------------------------------------+
            | (Только проверенные зашифрованные пакеты идут дальше)
            v
+-------------------------------------------------------------------+
|                 Шина PCIe и оперативная память хоста              |
+-------------------------------------------------------------------+
                                  |
                                  v
+-------------------------------------------------------------------+
|          Многопоточный криптографический конвейер RiceGuard       |
+-------------------------------------------------------------------+

Три режима аппаратного выполнения правил TC Flower

При развертывании правил сетевой инженер может четко регламентировать место выполнения:

  1. Автоматическая разгрузка (По умолчанию): Если драйвер сетевой карты поддерживает правило, ядро загружает его в ASIC адаптера и одновременно сохраняет копию в программной памяти. При заполнении таблиц контроллера система автоматически возвращается к программной обработке.
  2. Режим skip_hw: Ограничивает выполнение правила памятью ядра без задействования аппаратных ресурсов сетевой платы. Применяется для специфических правил с неподдерживаемыми действиями.
  3. Режим skip_sw (Исключительно аппаратное выполнение): Требует, чтобы правило исполнялось строго внутри кремниевого чипа сетевой платы. Если адаптер не может перенести правило целиком, утилита tc мгновенно возвращает ошибку.

Пример настройки аппаратного фильтра на канале 100 Гбит/с:

# Аппаратный сброс пакетов с поддельными адресами в кремнии сетевой платы
tc filter add dev enp1s0f0 ingress protocol ip prio 1 flower \
    src_ip 198.51.100.0/24 \
    skip_sw \
    action drop

# Перенаправление авторизованных потоков VPN в приоритетную очередь
tc filter add dev enp1s0f0 ingress protocol ip prio 2 flower \
    ip_proto udp \
    dst_port 51820 \
    skip_sw \
    action skbedit priority 1

Благодаря параметру skip_sw паразитный трафик уничтожается на физическом уровне Ethernet PHY/MAC сетевого адаптера. Пакеты не попадают на шину PCIe, не создают структуры sk_buff в оперативной памяти и не вызывают прерываний процессора.

Применение политик безопасности в инфраструктуре RiceGuard

В распределенной инфраструктуре VPNRice протокол RiceGuard объединяет современные криптографические алгоритмы с аппаратным управлением потоками для гарантии предельной пропускной способности и изоляции пользователей.

+-------------------------------------------------------------------+
|                     Граничный сервер VPNRice                      |
|                                                                   |
|   +-----------------------------------------------------------+   |
|   |         Сетевой адаптер 100 GbE (Intel / Mellanox)        |   |
|   |         Память TCAM: Правила TC Flower (skip_sw)          |   |
|   +-----------------------------------------------------------+   |
|         |                                           |             |
|   [Порт 51820: Валидный VPN]              [Неавторизованный флуд] |
|         |                                           |             |
|         v                                           v             |
|   Выделенное кольцо RX DMA                Сброс в кремнии карты   |
|         |                                 (0% нагрузки на CPU)    |
|         v                                                         |
|  +-------------------------------------------------------------+  |
|  |             Криптографическое ядро RiceGuard                |  |
|  |             Дешифрование ChaCha20-Poly1305 на скорости линии|  |
|  +-------------------------------------------------------------+  |
|         |                                                         |
|         v                                                         |
|  +-------------------------------------------------------------+  |
|  | Изолированные пространства имен и защищенные DNS-резолверы |  |
|  | Полная защита от нежелательных утечек исходного трафика     |  |
|  +-------------------------------------------------------------+  |
+-------------------------------------------------------------------+

1. Входная демультиплексация потоков

Вместо того чтобы направлять входящий поток в общую очередь ядра, RiceGuard применяет фильтры TC Flower для распознавания сессий WireGuard/RiceGuard. Аппаратный чип сетевой платы распределяет эти пакеты по индивидуальным очередям приема, привязанным к выделенным ядрам через механизм Receive Side Scaling (RSS). Это снижает блокировки памяти и сохраняет задержку на уровне менее миллисекунды.

2. Защита от объемных атак до этапа аутентификации

Неавторизованный поток пакетов способен нарушить стабильность шлюза VPN из-за постоянных попыток установления соединений. Используя аппаратное ограничение полосы (action police rate 100mbit burst 10k drop skip_sw), узлы шлюза отсекают избыточный трафик прямо в чипе платы. Атакующие пакеты отбрасываются до процессора, что сохраняет стабильность криптографических модулей.

3. Сегментация сетевых пространств и защита от утечек

Каждая группа клиентов внутри RiceGuard изолирована в собственном сетевом пространстве имен Linux (netns). Правила перенаправления TC Flower исключают передачу незашифрованных внутренних пакетов во внешние физические интерфейсы. Одновременно внутри каждого сетевого сегмента функционируют локальные резолверы DNS, исключающие утечки DNS-запросов и сохраняющие строгую конфиденциальность сетевых соединений при высоких нагрузках.