Linux RTNetlink: мониторинг маршрутов и failover Multi-WAN для VPN

Опасность утечки данных при периодическом опросе состояния маршрутов

В корпоративных маршрутизаторах с несколькими внешними каналами (Multi-WAN) и высоконагруженных концентраторах VPN стабильность сетевой архитектуры напрямую зависит от скорости выявления изменений на физическом уровне. При аварии на оптической линии, потере сигнала модемом связи или истечении срока аренды DHCP таблица пересылки пакетов ядра Linux (Forwarding Information Base, FIB) входит в состояние переходных процессов.

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

Временное окно утечки нешифрованного трафика: В промежутке между физическим обрывом кабеля и следующим циклом опроса сокеты приложений продолжают отправлять данные. Если маршрут VPN внезапно исчезает или перенаправляется на незащищенный резервный интерфейс, открытый текст направляется во внешнюю сеть без криптографической инкапсуляции.
Накладные расходы переключения контекста: Постоянный запуск процессов оболочки и разбор текстовых таблиц расходует ресурсы процессора, вызывая рост джиттера при интенсивном сетевом потоке.
Состояние гонки при нестабильном канале: Если физический интерфейс кратковременно отключается и включается, медленный механизм опроса применяет устаревшие правила, что приводит к зацикливанию маршрутов и сбоям туннелей.

Для обеспечения мгновенной реакции на сетевые события без единой утечки данных современные демоны VPN взаимодействуют с асинхронной шиной событий ядра Linux: RTNetlink (NETLINK_ROUTE).

Архитектура подсистемы Linux RTNetlink (NETLINK_ROUTE)

Протокол Netlink представляет собой межпроцессное взаимодействие (IPC) Linux, предназначенное для обмена сетевыми состояниями между пространством ядра и демонами пространства пользователя через стандартные сокеты BSD (AF_NETLINK). В отличие от ioctl или системных вызовов к /proc, 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.

Цикл обработки событий и разбор структур данных Netlink

При изменении сетевых состояний ядро передает последовательность структур 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.

Надежная реализация предусматривает комплекс мер:

Увеличение буфера сокета: Использование системного флага SO_RCVBUFFORCE (требует привилегии CAP_NET_ADMIN) для расширения приемного буфера до 16 или 32 мегабайт:
```
int rcvbuf = 16 * 1024 * 1024;
setsockopt(fd, SOL_SOCKET, SO_RCVBUFFORCE, &rcvbuf, sizeof(rcvbuf));
```
Синхронизация через 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 не прерываются.

Диагностика и мониторинг RTNetlink в операционной системе

Системные инженеры могут в реальном времени отслеживать события ядра с помощью стандартных инструментов Linux:

# Непрерывный мониторинг всех изменений линков, адресов и маршрутов
ip monitor all

# Отслеживание событий маршрутизации с точными метками времени
ip -ts monitor route

# Анализ состояния сокетов Netlink и проверка отброшенных пакетов
ss -u -a --netlink
cat /proc/net/netlink

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

Практические рекомендации по развертыванию

Разделение управляющих и событийных сокетов: Выделяйте один сокет Netlink исключительно для фонового прослушивания многоадресных сообщений, а второй сокет — для отправки управляющих команд. Это исключает блокировку очередей ответов на команды.
Привязка к числовым индексам интерфейсов: Всегда идентифицируйте сетевые интерфейсы по неизменяемому индексу ядра (ifindex), а не по строковому имени (eth0), предотвращая ошибки при переименовании устройств.
Изоляция политик маршрутизации (ip rule): Не добавляйте глобальные маршруты VPN непосредственно в основную системную таблицу main. Используйте выделенные таблицы маршрутизации для исключения случайных утечек трафика.

Применение событийной модели RTNetlink дает шлюзам VPN на базе Linux способность мгновенно реагировать на любые неполадки каналов связи, сохраняя надежность соединения и целостность защищенного периметра.