Експлуатація високонавантажених корпоративних шлюзів віртуальних приватних мереж (VPN) вимагає обробки мільйонів зашифрованих пакетів щосекунди на багатоядерних серверах. В операційній системі Linux усі криптографічні операції протоколу IPsec (інкапсулююче корисне навантаження ESP) керуються підсистемою ядра XFRM (Transform Subsystem).

Історично класичний підхід до IPsec на основі політик (Policy-Based IPsec) створював складні інженерні перешкоди:

  1. Неявне зіставлення пакетів: Трафік перехоплювався після завершення маршрутизації за умови збігу з правилами політики безпеки (SP). Це викликало приховані конфлікти з правилами брандмауера Netfilter, таблицями відстеження з'єднань (conntrack) та маршрутизацією за джерелом.
  2. Відсутність мережевого інтерфейсу: Через брак окремого пристрою діагностичні засоби, такі як tcpdump, не могли напряму захоплювати відкритий трафік до шифрування або після дешифрування без налаштування допоміжних правил ядра.
  3. Накладні витрати тунельних протоколів: Використання інтерфейсів Virtual Tunnel Interface (VTI) або зв'язки GRE-over-IPsec призводило до зростання розміру службових заголовків, зменшувало корисний MTU та ускладнювало роботу динамічних маршрутизаторів (BGP чи OSPF).

Для розв'язання цих проблем сучасне ядро Linux інтегрувало інтерфейси XFRM на основі маршрутизації (Route-Based XFRM, xfrmi) у поєднанні з апаратним розвантаженням криптографії (Hardware Crypto Offload). Ця архітектура відокремлює криптографічні перетворення від рішень маршрутизації, надає прозорі точки підключення та передає навантаження шифрування апаратним процесорам мережевих адаптерів (NIC ASIC).

+--------------------------------------------------------------------------+
|          АРХІТЕКТУРА LINUX XFRM: ПОРІВНЯННЯ ПОЛІТИК ТА XFRMI             |
+--------------------------------------------------------------------------+
|                                                                          |
| 1. Класичний IPsec на основі політик (Policy-Based):                     |
|    Пакет -> Маршрутизація -> Netfilter -> Збіг із політикою SP           |
|           -> Пошук асоціації SA -> Програмне шифрування -> Вихід         |
|    (Відсутній інтерфейс, ускладнений захват, конфлікти маршрутів)        |
|                                                                          |
| 2. Маршрутизований інтерфейс XFRM (Route-Based xfrmi):                   |
|    Пакет -> Стандартний маршрут на xfrm0 (if_id 42) -> Окрема черга Qdisc|
|           -> Прозорий аналіз через tcpdump -> Пошук SA за if_id          |
|           -> Апаратне шифрування в ASIC карти -> Фізична швидкість       |
|                                                                          |
+--------------------------------------------------------------------------+

Структурні компоненти підсистеми XFRM: SA, SP та ідентифікатор if_id

Підсистема XFRM у ядрі Linux оперує трьома базовими базами даних, що зберігаються в пам'яті ядра:

1. База даних асоціацій безпеки (SAD / xfrm_state)

Асоціація безпеки (Security Association, SA) описує односпрямований криптографічний контекст між двома вузлами мережі. Запис SA містить:

  • Індекс параметрів безпеки (SPI): 32-бітний ідентифікатор захищеного потоку даних.
  • Алгоритми шифрування та ключі: Набори на зразок AES-GCM-256 або ChaCha20-Poly1305.
  • Розширені номери послідовностей (ESN): 64-бітні лічильники для захисту від атак повторного відтворення.
  • Контекст апаратного прискорення: Вказівник на структури розвантаження в драйвері адаптера.

2. База даних політик безпеки (SPD / xfrm_policy)

Політика безпеки (Security Policy, SP) регламентує, який саме трафік підлягає обов'язковому шифруванню. Правило SP визначає діапазони IP-адрес джерела та призначення, протоколи і напрямок обробки (dir in, dir out, dir fwd).

3. Значення ідентифікатора інтерфейсу (if_id)

Параметр if_id є числовим зв'язком між віртуальним інтерфейсом xfrmi та правилами криптографічної обробки:

  • Якщо пакет спрямовується в інтерфейс xfrm0 із позначкою if_id 42, ядро обирає лише ті політики та асоціації SA, які містять аналогічний ідентифікатор if_id 42.
  • Кілька віртуальних інтерфейсів можуть одночасно функціонувати на одному сервері без взаємних перешкод.
+--------------------------------------------------------------------------+
|          РУХ ПАКЕТА КРІЗЬ МАРШРУТИЗОВАНИЙ ІНТЕРФЕЙС XFRM                 |
+--------------------------------------------------------------------------+
|                                                                          |
|       Програма користувача / Сокетний потік даних                        |
|                           │                                              |
|                           v                                              |
|       Таблиця маршрутизації ядра Linux (FIB Routing Table)               |
|       [ Маршрут: 10.100.0.0/16 спрямовано крізь пристрій xfrm0 ]         |
|                           │                                              |
|                           v                                              |
|       Віртуальний інтерфейс 'xfrm0' (Позначка if_id 42)                  |
|       [ Незашифрований пакет видно утиліті tcpdump -i xfrm0 ]            |
|                           │                                              |
|                           v                                              |
|       Конвеєр перетворень XFRM (Фільтр if_id 42)                         |
|       - Перевірка політики: збіг SP за кодом if_id 42                    |
|       - Пошук асоціації: вибір SA за SPI та адресою призначення          |
|                           │                                              |
|             ┌─────────────┴─────────────┐                                |
|             ▼ (Програмне виконання)     ▼ (Апаратне розвантаження)       |
|       Kernel Crypto API           Вбудований процесор NIC ASIC           |
|       (Векторні команди AES-NI)   (Нульове навантаження на ядра CPU)     |
|             │                           │                                |
|             └─────────────┬─────────────┘                                |
|                           │                                              |
|                           v                                              |
|       Фізичний порт адаптера (eth0 / Оптоволокно 100GbE)                 |
|       [ Зашифрований пакет ESP: SPI 0x1001, Номер послідовності N ]      |
|                           │                                              |
|                           v                                              |
|       Передавання фізичним каналом на максимальній швидкості             |
|                                                                          |
+--------------------------------------------------------------------------+

Апаратне розвантаження: Технологія XFRM Crypto Offload

Виконання шифрування на швидкостях 100GbE за допомогою центрального процесора спричиняє значне споживання системних ресурсів. Навіть із підтримкою векторних інструкцій AES-NI постійне шифрування мультигігабітного потоку викликає перегрів процесора та затримки в обробці черг.

Сучасні серверні мережеві адаптери (зокрема Mellanox ConnectX-6/ConnectX-7, Intel E810 та Broadcom NetXtreme) мають вбудовані апаратні модулі обробки IPsec.

Підсистема Linux XFRM підтримує два режими апаратної оптимізації:

  • Повне розвантаження пакета (Full Offload): Генерація заголовків ESP, оновлення номерів послідовностей, аналіз вікна повторів та криптографічні операції виконуються безпосередньо чипом мережевої карти.
  • Розвантаження криптографії (Crypto Offload): Ядро формує заголовки пакета, а трудомісткі обчислення симетричного шифрування здійснює адаптер під час передачі через DMA.
+--------------------------------------------------------------------------+
|          ПОРІВНЯННЯ ПОКАЗНИКІВ: ПРОЦЕСОР ПРОТИ АПАРАТНОГО ОФЛОАДУ        |
+--------------------------------------------------------------------------+
| Параметр оцінки         | Програмне шифрування    | Апаратний офлоад     |
+-------------------------+-------------------------+----------------------+
| Завантаження ядер 100G  | 8 - 16 Окремих ядер     | < 0.5 Ядра (Драйвер) |
| Затримка шифрування     | 15 - 35 Мікросекунд     | 1.2 - 2.5 Мікросекунд|
| Втрати пакетів під час  | Зростають від 8-12 Mpps | Повна відсутність    |
| пікового навантаження   |                         | втрат на швидкості   |
| Навантаження на шину    | Часті скидання DMA ків  | Пряме опрацювання NIC|
| Тепловиділення платформи| Висока температура CPU  | Карта працює помірно |
+-------------------------+-------------------------+----------------------+

Налаштування конфігурації у середовищі Linux

Розгортання інтерфейсів XFRM із підтримкою апаратного розвантаження здійснюється за допомогою стандартного пакета iproute2 (ip link та ip xfrm).

Крок 1: Створення віртуального інтерфейсу XFRM

Створіть новий пристрій XFRM на базі фізичного порту з прив'язкою до ідентифікатора if_id:

# Створення xfrm0 на адаптері eth0 з прив'язкою до if_id 42
ip link add name xfrm0 type xfrm dev eth0 if_id 42

# Призначення транзитної IP-адреси
ip addr add 10.254.1.1/30 dev xfrm0

# Активація інтерфейсу
ip link set dev xfrm0 up

Крок 2: Додавання асоціацій безпеки (SA) з апаратним розвантаженням

Внесіть вихідну та вхідну асоціації безпеки до пам'яті ядра із зазначенням прив'язки до if_id 42 та апаратного пристрою:

# Вихідна асоціація SA (Локальний -> Віддалений) з апаратним офлоадом
ip xfrm state add \
    src 198.51.100.1 dst 198.51.100.2 \
    proto esp spi 0x1001 \
    reqid 1 \
    mode tunnel \
    if_id 42 \
    aead 'rfc4106(gcm(aes))' 0x0123456789abcdef0123456789abcdef01234567 128 \
    offload dev eth0 dir out \
    sel src 0.0.0.0/0 dst 0.0.0.0/0

# Вхідна асоціація SA (Віддалений -> Локальний) з апаратним офлоадом
ip xfrm state add \
    src 198.51.100.2 dst 198.51.100.1 \
    proto esp spi 0x2001 \
    reqid 1 \
    mode tunnel \
    if_id 42 \
    aead 'rfc4106(gcm(aes))' 0x0123456789abcdef0123456789abcdef01234567 128 \
    offload dev eth0 dir in \
    sel src 0.0.0.0/0 dst 0.0.0.0/0

Крок 3: Налаштування зв'язаних політик безпеки (SP)

Створіть правила політики безпеки для обробки потоків інтерфейсу xfrm0:

# Вихідна політика для трафіку через xfrm0
ip xfrm policy add \
    src 0.0.0.0/0 dst 0.0.0.0/0 \
    dir out \
    if_id 42 \
    tmpl src 198.51.100.1 dst 198.51.100.2 proto esp reqid 1 mode tunnel

# Вхідна політика для приймання пакетів від шлюзу
ip xfrm policy add \
    src 0.0.0.0/0 dst 0.0.0.0/0 \
    dir in \
    if_id 42 \
    tmpl src 198.51.100.2 dst 198.51.100.1 proto esp reqid 1 mode tunnel

Крок 4: Маршрутизація трафіку крізь інтерфейс XFRM

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

# Маршрутизація цільової підмережі крізь xfrm0
ip route add 10.100.0.0/16 dev xfrm0

# Перевірка статистики трафіку та стану офлоаду
ip -s link show dev xfrm0
ip -s xfrm state show

Синергія з інфраструктурою RiceGuard та VPNRice

У глобальній мережі VPNRice інтерфейси XFRM та апаратний офлоад відіграють важливу роль:

  1. Магістральні канали між ЦОД: Трансконтинентальні лінії сполучають периферійні шлюзи з центральними кластерами. Апаратний офлоад алгоритму AES-GCM на картах SmartNIC 100GbE забезпечує передавання даних на швидкості кабелю без навантаження на процесори серверів.
  2. Спільна робота з динамічною маршрутизацією: Інтерфейси XFRM працюють як звичайні мережеві пристрої. Процеси BGP встановлюють сесії безпосередньо через xfrm0, забезпечуючи миттєву перемаршрутизацію у разі пошкодження магістральних каналів.
  3. Ізоляція трафіку клієнтських груп: Використання індивідуальних міток if_id розмежовує потоки даних різних користувачів по віртуальних інтерфейсах, полегшуючи застосування правил мережевого екрана.

Інженерні рекомендації для виробничих середовищ

Під час запуску архітектури XFRM на серверах важливо враховувати такі умови:

  • Підтримка в драйвері адаптера: Перевірте наявність підтримки розвантаження IPsec у драйвері мережевої карти (ethtool -k eth0 | grep esp). Цей механізм реалізовано в драйверах mlx5_core та ice.
  • Коригування MTU та MSS: Ураховуйте збільшення розміру пакетів через заголовки ESP (50–70 байтів). Налаштуйте MTU інтерфейсу xfrm0 на рівні 1430 байтів для стандартних мереж або задійте обмеження MSS (TCPMSS --clamp-mss-to-pmtu).
  • Синхронізація ESN проти повторів: На високих швидкостях 40GbE та 100GbE 32-бітний лічильник послідовності вичерпується за кілька хвилин. Завжди налаштовуйте розширені 64-бітні номери (ESN) та вікно перевірки розміром щонайменше 1024 пакети (replay-window 1024 flag esn).

Застосування маршрутизованих інтерфейсів XFRM та апаратного розвантаження перетворює звичайні сервери Linux на високоефективні шлюзи безпеки, створюючи надійну платформу для швидкісних сучасних систем VPN.