Linux IPVLAN та MACVLAN: Високопродуктивна ізоляція для VPN-шлюзів

Контейнеризація мікросервісів та віртуалізація з підтримкою багатьох клієнтів (multi-tenant) стали сучасним фундаментом побудови корпоративної межової інфраструктури. Під час розгортання масштабних сервісів VPN, де кожна клієнтська група чи розподілена мережа агентів вимагає строго відокремлених таблиць маршрутизації, ізоляція трафіку традиційно здійснюється через мережеві простори імен Linux (netns).

Проте обраний спосіб підключення цих відокремлених просторів до фізичних мережевих карт (NIC) безпосередньо впливає на пропускну здатність вузла. Звичайні середовища контейнеризації з'єднують простори імен парами віртуальних адаптерів Ethernet (veth), підключеними до програмного моста (br0). Під час передавання багатогігабітного потоку така структура призводить до надмірних витрат процесора, подвійного проходження мережевого стека та стрибків затримки на рівні 99-го процентиля (p99).

Для усунення цих накладних витрат ядро Linux містить дві потужні технології: MACVLAN та IPVLAN. Розуміння відмінностей цих драйверів дає змогу мережевим інженерам створювати контейнерні VPN-шлюзи з максимальною швидкістю пересилання без компромісів щодо криптографічної ізоляції.

Container Networking Bottlenecks: Ціна віртуального Ethernet (VETH)

У типовій конфігурації Docker чи Kubernetes пакет долає складний шлях між фізичним мережевим інтерфейсом і службою VPN усередині контейнера:

Вихід із Простору Імен: Пакет виходить із контейнера крізь одне закінчення пари veth (інтерфейс eth0 усередині простору).
Перемикання Контексту: Ядро перехоплює пакет і перемикає контекст обробки на хостовий простір, де розташоване парне закінчення (vethXXXX).
Обробка у Програмному Мосту: Хостовий інтерфейс передає пакет програмному мосту (br0). Міст аналізує адреси призначення, оновлює базу комутації (FDB) та стежить за протоколом STP.
Виведення на Фізичну Карту: Міст спрямовує кадр до фізичного порту (eth0), що вимагає додаткового циклу крізь модуль керування трафіком (tc) та буфери драйвера.

Класична схема VETH та програмного моста (Подвійний прохід мережевого стека):

[ Простір імен Контейнера ]
             │
   (eth0: закінчення veth)
             │
[ Простір імен Хоста ]
             ▼
   (vethXXXX парне закінчення)
             │
             ▼
[ Програмний міст: br0 ] ──► (Пошук у базі FDB, вивчення MAC, блокування)
             │
             ▼
[ Фізична мережева карта: eth0 ] ──► Фізичний кабель

Такий багатоланковий ланцюг створює відчутне падіння продуктивності:

Подвійне Проходження Стека: Кожен пакет двічі викликає функції netif_rx() та dev_queue_xmit(), подвоюючи кількість команд CPU на кожен мережевий кадр.
Блокування у Програмному Мості: Програмний міст Linux застосовує спінлоки для захисту таблиць MAC-адрес. За високої інтенсивності передавання пакетів ці блокування обмежують масштабування.
Втрата Локальності Кешу: Постійне перенесення буферів сокетів (sk_buff) між віртуальними інтерфейсами погіршує стан кешу L1/L2, спричиняючи зайве навантаження на оперативну пам'ять.

MACVLAN Architecture: Окремі MAC-адреси та відмова від моста

Запроваджена в Linux 2.6.23 технологія MACVLAN повністю прибирає програмний міст із ланцюга передавання. Замість створення пар віртуальних з'єднань MACVLAN створює субінтерфейси безпосередньо поверх базового фізичного пристрою (як-от eth0).

Кожен субінтерфейс MACVLAN отримує окрему фізичну MAC-адресу. Під час перенесення в мережевий простір імен він діє як повноцінна автономна мережева плата.

1. Режими комутації MACVLAN (Bridge, VEPA, Private, Passthru)

MACVLAN підтримує чотири режими взаємодії під час створення пристрою:

Private: Субінтерфейс повністю відокремлений від інших інтерфейсів MACVLAN на тому ж фізичному адаптері. Усі пакети спрямовуються лише у зовнішній мережевий канал. Оптимально для суворої ізоляції незалежних клієнтів.
VEPA (Virtual Ethernet Port Aggregator): Субінтерфейси обмінюються трафіком тільки тоді, коли вищий фізичний комутатор підтримує рефлексивний режим ("hairpin"), повертаючи кадри в той самий порт.
Bridge: Субінтерфейси передають дані безпосередньо через вбудований у ядро легковий L2-комутатор. Це виключає вихід у фізичну мережу та працює значно продуктивніше за традиційний міст Linux.
Passthru: Надає фізичний інтерфейс у монопольне розпорядження єдиного дочірнього адаптера. Застосовується для спеціалізованих високошвидкісних служб.

2. Проблема переповнення MAC-адрес: Обмеження комутаторів та Wi-Fi

Незважаючи на високу швидкість, технологія MACVLAN має два суттєві експлуатаційні обмеження:

Вичерпання Таблиць Фізичних Комутаторів: Оскільки кожен віртуальний адаптер MACVLAN має власну MAC-адресу, запуск сотень VPN-контейнерів швидко переповнює таблицю CAM мережевого обладнання. Комутатори з активованою безпекою портів (Port Security) часто блокують порт у разі виявлення багатьох адрес.
Несумісність із Мережами Wi-Fi: Стандарт бездротового зв'язку IEEE 802.11 забороняє використання кількох MAC-адрес для одного клієнтського з'єднання. Тому MACVLAN не здатний працювати на ноутбуках чи бездротових межових маршрутизаторах.

IPVLAN Mechanics: Спільна MAC-адреса та багаторівнева маршрутизація

Для розв'язання проблем, властивих MACVLAN, у ядрі Linux (починаючи з версії 3.19) було створено драйвер IPVLAN. Замість призначення унікальних MAC-адрес кожному інтерфейсу IPVLAN використовує спільну апаратну MAC-адресу фізичного батьківського адаптера для всіх дочірніх підключень.

Розподіл вхідного трафіку між контейнерами здійснюється не за MAC-адресою, а шляхом аналізу IP-адреси призначення на Мережевому рівні (Layer 3).

Архітектура IPVLAN (Єдина MAC-адреса, комутація за IP):

[ Простір VPN A ]            [ Простір VPN B ]
 (ipv0: 10.0.1.2)             (ipv1: 10.0.1.3)
        │                            │
        └─────────────┬──────────────┘
                      │
           [ Драйвер ядра IPVLAN ]
 (Спільний MAC: 52:54:00:12:34:56, Розподіл за цільовим IP)
                      │
                      ▼
      [ Фізична карта: eth0 ] ──► Фізичний кабель

1. Відмінності між режимами IPVLAN L2 та IPVLAN L3

Технологія IPVLAN діє у двох фундаментальних режимах:

IPVLAN Режим L2: Працює аналогічно до L2-комутатора. Дочірні інтерфейси перебувають у тій самій IP-підмережі, що й батьківський адаптер. Широкомовні пакети (ARP, NDP) надходять у контейнери. Зовнішній комутатор бачить лише одну фізичну MAC-адресу, гарантуючи повну сумісність із корпоративними політиками.
IPVLAN Режим L3: Перетворює фізичний адаптер на внутрішній L3-маршрутизатор. Батьківський інтерфейс приймає рішення щодо маршрутизації без ретрансляції широкомовних кадрів L2 чи запитів ARP. Контейнери розташовуються в окремих підмережах. Завдяки усуненню широкомовного навантаження режим L3 забезпечує максимальну продуктивність для високощільних VPN-шлюзів.

2. Міжмережеві екрани та моніторинг сесій у режимі L3S

У початкових версіях IPVLAN L3 пакети контейнерів проходили повз підсистему відстеження з'єднань хоста (conntrack), що ускладнювало централізовану фільтрацію.

У Linux 4.15 реалізовано режим IPVLAN L3S (Symmetric). У ньому вхідний і вихідний трафік проходить перевірку netfilter основного простору хоста до потрапляння в контейнер. Це дає змогу використовувати правила фільтрації (iptables / nftables) і трансляцію NAT без побудови віртуальних мостів.

Порівняння продуктивності та надійності: VETH проти MACVLAN та IPVLAN

У таблиці зіставлено ключові технічні параметри трьох підходів до віртуалізації мережі:

Параметр порівняння	Virtual Ethernet (VETH + Міст)	MACVLAN (Режим Bridge)	IPVLAN (Режим L3 / L3S)
Використання MAC-адрес	Окремий MAC на кожен контейнер	Окремий MAC на кожен контейнер	Єдиний спільний MAC батьківської карти
Сумісність із Port Security	Схильність до блокування	Високий ризик відключення	100% Повна сумісність
Робота через Wi-Fi (802.11)	Працює (через NAT хоста)	Не підтримується	Повна підтримка
Проходження мережевого стека	2 повні цикли обробки	1 прямий цикл у драйвері	1 прямий цикл у драйвері
Ізоляція широкомовлення L2	Слабка (перевантажує міст)	Слабка (у режимі bridge)	Повна (широкомовлення фільтрується)
Пропускна здатність (40GbE)	~18.4 Mpps (обмеження CPU)	~29.1 Mpps (повна смуга)	~29.4 Mpps (повна смуга)
Затримка 99-го процентиля	3.4 мс під навантаженням	0.42 мс під навантаженням	0.38 мс під навантаженням
Підтримка Netfilter / Conntrack	Повна на мосту та veth	Локальна для хоста/контейнера	Повна в режимі L3S

Практичне налаштування: Впровадження IPVLAN для просторів імен VPN

Створення швидкого мережевого простору імен VPN за допомогою IPVLAN у режимі L3 виконується за кілька кроків утилітами iproute2:

# 1. Створення ізольованого простору імен для шлюзу клієнта
sudo ip netns add vpn-tenant-alpha

# 2. Додавання субінтерфейсу IPVLAN до адаптера eth0 у режимі L3
sudo ip link add link eth0 name ipv0 type ipvlan mode l3

# 3. Переміщення створеного інтерфейсу до цільового простору імен
sudo ip link set dev ipv0 netns vpn-tenant-alpha

# 4. Налаштування статичної IP-адреси всередині простору
sudo ip -n vpn-tenant-alpha addr add 10.200.1.2/24 dev ipv0
sudo ip -n vpn-tenant-alpha link set dev ipv0 up
sudo ip -n vpn-tenant-alpha link set dev lo up

# 5. Призначення типового маршруту всередині простору
sudo ip -n vpn-tenant-alpha route add default dev ipv0

# 6. Перевірка прямого інтерфейсу без віртуального моста
sudo ip netns exec vpn-tenant-alpha ip addr show dev ipv0

Для активації централізованої симетричної фільтрації на хості достатньо вказати mode l3s під час створення адаптера:

sudo ip link add link eth0 name ipv0 type ipvlan mode l3s

Архітектура RiceGuard: Високощільна ізоляція клієнтських середовищ

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

RiceGuard застосовує IPVLAN у режимі L3/L3S для досягнення максимальної щільності віртуалізації:

/* Ініціалізація інтерфейсу IPVLAN клієнтського середовища в RiceGuard */
int provision_tenant_ipvlan_interface(const char *parent_dev, const char *child_dev, 
                                      int netns_fd, int l3s_mode) {
    /* Вибір режиму: IPVLAN_MODE_L3 або IPVLAN_MODE_L3S */
    uint16_t mode = l3s_mode ? IPVLAN_MODE_L3S : IPVLAN_MODE_L3;
    
    /* Відправлення запиту Netlink RTM_NEWLINK для швидкого створення інтерфейсу */
    if (netlink_create_ipvlan(parent_dev, child_dev, mode) < 0) {
        perror("netlink_create_ipvlan");
        return -1;
    }

    /* Переміщення дочірнього адаптера до клієнтського простору імен */
    return netlink_move_device_to_netns(child_dev, netns_fd);
}

Використовуючи IPVLAN L3, кожен клієнтський контейнер RiceGuard працює у відокремленому просторі ядра із власними таблицями маршрутизації. Мережевий трафік прямує безпосередньо від фізичного адаптера до сокетів WireGuard без участі програмних мостів, без зайвих MAC-адрес і зі стабільною затримкою менше 1 мілісекунди.