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

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

Історично системні інженери налаштовували обробку пакетів за допомогою правил iptables або базових таблиць nftables. Хоча вони добре працюють на звичайних маршрутизаторах, суто програмні рішення мають суттєві фізичні обмеження:

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

Для збереження передачі даних на повній швидкості каналу та виключення перевантаження ядер шлюзам 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: IP-адреси джерела й призначення IPv4/IPv6, DSCP        |
|     - Розбір L4: Порти UDP/TCP, прапорці стану TCP, типи ICMP           |
|     - Розбір ідентифікаторів інкапсуляції тунелів (VNI, Tunnel ID)      |
+-------------------------------------------------------------------------+
                                    |
                                    v
+-------------------------------------------------------------------------+
|                   Хеш-таблиця масок Flower (Mask-and-Match)             |
|   - Пошук за сталий час O(1) за налаштованими параметрами               |
+-------------------------------------------------------------------------+
         |                                  |
   Правило збіглося                   Правило не збіглося
         |                                  |
         v                                  v
+-----------------------+          +-----------------------+
|  Призначена дія TC    |          | Стандартне оброблення |
|  - 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:

# Підключення дисципліни 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). Під час передавання правил у режимі розвантаження ядро перетворює їх на мікрокод і записує прямо в таблиці комутатора мережевої карти.

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

Три режими виконання правил TC Flower

Адміністратор може чітко керувати середовищем виконання фільтрів:

  1. Автоматичне розвантаження (Типове): Якщо апаратний драйвер підтримує правило, ядро завантажує його в ASIC мережевої плати та створює дзеркальну копію в пам'яті. У разі нестачі місця в кремнії система непомітно повертається до програмного опрацювання.
  2. Режим skip_hw: Виконує правило виключно в пам'яті ядра без використання ресурсів мережевого адаптера. Підходить для експериментальних правил із нестандартними діями.
  3. Режим skip_sw (Суто апаратне виконання): Вимагає виконання правила виключно в мікросхемах мережевої карти. Якщо адаптер не може виконати правило апаратно, команда tc відразу повертає помилку.

Приклад налаштування чисто апаратного захисту на інтерфейсі 100 Гбіт/с:

# Апаратне відкидання підроблених IP-підмереж у кремнії мережевої карти
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, не займає оперативну пам'ять і не створює переривань процесора.

Реалізація політик захисту в інфраструктурі RiceGuard

У глобальній розподіленій мережі VPNRice архітектура RiceGuard поєднує криптографічні стандарти нового покоління з апаратною диспетчеризацією потоків для збереження граничної пропускної здатності та безпеки користувачів.

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

1. Диспетчеризація вхідних потоків

Замість передавання всього потоку до спільної програмної черги, RiceGuard використовує фільтри TC Flower для миттєвої ідентифікації сесій WireGuard/RiceGuard. Апаратний контролер карти розподіляє їх за окремими чергами приймання, закріпленими за різними ядрами CPU через Receive Side Scaling (RSS). Це усуває конфлікти пам'яті та утримує затримку передавання в межах часток мілісекунди.

2. Захист від перевантаження до етапу автентифікації

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

3. Ізоляція мережевих просторів і захист від витоку

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