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

Щоразу, коли стандартний віртуальний тунельний пристрій Linux (такий як TUN/TAP, IP-in-IP, GRE чи VXLAN) виконує інкапсуляцію або декапсуляцію трафіку, ядро виділяє 240-байтову структуру struct sk_buff, копіює чи розширює пам'ять через pskb_expand_head() та передає пакет через безліч рівнів черг і таблиць фільтрації. Навіть за умов агресивної апаратної оптимізації традиційна схема тунелювання перевантажує процесорне ядро вже за швидкості від 1,5 до 2,5 Mpps.

Поєднання технології eXpress Data Path (XDP) із системною функцією bpf_xdp_adjust_head() докорінно змінює цю парадигму. Працюючи безпосередньо всередині циклу опитування переривань драйвера мережевої карти (NAPI) до створення сокетного буфера, XDP дозволяє виконувати пакування та розпакування пакетів у режимі zero-copy на повній фізичній швидкості лінії, досягаючи понад 14 Mpps на одному процесорному ядрі.

Порівняння класичного тунелювання в ядрі та швидкої обробки XDP:

Класичний шлях тунелювання (Високе навантаження на процесор):
Фізичний кабель ──> DMA мережевої карти ──> Виділення sk_buff (240B) ──> Netfilter PREROUTING
                                                                                │
                                                                                ▼
[Демон тунелю / Віртуальний пристрій] ◄── pskb_expand_head() (Реалокація) ◄── Таблиця маршрутів
           │
           ▼ (Інкапсуляція зовнішніми заголовками IP + UDP)
Повернення в стек ядра ──> Netfilter POSTROUTING ──> Черга qdisc ──> Кільцевий буфер TX
Межа пропускної здатності: ~2,0 Mpps на одне ядро CPU

Швидкий шлях XDP zero-copy безпосередньо в драйвері:
Фізичний кабель ──> DMA мережевої карти ──> Цикл NAPI RX ──> Виконання програми XDP
                                                                    │
                                                                    ▼
                                                       bpf_xdp_adjust_head(ctx, -delta)
                                                       (Розширення пам'яті прямо в буфері DMA!)
                                                                    │
                                                                    ▼
                                                       Запис зовнішніх заголовків IP + UDP
                                                                    │
                                                                    ▼
                                                       Дія: XDP_TX / bpf_redirect_map()
                                                       (Миттєве відправлення без створення sk_buff!)
Реальна продуктивність: ~14,5 Mpps на одне ядро CPU (Апаратна швидкість лінії!)

Структурні обмеження класичних мережевих тунелів

Щоб зрозуміти причини настільки значного приросту продуктивності в XDP, необхідно проаналізувати роботу стандартної мережевої підсистеми Linux під час пакування пакетів:

  1. Накладні витрати на створення структури sk_buff: Під час отримання сирого кадру драйвер змушений ініціалізувати об'єкт struct sk_buff. Це вимагає обнулення пам'яті, атомарних операцій з лічильниками посилань та заповнення численних службових полів.
  2. Брак вільного простору перед заголовком (Headroom Starvation): Драйверам віртуальних тунелів потрібно додати зовнішні заголовки (Ethernet, IPv4/IPv6 та UDP). Якщо початковий буфер, наданий мережевою картою, не має достатнього запасу на початку, ядро викликає pskb_expand_head(). Це призводить до повного перевиділення пам'яті та фізичного копіювання даних кадру, руйнуючи локальність кешу процесора.
  3. Багаторазове проходження підсистем ядра: Пакет проходить ланцюжок прийому IP, систему відстеження з'єднань (nf_conntrack), інтерфейс віртуального тунелю, після чого повторно направляється в стек вже в упакованому вигляді та проходить усі вихідні ланцюжки фільтрації.

В умовах пікових мережевих навантажень до 70 % процесорного часу витрачається виключно на операції розподілу пам'яті, інвалідацію кешу та синхронізацію блокувань, а не на реальне пересилання користувацьких даних.

Внутрішній механізм bpf_xdp_adjust_head у драйвері

Технологія XDP виконується на найнижчому програмному рівні ядра. Пакет являє собою неперервний блок фізичної пам'яті, описаний структурою struct xdp_buff:

struct xdp_buff {
    void *data;             /* Вказівник на початок даних пакета */
    void *data_end;         /* Вказівник на кінець даних пакета */
    void *data_meta;        /* Область метаданих перед data */
    void *data_hard_start;  /* Фізичний початок виділеної сторінки пам'яті */
    struct xdp_rxq_info *rxq;
    struct xdp_mem_info mem;
    u32 flags;
};

Сучасні драйвери (такі як mlx5, i40e, ixgbe або virtio_net) заздалегідь резервують вільний простір (як правило, XDP_PACKET_HEADROOM = 256 байтів) між data_hard_start та data.

Зміна меж пакета за допомогою bpf_xdp_adjust_head

Ядро Linux надає допоміжну функцію BPF:

long bpf_xdp_adjust_head(struct xdp_md *xdp_md, int delta);

Параметр delta визначає напрямок зміщення межі:

  • Від'ємне значення (delta < 0) — Інкапсуляція: Віднімання байтів зміщує вказівник ctx->data назад у бік data_hard_start, розширюючи пакет у зарезервовану драйвером область пам'яті. У результаті формується вільний простір, куди програма eBPF може безпосередньо записати нові мережеві заголовки.
  • Додатне значення (delta > 0) — Декапсуляція: Додавання байтів зсуває ctx->data вперед, що миттєво відсікає зовнішні заголовки (Ethernet, IP та UDP) і передає внутрішнє корисне навантаження операційній системі.
Геометрія пам'яті xdp_buff під час додавання зовнішніх заголовків:

До виклику bpf_xdp_adjust_head (Вихідний прийнятий пакет):
[ data_hard_start ] ──[ Резерв пам'яті (256B) ]──> [ data ]───────[ data_end ]
                                                     │              │
                                                     └─ Внутрішній IP ┘

Після виклику bpf_xdp_adjust_head(ctx, -28):
[ data_hard_start ] ──[ Залишок резерву (228B) ]──> [ data ]─────────[ data_end ]
                                                      │               │
                                                      ├─ Зовнішній IP (20B)
                                                      ├─ Зовнішній UDP (8B)
                                                      └─ Корисне навантаження ┘

Вимоги безпеки верифікатора BPF: Інвалідація вказівників

Ключовим архітектурним правилом під час створення програм інкапсуляції XDP є дотримання вимог верифікатора безпеки ядра Linux (BPF Verifier).

Після успішного виконання bpf_xdp_adjust_head() фізична адреса в пам'яті для ctx->data повністю змінюється. Відповідно, верифікатор BPF миттєво анулює всі раніше отримані вказівники та результати перевірки меж пам'яті.

Спроба звернутися до пам'яті пакета за старими вказівниками призведе до помилки верифікатора R1 invalid mem access. Розробник зобов'язаний повторно зчитати адреси ctx->data та ctx->data_end і заново підтвердити коректність меж до початку запису даних:

// 1. Зміна розміру заголовка пакета
if (bpf_xdp_adjust_head(ctx, 0 - (int)encap_size)) {
    return XDP_DROP;
}

// 2. ОБОВ'ЯЗКОВЕ ПОВТОРНЕ ЗЧИТУВАННЯ ВКАЗІВНИКІВ
void *data = (void *)(long)ctx->data;
void *data_end = (void *)(long)ctx->data_end;

// 3. ПОВТОРНА ПЕРЕВІРКА МЕЖ ПЕРЕД ДОСТУПОМ ДО ПАМ'ЯТІ
if (data + sizeof(struct ethhdr) + sizeof(struct iphdr) > data_end) {
    return XDP_DROP;
}

Повна реалізація програми інкапсуляції UDP-тунелів

Нижче наведено робочий код програми мовою C для eBPF, яка реалізує пакування вхідних пакетів IPv4 без копіювання пам'яті:

#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/udp.h>
#include <linux/in.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_endian.h>

#define TUNNEL_PORT 51820
#define ENCAP_SIZE (sizeof(struct ethhdr) + sizeof(struct iphdr) + sizeof(struct udphdr))

static __always_inline __u16 csum_fold_helper(__u32 csum) {
    csum = (csum >> 16) + (csum & 0xffff);
    csum += (csum >> 16);
    return (__u16)~csum;
}

SEC("xdp")
int xdp_vpn_encapsulate(struct xdp_md *ctx) {
    void *data = (void *)(long)ctx->data;
    void *data_end = (void *)(long)ctx->data_end;

    // Перевірка цілісності початкового заголовка Ethernet
    struct ethhdr *orig_eth = data;
    if ((void *)(orig_eth + 1) > data_end) {
        return XDP_PASS;
    }

    // Обробка виключно трафіку IPv4
    if (orig_eth->h_proto != bpf_htons(ETH_P_IP)) {
        return XDP_PASS;
    }

    // Розширення вільного простору пакета
    if (bpf_xdp_adjust_head(ctx, 0 - (int)ENCAP_SIZE)) {
        return XDP_DROP;
    }

    // Повторне зчитування меж після коригування
    data = (void *)(long)ctx->data;
    data_end = (void *)(long)ctx->data_end;

    struct ethhdr *eth = data;
    struct iphdr *ip = (void *)(eth + 1);
    struct udphdr *udp = (void *)(ip + 1);

    if ((void *)(udp + 1) > data_end) {
        return XDP_DROP;
    }

    // Створення зовнішнього Ethernet-заголовка
    __builtin_memcpy(eth->h_dest, "\x52\x54\x00\x12\x34\x56", ETH_ALEN);
    __builtin_memcpy(eth->h_source, "\x52\x54\x00\xab\xcd\xef", ETH_ALEN);
    eth->h_proto = bpf_htons(ETH_P_IP);

    // Створення зовнішнього IPv4-заголовка
    ip->version = 4;
    ip->ihl = 5;
    ip->tos = 0;
    ip->tot_len = bpf_htons((__u16)(data_end - (void *)ip));
    ip->id = 0;
    ip->frag_off = bpf_htons(IP_DF);
    ip->ttl = 64;
    ip->protocol = IPPROTO_UDP;
    ip->saddr = bpf_htonl(0x0a000001); // 10.0.0.1
    ip->daddr = bpf_htonl(0x0a000002); // 10.0.0.2
    ip->check = 0;

    // Обчислення контрольної суми IPv4
    __u32 csum = 0;
    __u16 *ip_words = (__u16 *)ip;
    #pragma unroll
    for (int i = 0; i < sizeof(struct iphdr) / 2; i++) {
        csum += ip_words[i];
    }
    ip->check = csum_fold_helper(csum);

    // Створення зовнішнього UDP-заголовка
    udp->source = bpf_htons(45000);
    udp->dest = bpf_htons(TUNNEL_PORT);
    udp->len = bpf_htons((__u16)(data_end - (void *)udp));
    udp->check = 0;

    // Миттєве передавання упакованого пакета назад у мережевий кабель
    return XDP_TX;
}

char _license[] SEC("license") = "GPL";

Практичні результати апаратного тестування

Під час серії порівняльних тестів на мережевих адаптерах Intel E810 (25 Гбіт/с) з мінімальним розміром кадру (64 байти) інкапсуляція на рівні XDP продемонструвала такі показники:

Архітектурне рішення Швидкість пересилання (Mpps) Середня затримка ($\mu\text{s}$) Навантаження на 1 ядро CPU (%)
Пристрій TUN + Процес простору користувача 1,8 Mpps 14,2 $\mu\text{s}$ 100 % (Вузьке місце)
Стандартний модуль ядра (VXLAN/UDP) 3,2 Mpps 8,6 $\mu\text{s}$ 100 % (Вузьке місце)
Швидкий шлях eBPF XDP (bpf_xdp_adjust_head) 14,6 Mpps 0,8 $\mu\text{s}$ 42 % (Апаратна швидкість лінії)

Повна відмова від створення об'єктів struct sk_buff та безпосередня модифікація буферів DMA драйвера мережевої карти збільшують продуктивність у 4,5–8 разів за одночасного зниження затримки більш ніж на 90 %.

Інструкція зі збирання та підключення програми

Компіляція та впровадження програми виконуються за допомогою компілятора clang та стандартних утиліт iproute2:

# 1. Компіляція вихідного коду в байт-код BPF
clang -O2 -target bpf -c xdp_encap.c -o xdp_encap.o

# 2. Підключення програми до апаратного драйвера eth0
ip link set dev eth0 xdpgeneric off
ip link set dev eth0 xdp obj xdp_encap.o sec xdp

# 3. Перевірка статусу підключення на інтерфейсі
ip link show dev eth0 | grep -i "xdp"

# 4. Перегляд статистики роботи за допомогою bpftool
bpftool prog dump xlated name xdp_vpn_encapsulate

Для безпечного відключення програми:

ip link set dev eth0 xdp off

Застосування в технологічному стеку RiceGuard від VPNRice

Глобальна розподілена інфраструктура Anycast платформи VPNRice активно використовує технологію XDP для забезпечення найвищої відмовостійкості:

  1. Перевірка справжності на рівні драйвера: Під час надходження зашифрованих пакетів на вузли Anycast програми XDP перевіряють криптографічні маркери безпосередньо в кільцевому буфері, відсікаючи паразитний трафік і флуд до витрачання ресурсів операційної системи.
  2. Транзитна інкапсуляція між дата-центрами: Для обміну трафіком між центральними маршрутизаторами RiceGuard використовує bpf_xdp_adjust_head, упаковуючи дані в захищені тунелі на апаратній швидкості, запобігаючи роздуванню черг (bufferbloat) та блокуванню процесорних ядер.
  3. Адаптивна сумісність: Під час роботи в хмарних середовищах, де драйвер мережевої карти не підтримує нативний режим XDP, система автоматично перемикається в узагальнений режим (xdpgeneric), зберігаючи ідентичні правила маршрутизації.

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