Небезпека витоку незашифрованих даних під час періодичного опитування маршрутів

У мережевих шлюзах із підтримкою кількох зовнішніх підключень (Multi-WAN) та корпоративних серверах VPN стабільність каналів зв'язку безпосередньо залежить від швидкості виявлення апаратних змін. Коли на оптоволоконній лінії стається обрив, мобільний модем втрачає сигнал базової станції або завершується термін оренди IP-адреси DHCP, таблиця маршрутизації ядра Linux (Forwarding Information Base, FIB) переходить у стан нестабільності.

Традиційні сценарії адміністрування нерідко покладаються на періодичне опитування (polling): виконання команди ip route show через дочірній процес щокілька секунд, розбір тексту або пінгування тестових серверів. Такий підхід створює критичні загрози в захищених мережах VPN:

  1. Часове вікно витоку відкритого тексту: Протягом кількох секунд між фізичним зникненням сигналу і наступним опитуванням програми продовжують надсилати мережеві пакети. Якщо типовий маршрут тунелю зникає або автоматично перенаправляється на незахищений резервний інтерфейс, конфіденційні дані виходять назовні без шифрування.
  2. Марнування ресурсів на перемикання контексту: Постійне створення процесів командного інтерпретатора та текстовий аналіз таблиць витрачає ресурси процесора, викликаючи коливання затримки під навантаженням.
  3. Стан перегонів під час мерехтіння лінії: Якщо канал зв'язку зазнає короткочасних відключень і відновлень (link flapping), повільний опитувач застосовує застарілі правила, що призводить до петель маршрутизації та падіння тунелів.

Щоб досягти миттєвої реакції на події зв'язку без найменшого витоку даних, сучасні демони VPN взаємодіють з асинхронною подієвою шиною ядра Linux: RTNetlink (NETLINK_ROUTE).

Протокол Netlink є внутрішнім механізмом міжпроцесної взаємодії (IPC) Linux, розробленим для обміну станами між ядром і простором користувача через стандартизовані сокети BSD (AF_NETLINK). На відміну від статичних викликів ioctl, Netlink забезпечує двостороннє асинхронне передавання повідомлень і багатоадресне транслювання подій (multicast) у реальному часі.

Спеціалізований підпротокол RTNetlink керує таблицями маршрутизації, станами фізичних адаптерів, IP-адресами, таблицями сусідів (ARP/NDP) та дисциплінами керування чергами (Traffic Control qdisc).

+-------------------------------------------------------------------+
|                     Демон VPN у просторі користувача              |
|    - Цикл обробки подій (epoll / kqueue)                          |
|    - Модуль розбору RTNetlink та кінцевий автомат                 |
+-------------------------------------------------------------------+
                  ^                                    |
      Асинхронний | Багатоадресні        Синхронні     | Оновлення
      потік       | групи                команди       | маршрутів
     (RTM_NEWLINK,| (RTMGRP_LINK,                      | (NLM_F_REPLACE,
      RTM_NEWROUTE|  RTMGRP_IPV4_ROUTE)                |  RTM_NEWROUTE)
                  |                                    v
+-------------------------------------------------------------------+
|                      Ядро Linux: Netlink Core                     |
|                    (AF_NETLINK / NETLINK_ROUTE)                   |
+-------------------------------------------------------------------+
        ^                                            |
        | Сповіщення про події                       | Модифікації FIB
        |                                            v
+---------------------------+        +------------------------------+
| Апаратні події адаптера   |        | Таблиця пересилання ядра     |
| (carrier on/off, netif_*) |        | (FIB IPv4 / IPv6, ip rules)  |
+---------------------------+        +------------------------------+

Основні групи багатоадресної розсилки

Щоб отримувати системні повідомлення без затримок і без опитування, демон VPN відкриває необроблений сокет Netlink і підписується на потрібні групи:

struct sockaddr_nl sa;
memset(&sa, 0, sizeof(sa));
sa.nl_family = AF_NETLINK;
sa.nl_groups = RTMGRP_LINK | RTMGRP_IPV4_IFADDR | RTMGRP_IPV4_ROUTE | RTMGRP_IPV6_ROUTE;

int fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
bind(fd, (struct sockaddr *)&sa, sizeof(sa));

Ключові типи повідомлень ядра:

  • RTM_NEWLINK / RTM_DELLINK: Надходять негайно, коли інтерфейс змінює адміністративний стан (IFF_UP), втрачає чи відновлює несучу частоту (IFF_RUNNING / IFLA_CARRIER) або змінює розмір MTU.
  • RTM_NEWADDR / RTM_DELADDR: Формуються під час призначення або видалення IP-адреси службами DHCP, SLAAC або вручну.
  • RTM_NEWROUTE / RTM_DELROUTE: Розсилаються за будь-якої зміни записів у таблиці маршрутизації FIB.

Під час виникнення мережевих змін ядро розміщує структури nlmsghdr у буфері приймання сокета. Кожне повідомлення містить заголовок та ланцюжок атрибутів маршрутизації (Routing Attributes - RtAttr):

+-------------------------+-------------------------+------------------------+
|  nlmsghdr (16 байтів)   |   rtmsg (12 байтів)     |  Дані rtattr...        |
|  - nlmsg_len            |   - rtm_family          |  - RTA_DST             |
|  - nlmsg_type           |   - rtm_table           |  - RTA_GATEWAY         |
|  - nlmsg_flags          |   - rtm_protocol        |  - RTA_OIF (Інтерфейс) |
|  - nlmsg_seq / pid      |   - rtm_scope           |  - RTA_PRIORITY (Метр.)|
+-------------------------+-------------------------+------------------------+

Безпечна обробка через макроси POSIX

Стандартні макроси ядра (NLMSG_OK, NLMSG_NEXT, RTA_OK, RTA_NEXT) гарантують захищений розбір повідомлень без виходу за межі виділеної пам'яті:

char buffer[8192];
ssize_t len = recv(fd, buffer, sizeof(buffer), 0);

for (struct nlmsghdr *nh = (struct nlmsghdr *)buffer; NLMSG_OK(nh, len); nh = NLMSG_NEXT(nh, len)) {
    if (nh->nlmsg_type == NLMSG_DONE) break;
    if (nh->nlmsg_type == NLMSG_ERROR) { /* Обробка помилки */ continue; }

    if (nh->nlmsg_type == RTM_NEWROUTE || nh->nlmsg_type == RTM_DELROUTE) {
        struct rtmsg *rt = (struct rtmsg *)NLMSG_DATA(nh);
        struct rtattr *rta = (struct rtattr *)RTM_RTA(rt);
        int rta_len = RTM_PAYLOAD(nh);

        for (; RTA_OK(rta, rta_len); rta = RTA_NEXT(rta, rta_len)) {
            if (rta->rta_type == RTA_GATEWAY) {
                // Визначення IP-адреси шлюзу
            } else if (rta->rta_type == RTA_OIF) {
                int ifindex = *(int *)RTA_DATA(rta);
                // Отримання індексу вихідного адаптера
            }
        }
    }
}

Запобігання переповненню буфера сокета (ENOBUFS)

Під час масових мережевих змін (наприклад, у разі одночасного відкликання тисяч маршрутів BGP) ядро здатне створити тисячі сповіщень за мілісекунди. Якщо процес користувача тимчасово витісняється планувальником, буфер сокета переповнюється, що призводить до втрати повідомлень і появи помилки -ENOBUFS.

Коректна реалізація використовує дворівневий захист:

  1. Збільшення обсягу буфера сокета: Застосування параметра SO_RCVBUFFORCE (потребує дозволу CAP_NET_ADMIN) для розширення буфера до 16 або 32 МБ:
    int rcvbuf = 16 * 1024 * 1024;
setsockopt(fd, SOL_SOCKET, SO_RCVBUFFORCE, &rcvbuf, sizeof(rcvbuf));
  2. Повна синхронізація через NLM_F_DUMP: Якщо сталася помилка ENOBUFS, зв'язність потоку порушено. Демон надсилає запит повного знімка (NLM_F_REQUEST | NLM_F_DUMP) з командою RTM_GETROUTE, відновлюючи стан FIB у пам'яті без перезапуску тунелів.

Створення відмовостійкої архітектури Multi-WAN без витоку даних

Щоб гарантувати повну захищеність трафіку під час перемикання ліній, зміна маршрутів повинна виконуватися атомарно за підтримки правил маршрутизації ядра (ip rule).

[ Трафік застосунків ]
           |
           v
+-------------------------------------------------------------+
| Правила маршрутизації за політиками (ip rule):              |
| - Маркований трафік тунелю (fwmark 0x51820) -> 'main'       |
| - Увесь інший звичайний трафік              -> 'vpn'        |
+-------------------------------------------------------------+
                               |
               +---------------+---------------+
               |                               |
               v                               v
+-------------------------------+   +-------------------------+
| Таблиця 'vpn':                |   | Таблиця 'main':         |
| - default dev wg0 метрика 50  |   | - default через WAN 1   |
| - default blackhole метр. 999 |   |   (eth0, 192.168.1.1)   |
+-------------------------------+   | - default через WAN 2   |
                                    |   (eth1, 10.0.0.1)      |
                                    +-------------------------+

1. Захисний маршрут blackhole

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

# Додавання захисного маршруту blackhole до таблиці vpn
ip route add blackhole default table vpn metric 999

Якщо основний інтерфейс тунелю (wg0 або riceguard0) вимикається, ядро негайно перенаправляє наступні пакети в цей тупиковий маршрут, знищуючи їх без навантаження на процесор та запобігаючи передаванню відкритого тексту через фізичний порт.

2. Атомарне оновлення прапорцем NLM_F_REPLACE

Замість двох окремих кроків видалення старого маршруту і додавання нового, RTNetlink дозволяє здійснити атомарну заміну за один системний виклик. Надсилаючи повідомлення RTM_NEWROUTE з прапорцями NLM_F_REQUEST | NLM_F_CREATE | NLM_F_REPLACE, ядро миттєво змінює вказівник шлюзу в таблиці FIB без втрати активних пакетів.

3. Динамічне керування з'єднаннями у RiceGuard

У корпоративних сценаріях RiceGuard із двома незалежними провайдерами зв'язку демон відстежує сигнали несучої RTNetlink для плавного перемикання каналів.

Коли подія RTM_NEWLINK сповіщає про зникнення сигналу на оптичній лінії (IFLA_CARRIER переходить у 0), демон RiceGuard переприв'язує сокети UDP до мобільного інтерфейсу через SO_BINDTOIFINDEX лише за 4 мілісекунди. Завдяки роботі тунелів на віртуальному рівні користувацькі сесії TCP і виклики VoIP продовжують функціонувати без розривів.

Адміністратори мають можливість відстежувати події ядра в реальному часі за допомогою стандартних утиліт:

# Пряме спостереження за всіма змінами з'єднань, адрес і маршрутів
ip monitor all

# Моніторинг виключно подій маршрутизації з точними часовими мітками
ip -ts monitor route

# Перевірка черг сокетів Netlink та втрачених повідомлень
ss -u -a --netlink
cat /proc/net/netlink

У виведенні /proc/net/netlink зверніть увагу на стовпчик Drops у рядку протоколу NETLINK_ROUTE (protocol 0). Значення більше нуля свідчить про те, що застосунок не встигає зчитувати сповіщення і потребує розширення системного буфера.

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

  • Розділення сокетів керування та прослуховування: Використовуйте один сокет виключно для фонового приймання багатоадресних подій, а другий — для передавання команд конфігурації. Це усуває взаємне блокування запитів.
  • Використання числових індексів інтерфейсів: Завжди відстежуйте мережеві адаптери за постійним числовим індексом ядра (ifindex), а не за назвою (eth0), уникаючи колізій під час перейменування портів.
  • Ізоляція таблиць маршрутизації (ip rule): Ніколи не призначайте загальний маршрут VPN безпосередньо в системну таблицю main. Використовуйте відокремлені таблиці для забезпечення контролю за трафіком.

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