Linux SR-IOV та Macvtap: апаратна віртуалізація I/O для VPN-шлюзів

Вузькі місця програмної комутації у високощільних шлюзах

Експлуатація серверів multi-tenant VPN-шлюзів із високою щільністю навантаження вимагає вирішення складного завдання: забезпечення повної ізоляції незалежних клієнтських середовищ при збереженні максимальної швидкості передачі на спільному фізичному обладнанні. Традиційно при розгортанні контейнерів або віртуальних машин інтерфейси підключають до програмних мостів Linux (br0) чи Open vSwitch (OVS).

При невеликих обсягах трафіку програмна комутація працює стабільно. Проте коли сумарний трафік наближається до 10 Гбіт/с, 25 Гбіт/с чи 100 Гбіт/с, програмні методи перемикання пакетів спричиняють значні апаратні обмеження:

Багаторазове копіювання пам'яті та вимивання кешу процесора: Кожен вхідний Ethernet-кадр копіюється в буфер сокета (sk_buff) ядра, обробляється логікою програмного моста, повторно копіюється в кільцевий буфер virtio-net/tap і лише потім передається гостьовій системі. Подвійне копіювання перевантажує шину оперативної пам'яті та скидає кеш L2/L3 процесора.
Накладні витрати контекстних перемикань і SoftIRQ: Віртуальні пристрої tap задіюють системні потоки vhost-net та обробники переривань ksoftirqd. За умов передачі мільйонів пакетів на секунду (Mpps) кількість міжпроцесорних переривань стрімко зростає, відбираючи обчислювальні ресурси у криптографічних процесів.
Конкуренція за черги між незалежними клієнтами: Коли один клієнт генерує різкий сплеск зашифрованого трафіку, блокування програмного світча сповільнюють пакети інших користувачів, породжуючи коливання затримки (джиттер) і затримки в чергах.

Для сучасних криптографічних протоколів, таких як WireGuard та RiceGuard, нераціонально витрачати від 30% до 50% ресурсів процесора лише на пересилання пакетів у пам'яті. Оптимальним підходом є делегування завдань мережевої віртуалізації безпосередньо в апаратну частину мережевої плати завдяки технологіям SR-IOV та драйверу Macvtap.

Архітектура SR-IOV: Фізичні (PF) та віртуальні (VF) функції

Стандартизована консорціумом PCI-SIG технологія SR-IOV (Single Root I/O Virtualization) дає змогу одній фізичній мережевій платі PCIe відображатися для операційної системи Linux як безліч незалежних пристроїв PCIe. Апаратні ресурси поділяються на два рівні:

+-------------------------------------------------------------------------+
|                  Фізичний мережевий адаптер PCIe (NIC)                  |
|                                                                         |
|  +-------------------------------------------------------------------+  |
|  |           Physical Function (PF): Повне керування картою          |  |
|  |           - Налаштування портів, оновлення мікрокоду, MAC/VLAN    |  |
|  +-------------------------------------------------------------------+  |
|         |                     |                     |                   |
|         v                     v                     v                   |
|  +--------------+      +--------------+      +--------------+           |
|  |  VF 0 (PCIe) |      |  VF 1 (PCIe) |      |  VF 2 (PCIe) |           |
|  |  - Кільце RX |      |  - Кільце RX |      |  - Кільце RX |           |
|  |  - MSI-X IRQ |      |  - MSI-X IRQ |      |  - MSI-X IRQ |           |
|  |  - Канал DMA |      |  - Канал DMA |      |  - Канал DMA |           |
|  +--------------+      +--------------+      +--------------+           |
+---------|---------------------|---------------------|-------------------+
          | DMA                 | DMA                 | DMA
          v                     v                     v
+------------------+   +------------------+   +------------------+
|  Клієнт Альфа    |   |  Клієнт Бета     |   |  Клієнт Гамма    |
|  Мережевий NetNS |   |  Мережевий NetNS |   |  Мережевий NetNS |
|  Вузол RiceGuard |   |  Вузол RiceGuard |   |  Вузол RiceGuard |
+------------------+   +------------------+   +------------------+

Physical Function (PF)

PF є головним інтерфейсом PCIe мережевої карти. Вона має повний доступ до налаштувань апаратного порту, узгодження швидкості каналу та оновлення прошивки контролера. Хостова система завантажує стандартні драйвери корпоративного класу (наприклад, Intel ice/ixgbe або Mellanox mlx5_core) для контролю PF.

Virtual Function (VF)

Віртуальна функція — це полегшений апаратний інтерфейс PCIe, створений кремнієвим контролером плати. Кожна VF володіє власним незалежним комплектом ресурсів:

Виділені канали прямого доступу до пам'яті (DMA)
Апаратні кільцеві буфери приймання та надсилання (RX/TX ring buffers)
Окремі вектори апаратних переривань MSI-X
Вбудовані механізми фільтрації MAC-адрес та обробки міток VLAN

Віртуальні функції позбавлені складних просторів конфігурації для економії кремнієвої площі. У Linux керування VF здійснюється через підсистему sysfs:

# Увімкнення 4 апаратних віртуальних функцій на інтерфейсі enp4s0f0
echo 4 > /sys/class/net/enp4s0f0/device/sriov_numvfs

# Перевірка виявлених пристроїв PCIe у системі
lspci -d 8086: | grep "Virtual Function"

Після ініціалізації адміністратор фіксує безпекові параметри для запобігання підміні мережевих адрес:

# Прив'язка MAC-адреси та активація захисту від спуфінгу на рівні плати
ip link set dev enp4s0f0 vf 0 mac 52:54:00:12:34:01 spoofchk on trust off

# Встановлення гарантованої мінімальної та максимальної пропускної здатності
ip link set dev enp4s0f0 vf 0 min_tx_rate 1000 max_tx_rate 5000

У разі ввімкненого параметра spoofchk on мережевий контролер автоматично відхиляє будь-які кадри з адресою відправника, що відрізняється від призначеної, унеможливлюючи втручання між ізольованими сегментами на фізичному рівні.

Пряме передавання даних без копіювання за допомогою Macvtap

Для контейнеризованих середовищ або ізольованих мережевих просторів імен Linux (netns) повний прокид пристрою через VFIO може бути надлишковим. Драйвер Macvtap пропонує збалансовану альтернативу, усуваючи зайві програмні прошарки.

Macvtap поєднує можливості ізоляції кінцевих точок macvlan із символьним інтерфейсом (/dev/tapX). Замість пересилання даних через програмний комутатор Macvtap напряму приєднується до віртуальної функції.

+-------------------------------------------------------------------+
|                     Мережевий простір клієнта                     |
|                 VPN-демон / Процес маршрутизації                  |
|                                 ^                                 |
|                                 | Читання / Запис                 |
|                                 v                                 |
|                         Файл /dev/tapX                            |
+---------------------------------|---------------------------------+
                                  | Прямий сокетний інтерфейс
+---------------------------------v---------------------------------+
|                       Драйвер ядра Macvtap                        |
|   - Оминає програмний міст br0 та правила netfilter bridge        |
|   - Швидка класифікація кадрів за MAC-таблицею контролера         |
+---------------------------------|---------------------------------+
                                  | Апаратна черга PCIe
+---------------------------------v---------------------------------+
|               SR-IOV Virtual Function (Апаратна VF)               |
+-------------------------------------------------------------------+

Режими функціонування Macvtap

Macvtap підтримує кілька режимів взаємодії, які налаштовуються командою ip link:

Режим VEPA (Virtual Ethernet Port Aggregator): У режимі mode vepa гостьові інтерфейси, закріплені за спільним фізичним портом, не можуть напряму обмінюватися трафіком. Кожен кадр надсилається на зовнішній апаратний комутатор, який застосовує правила безпеки та повертає дозволений трафік. Це рекомендований варіант для надійної ізоляції у multi-tenant VPN.
Режим Bridge: У mode bridge точки Macvtap перемикають пакети безпосередньо у внутрішній пам'яті ядра без залучення зовнішнього комутатора, пришвидшуючи локальний обмін ціною спільного простору збоїв.
Режим Passthru: У mode passthru інтерфейс виділяється виключно одному гостьовому середовищу, надаючи повний контроль над апаратними функціями.

Створення та призначення інтерфейсу Macvtap у цільовий мережевий простір виконується так:

# Створення каналу Macvtap у режимі VEPA на основі інтерфейсу VF
ip link add link enp4s0f0v0 name mvtap0 type macvtap mode vepa

# Переміщення інтерфейсу Macvtap до мережевого простору клієнта
ip link set dev mvtap0 netns tenant-alpha

# Активація з'єднання та призначення IP всередині простору
ip netns exec tenant-alpha ip link set dev mvtap0 up
ip netns exec tenant-alpha ip addr add 198.51.100.2/24 dev mvtap0

Оскільки Macvtap створює символьний файл /dev/tapX, клієнтські мережеві демони можуть застосовувати mmap(), усуваючи повторне копіювання даних між простором ядра та пам'яттю програми.

Апаратне прискорення в інфраструктурі RiceGuard

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

+-------------------------------------------------------------------+
|                    Виділений сервер VPNRice                       |
|                                                                   |
|   +-----------------------------------------------------------+   |
|   |         Мережева карта 100 GbE (Intel / Mellanox)         |   |
|   +-----------------------------------------------------------+   |
|         |                      |                      |           |
|         v                      v                      v           |
|   [VF 0: 25 Гбіт/с]      [VF 1: 25 Гбіт/с]      [VF 2: 50 Гбіт/с] |
|         |                      |                      |           |
|         v                      v                      v           |
|     Macvtap 0              Macvtap 1              Macvtap 2       |
|         |                      |                      |           |
|         v                      v                      v           |
|  +-------------+        +-------------+        +-------------+    |
|  | RiceGuard   |        | RiceGuard   |        | RiceGuard   |    |
|  | Клієнт A    |        | Клієнт B    |        | Клієнт C    |    |
|  | Окреме ядро |        | Окреме ядро |        | Окреме ядро |    |
|  | шифрування  |        | шифрування  |        | шифрування  |    |
|  +-------------+        +-------------+        +-------------+    |
+-------------------------------------------------------------------+

1. Усунення перехресних завад між клієнтами

Традиційні схеми на основі conntrack зазнають деградації за великої кількості сесій. Завдяки комбінації SR-IOV та Macvtap VEPA розмежування трафіку здійснюється безпосередньо апаратними регістрами мережевої плати. Перевантаження в одного клієнта не впливає на черги DMA чи стабільність інших вузлів.

2. Лінійна швидкість із підтримкою апаратного розвантаження

Під час з'єднання RiceGuard із віртуальними функціями зберігається апаратне обчислення контрольних сум (TCP/UDP Checksum Offload) та агрегація пакетів (LRO/LSO). Контролер мережевої карти скеровує зашифровані пакети за допомогою механізму Receive Side Scaling (RSS) прямо до переривань призначеної VF, вивільняючи процесорні потужності для операцій ChaCha20-Poly1305.

3. Комплексний захист від витоку даних

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