Складнощі вибору інтерфейсів у мультихоум-середовищах VPN

Сучасні системи на базі ядра Linux часто функціонують у багатоінтерфейсних конфігураціях (multi-homed), де одночасно активні фізичні мережеві адаптери (eth0, wlan0), мобільні модеми (wwan0) та віртуальні тунельні пристрої (wg0, tun0). У стандартному режимі вибір вихідного інтерфейсу (egress) визначається базою маршрутизації FIB (Forwarding Information Base) і правилами селективної маршрутизації (ip rule). Під час виклику функцій connect() або sendto() підсистема маршрутизації зіставляє параметри пакета з маршрутами на основі IP-адреси отримувача, IP-адреси відправника, міток пакета (fwmark) та метрик.

Проте пряма залежність від глобальних таблиць маршрутизації створює вразливості у робочих конфігураціях VPN. Якщо тунельний зв'язок тимчасово розривається, клієнт DHCP перепризначає шлюз за замовчуванням або мережевий менеджер скидає маршрути під час перемикання каналів, незашифровані дані додатків можуть піти через фізичний порт у відкритому вигляді. Такий витік маршрутизації (routing leak) розкриває трафік користувача та DNS-запити провайдерам зв'язку.

Окрім цього, фонові демони VPN стикаються з проблемою рекурсивних петель маршрутизації: службі необхідно передавати інкапсульовані пакети UDP через зовнішній фізичний інтерфейс, тоді як звичайні програми на комп'ютері мають надсилати дані виключно у віртуальний тунель. Якщо правила маршрутизації дають збій, зашифровані пакети повертаються назад у віртуальний адаптер, переповнюючи буфери та спричиняючи розрив сесії.

Ядро Linux усуває ці ризики на рівні сокетів завдяки параметрам SO_BINDTODEVICE та SO_BINDTOIFINDEX. Прив'язка мережевого сокета безпосередньо до індексу пристрою закріплює вихідний маршрут на рівні сокета, забезпечуючи вищий пріоритет над загальними таблицями ядра.

+-------------------------------------------------------------------------+
|                          Програма користувача                           |
+-------------------------------------------------------------------------+
                                     |
               setsockopt(..., SOL_SOCKET, SO_BINDTODEVICE, "wg0", ...)
                                     |
+------------------------------------+------------------------------------+
| Рівень сокетів ядра Linux (net/core/sock.c)                             |
| -> Призначає sk->sk_bound_dev_if = ifindex("wg0")                       |
+-------------------------------------------------------------------------+
                                     |
         +---------------------------+---------------------------+
         |                                                       |
         v                                                       v
+-----------------------------+             +-----------------------------+
|    Пошук маршруту у FIB     |             |         Збій каналу         |
| (FIB обмежує пошук виключно |             | (Інтерфейс wg0 вимкнено)    |
|  пристроєм wg0)             |             |                             |
+-----------------------------+             +-----------------------------+
         |                                                       |
         v                                                       v
Безпечна передача через тунель wg0          Ядро повертає помилку ENETUNREACH
(Витік відкритих даних неможливий)          (Передача через eth0 заблокована)

Механізми ядра: SO_BINDTODEVICE та SO_BINDTOIFINDEX

У вихідному коді ядра net/core/sock.c дані прив'язки інтерфейсу зберігаються безпосередньо в базовій структурі сокета:

struct sock {
    ...
    int sk_bound_dev_if; /* Індекс прив'язаного пристрою, якщо > 0 */
    ...
};

Коли програма викликає setsockopt з параметром SO_BINDTODEVICE, вона передає рядок з іменем мережевого інтерфейсу (наприклад, "wg0" або "eth0"). Системна функція sock_setbindtodevice() виконує такі кроки:

  1. Захоплює блокування сокета (lock_sock).
  2. Якщо передано порожній рядок, скидає sk->sk_bound_dev_if = 0, відв'язуючи сокет.
  3. Якщо вказано ім'я інтерфейсу, викликає dev_get_by_name(net, devname) для пошуку пристрою в мережевому просторі імен (net).
  4. У разі успішного пошуку числовий 32-бітний індекс пристрою (dev->ifindex) записується в sk->sk_bound_dev_if.
  5. Коректно контролює лічильники посилань на мережевий пристрій.

Починаючи з версії Linux 5.0, ядро отримало виклик SO_BINDTOIFINDEX. Замість текстового рядка, який потребує копіювання пам'яті та пошуку за іменем через dev_get_by_name(), програма одразу передає цілочисельний індекс ifindex:

int ifindex = if_nametoindex("wg0");
if (ifindex > 0) {
    setsockopt(sockfd, SOL_SOCKET, SO_BINDTOIFINDEX, &ifindex, sizeof(ifindex));
}

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

Обмеження пошуку в таблицях FIB та контроль вихідного порту

Під час надсилання пакета зі зв'язаного сокета мережевий стек готує структуру потоку (struct flowi4 для IPv4 або struct flowi6 для IPv6). Значення sk->sk_bound_dev_if копіюється безпосередньо в поле flowi4_oif:

struct flowi4 fl4 = {
    .flowi4_oif = sk->sk_bound_dev_if,
    .daddr = dst_ip,
    .saddr = src_ip,
    ...
};

Під час пошуку маршруту (fib_lookup() у net/ipv4/fib_frontend.c) ядро враховує виключно ті маршрути, вихідний інтерфейс яких збігається з flowi4_oif:

  • Якщо в таблиці існує маршрут за замовчуванням 0.0.0.0/0 через eth0 з низькою метрикою, система відхиляє його, оскільки flowi4_oif вказує на wg0.
  • Пошук успішний лише тоді, коли знайдено дійсний шлях через wg0.
  • Якщо тунельний інтерфейс вимкнено адміністративно (ip link set wg0 down), пошук негайно завершується з помилкою. Ядро повертає статус -ENETUNREACH (Network is unreachable).

Ядро Linux за жодних умов не спрямовує пакети на альтернативний фізичний інтерфейс, якщо активне поле sk_bound_dev_if. Це забезпечує надійний апаратний бар'єр проти витоку даних.

Запобігання петлям тунелювання без використання Fwmark

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

  1. Створюється правило ip rule для зіставлення мітки fwmark 51820.
  2. Трафік без мітки спрямовується до таблиці маршрутизації VPN.
  3. Фоновий демон позначає зовнішні транспортні пакети UDP викликом SO_MARK = 51820.

Цей підхід працює, але він чутливий до збоїв у правилах iptables, nftables та зміщення пріоритетів ip rule. Перезапуск стороннього фаєрвола скидає мітки та руйнує захист.

Маршрутизація за мітками (Вразлива до скидання правил):
Пакет -> Мітка Netfilter -> Перевірка ip rule -> Таблиця VPN або WAN

Прив'язка на рівні сокета (Гарантується ядром):
Зовнішній демон VPN -> SO_BINDTOIFINDEX(eth0) -> Пряма передача у чергу eth0
Сокети додатків     -> SO_BINDTOIFINDEX(wg0)  -> Пряма передача в тунель wg0

Використання SO_BINDTODEVICE або SO_BINDTOIFINDEX робить поведінку передбачуваною:

  • Демон туннеля визначає індекс активного фізичного інтерфейсу (eth0_idx).
  • Сокету призначається параметр setsockopt(tunnel_fd, SOL_SOCKET, SO_BINDTOIFINDEX, &eth0_idx, sizeof(eth0_idx)).
  • Усі зашифровані пакети прямують виключно через eth0, незалежно від маршруту за замовчуванням на wg0.

Системний механізм Killswitch на рівні операційної системи

Програмні засоби аварійного блокування (Killswitch), що діють у просторі користувача, мають затримку спрацьовування. Після розриву зв'язку службі моніторингу потрібен час, щоб отримати подію через netlink і застосувати правила блокування. За цей час відкриті сесії TCP можуть встигнути надіслати незашифровані дані через фізичну мережу.

Прив'язка інтерфейсу на рівні сокета діє миттєво в просторі ядра:

Сценарій неполадки Програмний Killswitch Прив'язка сокета (SO_BINDTODEVICE)
Падіння тунелю Витік інформації під час очікування реакції Помилка ENETUNREACH у системному виклику
Скидання таблиць Трафік переходить на фізичний інтерфейс Ядро зберігає суворе обмеження виходу
Зміна через DHCP Підміна маршруту спрямовує трафік назовні Поле flowi_oif блокує сторонній інтерфейс
Зниження прав Програма не може керувати фаєрволом Прив'язка сокета залишається дієвою

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

Практична реалізація на мові C та взаємодія з VRF

1. Створення захищеного сокета на C

Наведений приклад демонструє, як надійно закріпити сокет за віртуальним інтерфейсом тунелю:

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <net/if.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <errno.h>

int create_pinned_socket(const char *interface_name) {
    int fd = socket(AF_INET, SOCK_STREAM, 0);
    if (fd < 0) {
        perror("Помилка створення сокета");
        return -1;
    }

    /* Отримання числового індексу інтерфейсу */
    unsigned int ifindex = if_nametoindex(interface_name);
    if (ifindex == 0) {
        fprintf(stderr, "Інтерфейс %s не знайдено: %s\n",
                interface_name, strerror(errno));
        close(fd);
        return -1;
    }

    /* Рекомендований спосіб: SO_BINDTOIFINDEX (Linux 5.0+) */
    if (setsockopt(fd, SOL_SOCKET, SO_BINDTOIFINDEX,
                   &ifindex, sizeof(ifindex)) < 0) {
        /* Резервний варіант для старіших версій ядра */
        if (setsockopt(fd, SOL_SOCKET, SO_BINDTODEVICE,
                       interface_name, strlen(interface_name) + 1) < 0) {
            perror("Помилка setsockopt SO_BINDTODEVICE");
            close(fd);
            return -1;
        }
    }

    return fd;
}

2. Права доступу в сучасних ядрах Linux

Раніше для виклику SO_BINDTODEVICE були потрібні права суперкористувача (root) або привілей CAP_NET_RAW. У контейнеризованих системах надання таких прав розширює вектори атак.

Починаючи з Linux 5.7, ядро пом'якшило вимоги:

  • Звичайний процес може прив'язувати сокет, якщо сокет належить до простору імен користувача, що керує відповідним мережевим простором (ns_capable(net->user_ns, CAP_NET_RAW)).
  • Програми можуть закріплювати сокети за інтерфейсами всередині свого мережевого середовища без додаткових дозволів.
  • Системні служби можуть зв'язати сокет з wg0 під час старту, після чого безпечно знизити права (setuid()), зберігаючи дієву прив'язку.

3. Спільна робота з доменами віртуальної маршрутизації VRF

У разі використання технології Linux VRF (l3mdev) головні пристрої VRF функціонують як мережеві інтерфейси. Прив'язка сокета через SO_BINDTODEVICE до головного інтерфейсу VRF (наприклад, vrf-secure) скеровує всі запити до окремої таблиці FIB відповідного домену.

Якщо сокет прив'язується до підпорядкованого адаптера (наприклад, wg0 всередині vrf-secure), застосовується подвійний контроль: дані виходять суворо через wg0 і маршрутизуються за правилами ізольованого простору VRF.

Дворівнева модель фіксації сокетів у протоколі RiceGuard

У сервісі VPNRice технологія фіксації інтерфейсів сокетів є базовим елементом протоколу RiceGuard. Замість окремого налаштування фаєрвола система реалізує дворівневу структуру:

[ Додатки користувача та системний DNS ]
       |
       v
  Рівень сокетів: Жорстка прив'язка до віртуального адаптера RiceGuard (wg0 / rice0)
  Результат: Усунення витоків DNS та захист від підміни шлюзів
       |
[ Криптографічний модуль RiceGuard ]
       |
       v
  Транспортний сокет: Прив'язка до ifindex фізичного порту WAN
  Результат: Стабільний вихід пакетів без ризику виникнення петель
  1. Захист клієнтських потоків: Клієнт VPNRice фіксує сокети системного DNS та з'єднання додатків на індексі віртуального тунелю. Під час перемикання між точками Wi-Fi або мобільними мережами незашифровані пакети не можуть потрапити у фізичну мережу.
  2. Динамічна адаптація зв'язку: У разі зміни фізичного підключення модуль транспорту RiceGuard визначає новий індекс інтерфейсу та атомарно оновлює сокет через SO_BINDTOIFINDEX без скидання активної сесії.
  3. Захист у публічних мережах: Контроль індексів у сокеті нейтралізує спроби небезпечних серверів DHCP нав'язати фіктивний шлюз у відкритих мережах.

Використання вбудованих функцій ядра Linux гарантує надійний захист конфіденційності, високу швидкість обробки пакетів та бездоганну цілісність даних.