Сучасні розподілені атаки на відмову в обслуговуванні (DDoS) регулярно генерують потоки трафіку інтенсивністю в десятки мільйонів пакетів за секунду (Mpps). Для високопродуктивних шлюзів віртуальних приватних мереж (VPN) головною технічною загрозою під час таких атак рідко буває пряме вичерпання пропускної здатності фізичного каналу. Критична відмова трапляється значно глибше — всередині мережевого стека операційної системи, де витрати на виділення памʼяті та перемикання контексту перевантажують процесорні ресурси.

Коли традиційний шлюз під керуванням Linux отримує масований потік пакетів, кожен окремий пакет змушує ядро створювати дескриптор сокетного буфера (sk_buff), генерувати програмні переривання, розбирати заголовки різних рівнів та обробляти правила міжмережевого екрана. За умов навантаження в 10–20 Mpps обробники переривань ядра (ksoftirqd) повністю завантажують процесорні ядра, позбавляючи легітимні VPN-сесії обчислювального часу. Користувачі стикаються з різкими стрибками затримок, втратою пакетів та скиданням процедур погодження ключів.

Щоб гарантувати низькі затримки та безперервну передачу трафіку під час потужних аномалій, сучасні мережеві системи використовують технології eBPF (Extended Berkeley Packet Filter) та XDP (eXpress Data Path). Виконуючи верифікований байт-код безпосередньо в драйвері мережевої карти (NIC) до створення буферів памʼяті, XDP забезпечує перевірку та скидання небажаного трафіку на повній лінійній швидкості інтерфейсу.

Вразливість обʼємних атак: накладні витрати на виділення sk_buff

Щоб зʼясувати, чому класичні міжмережеві екрани виходять із ладу під час інтенсивних атак, слід проаналізувати стандартний цикл обробки вхідних пакетів у Linux. Коли мережевий адаптер фіксує кадр Ethernet:

  1. Запис через DMA: Мережева карта записує байти пакета у кільцевий буфер оперативної памʼяті через прямий доступ до памʼяті (DMA).
  2. Переривання та цикл NAPI: Драйвер надсилає апаратне переривання, ініціюючи роботу опитувача NAPI всередині ядра.
  3. Виділення структури sk_buff: Для кожного пакета ядро створює структуру метаданих sk_buff обсягом у сотні байтів. Ця процедура вимагає очищення памʼяті, налаштування адресних покажчиків та постійного перезапису кеш-ліній процесора.
  4. Проходження мережевого стека: Пакет передається до підсистеми netfilter (перевірка правил iptables, nftables і таблиці conntrack), після чого проходить маршрутизацію та потрапляє до черги сокета.
[ Вхідний потік пакетів (Лінійна швидкість: 10–40 Mpps) ]
                            │
                            ▼
           [ Кільцевий буфер DMA мережевого адаптера ]
                            │
          ┌─────────────────┴─────────────────┐
          │     Класичний стек Linux          │  <── Вузьке місце: перевантаження CPU
          │   Створення памʼяті sk_buff       │      ksoftirqd завантажує ядра на 100%
          │   Правила Netfilter / iptables    │      Постійне скидання кешу процесора
          │   Маршрутизація та черги сокетів  │
          └─────────────────┬─────────────────┘
                            ▼
            [ Модуль ядра WireGuard VPN ]
                            │
          [ Розшифровані дані користувача ]

За звичайних умов така модель забезпечує високу гнучкість. Проте під час атак з посиленням (DNS/NTP-ампліфікація) чи UDP-флуду створення мільйонів обʼєктів sk_buff щосекунди виснажує контролери памʼяті. Процесор витрачає всі ресурси лише на створення та миттєве видалення дескрипторів, не маючи змоги виконувати криптографічну розшифровку легітимного трафіку.

Інженерні принципи архітектури eBPF та XDP

Технологія eBPF перетворює ядро Linux на програмоване середовище виконання. Фахівці пишуть спеціалізовані модулі на обмеженій підмножині мови C. Системний верифікатор ядра контролює безпеку коду (переконується у відсутності нескінченних циклів та ізольованості памʼяті), після чого JIT-компілятор перетворює інструкції на машинний код.

XDP розміщує точку аналізу пакетів на найранішому програмному рівні: безпосередньо всередині драйвера мережевого адаптера, ще до того, як ядро виділить структуру sk_buff чи ініціалізує протокольний стек.

[ Вхідний потік пакетів (Лінійна швидкість: 10–40 Mpps) ]
                            │
                            ▼
           [ Кільцевий буфер DMA мережевого адаптера ]
                            │
      ┌─────────────────────┴─────────────────────┐
      │     Точка перехоплення XDP (рівень драйвера)│
      │  Перевірка байт-коду eBPF менш ніж за 10 нс│
      └─────────┬─────────────────────────┬───────┘
                │                         │
         (Дія скидання)            (Дія пропуску)
                ▼                         ▼
        [ XDP_DROP ]                [ XDP_PASS ]
   (Памʼять не виділяється)   (sk_buff створюється лише
    Скидання на швидкості NIC  для дозволених пакетів)
                                          │
                                          ▼
                            [ Модуль ядра WireGuard ]

Коли вхідний пакет потрапляє до точки XDP, програма eBPF звертається безпосередньо до сирих даних кадру (xdp_buff) і повертає одне зі стандартних рішень:

  • XDP_DROP: Миттєво відкидає пакет на рівні драйвера. Оскільки структура sk_buff не створюється, одне серверне процесорне ядро здатне аналізувати та скидати понад 20 мільйонів пакетів за секунду.
  • XDP_PASS: Спрямовує пакет вгору до мережевого стека Linux для звичайної маршрутизації та передачі сокетам додатків.
  • XDP_TX: Відправляє пакет назад через той самий фізичний порт із можливістю модифікації заголовків без залучення системних буферів.
  • XDP_REDIRECT: Перенаправляє пакет на інший мережевий інтерфейс, оминаючи мережевий стек ядра, або безпосередньо в простір користувача через кільцеві буфери AF_XDP.

Захист шлюзів WireGuard на лінійній швидкості

Протокол WireGuard працює як віртуальний мережевий інтерфейс Layer 3 безпосередньо в ядрі системи. Його формат пакетів починається з простого 4-байтового заголовка з однобайтовим полем типу повідомлення (1 — запит на погодження звʼязку, 2 — відповідь на погодження, 3 — відповідь із cookie-токеном, 4 — зашифровані дані).

Така чітка структура ідеально підходить для апаратно наближеної фільтрації за допомогою eBPF:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Тип (1B)    |                   Резерв                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Індекс відправника                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                Незашифрований ефемерний ключ                  +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Розгортання модуля XDP на фізичному мережевому адаптері дозволяє класифікувати трафік до моменту його передачі модулю WireGuard:

1. Перевірка відповідності структури протоколу

Інструменти генерації атак нерідко надсилають пошкоджені дейтаграми UDP із хибною довжиною або випадковими даними. Фільтр XDP перевіряє довжину UDP-пакета та валідність коду повідомлення WireGuard. Пакети з помилковою структурою миттєво відсікаються через дію XDP_DROP.

2. Обмеження частоти звернень через BPF-таблиці

Програми eBPF синхронізують стан із сервісами керування за допомогою високопродуктивних карт памʼяті BPF Maps (таких як LRU Hash Maps та Per-CPU Array Maps). Якщо певний діапазон IP-адрес перевищує поріг ініціацій, програма XDP збільшує лічильники безпосередньо в процесорному кеші. За умови підозрілої активності наступні пакети з цієї адреси відкидаються на повній швидкості каналу.

WireGuard містить дворівневий механізм захисту за допомогою криптографічних токенів (MAC1 та MAC2) для запобігання підробці адрес та перевантаженню процесора. За умов високого навантаження шлюз вимагає від клієнта дійсний токен MAC2. Модуль eBPF здатний валідувати ці токени безпосередньо в драйвері, відкидаючи неавторизовані запити до початку обчислень на кривій Curve25519 в основному ядрі.

Порівняння архітектурних підходів: iptables, DPDK та eBPF/XDP

Під час проектування високошвидкісних VPN-вузлів зазвичай порівнюють такі підходи:

Параметр iptables / Netfilter DPDK (прямий доступ до обладнання) Архітектура eBPF / XDP
Рівень виконання Усередині мережевого стека ядра Драйвер у просторі користувача Хук драйвера всередині ядра
Виділення памʼяті Створення sk_buff на кожен пакет Власні пули памʼяті поза ядром Без виділення памʼяті при скиданні
Сумісність з інструментами Повна сумісність з Linux Несумісний зі стандартними утилітами Повна інтеграція з маршрутизацією ядра
Використання CPU Критичне перевантаження під час атак 100% завантаження виділених ядер (опитування) Пропорційне реальному обсягу даних

Хоча фреймворк DPDK демонструє значну пропускну здатність, він вимагає виділення окремих ядер CPU під безперервні цикли опитування та унеможливлює використання стандартних служб маршрутизації (наприклад, BIRD для BGP) чи системного інтерфейсу WireGuard.

eBPF та XDP пропонують оптимальний баланс: обробка трафіку на апаратній швидкості без відмови від перевіреної підсистеми маршрутизації Linux.

Реалізація фільтрації на рівні ядра в інфраструктурі VPNRice

Мережа вузлів VPNRice розгортається на базі фільтрації всередині ядра для забезпечення стабільного зʼєднання:

  • Розподіл навантаження через BGP Anycast: Підключення користувачів балансуються між глобальними локаціями Anycast. Обсяги атак розосереджуються за географічним принципом, що запобігає перевантаженню окремих дата-центрів.
  • Фільтрація в драйвері за допомогою XDP: Кожен шлюз виконує модулі eBPF на інтерфейсах зі швидкістю 25 Гбіт/с та 100 Гбіт/с. Нелегітимні потоки даних та підроблені UDP-пакети видаляються з памʼяті драйвера за частки наносекунди.
  • Стабільне передавання даних у RiceGuard: Оскільки паразитна активність не призводить до створення структур sk_buff, процесорні ядра зберігають обчислювальний потенціал для шифрування ChaCha20-Poly1305. Пакетний обмін користувачів обробляється інтерфейсом WireGuard із фіксованим часом затримки.
  • Захист вбудованих DNS-серверів: Внутрішні рекурсивні служби DNS у тунелі повністю ізольовані від зовнішнього трафіку, забезпечуючи миттєву обробку запитів навіть під час мережевих інцидентів.

Рекомендації щодо впровадження фільтрації на рівні ядра

Щоб підвищити стійкість VPN-шлюзів на базі Linux перед атаками відмови в обслуговуванні, слід впроваджувати такі рішення:

  • Обирайте мережеві плати з підтримкою Native-XDP: Переконайтеся, що апаратні адаптери використовують драйвери з нативною підтримкою XDP (наприклад, Intel ixgbe/ice, Mellanox mlx5 або Broadcom bnxt_en).
  • Контролюйте ліміти памʼяті в BPF Maps: Під час налаштування таблиць фіксації IP-адрес застосовуйте хеш-таблиці з витісненням LRU та обмеженою кількістю записів, щоб уникнути вичерпання RAM під час розподілених атак.
  • Розширюйте кільцевий буфер прийому: Збільшуйте розмір буфера мережевої карти (ethtool -G <інтерфейс> rx 4096), щоб система витримувала мікро-сплески без втрати пакетів до запуску XDP.
  • Синхронізуйте моніторинг у просторі користувача: Використовуйте оптимізовані службові процеси для періодичного зчитування лічильників із BPF Maps без втручання у високошвидкісну обробку на рівні драйвера.

Технології eBPF та XDP встановлюють нові стандарти стійкості мережевих платформ. Завдяки переносу аналізу пакетів безпосередньо до апаратного драйвера, VPN-системи витримують масовані навантаження, забезпечуючи високу швидкість обміну даними та надійну роботу каналів звʼязку.

Завантажити VPNRice.