В традиционной сетевой подсистеме Linux все интерфейсы разделяют общую таблицу маршрутизации — глобальную базу данных Forwarding Information Base (FIB). В стандартных рабочих станциях и серверах с одним сетевым подключением данная архитектура функционирует без сбоев.

Однако на узлах виртуальных частных сетей (VPN), маршрутизаторах с несколькими внешними каналами (Multi-WAN) и в многоарендных средах централизованная модель порождает серьезные риски утечки данных. Если различные интерфейсы находятся в едином пространстве маршрутизации, возникают конфликты шлюзов по умолчанию. При неожиданном разрыве зашифрованного туннеля трафик может моментально переключиться на физический адаптер (Wi-Fi или Ethernet), открывая незашифрованные пакеты и DNS-запросы внешним наблюдателям.

Исторически сетевые инженеры решали эту проблему с помощью сетевых пространств имен Linux (netns). Пространства имен обеспечивают полную изоляцию за счет клонирования сетевого стека (включая сокеты, loopback-интерфейсы, правила фильтрации и параметры sysctl), но создают значительные накладные расходы. Пересылка пакетов между пространствами имен требует создания пар виртуальных адаптеров veth или использования программ eBPF, что ведет к дополнительному расходу структур sk_buff и падению пропускной способности на скоростях 40GbE и 100GbE.

Для устранения этих ограничений в ядро Linux был интегрирован механизм Virtual Routing and Forwarding (VRF), функционирующий на базе подсистемы Layer 3 Master Device (l3mdev).

+--------------------------------------------------------------------------+
|          АРХИТЕКТУРА ИЗОЛЯЦИИ МАРШРУТИЗАЦИИ LINUX VRF И L3MDEV           |
+--------------------------------------------------------------------------+
|                                                                          |
|   +------------------------------------------------------------------+   |
|   |                   ПРИКЛАДНЫЕ ПРОЦЕССЫ USERSPACE                  |   |
|   |                                                                  |   |
|   |   +-------------------+                     +----------------+   |   |
|   |   | Защищенный клиент |                     | Демон SSH      |   |   |
|   |   |  (ip vrf exec)    |                     | (Управление)   |   |   |
|   +---+---------+---------+---------------------+--------+-------+---+   |
|                 | SO_BINDTODEVICE                        |               |
|                 v (vrf-secure)                           v               |
|   +------------------------------------------------------------------+   |
|   |                       СЕТЕВОЙ СТЕК ЯДРА LINUX                    |   |
|   |                                                                  |   |
|   |   [ Мастер VRF: vrf-secure ]            [ Глобальный стек / main]|   |
|   |   [ Таблица FIB: 100       ]            [ Таблица FIB: 254       ]   |
|   |                                                                  |   |
|   |   Поиск в FIB (Изолированный):          Поиск в FIB (Глобальный):|   |
|   |   default dev riceguard0                default via 192.168.1.1  |   |
|   |   10.8.0.0/24 dev riceguard0            192.168.1.0/24 dev eth0  |   |
|   |             |                                    |               |   |
|   |             |                                    |               |   |
|   |   +---------v---------+                +---------v---------+     |   |
|   |   | Подчиненный dev:  |                | Физический dev:   |     |   |
|   |   | riceguard0        |                | eth0 (WAN / Wi-Fi)|     |   |
|   |   +---------+---------+                +---------+---------+     |   |
|   +-------------|------------------------------------|---------------+   |
|                 v                                    v                   |
|     +-----------------------+            +-----------------------+       |
|     | Зашифрованный туннель |            | Внешний сетевой канал |       |
|     | (Полная изоляция)     |            | (Без утечек трафика)  |       |
|     +-----------------------+            +-----------------------+       |
|                                                                          |
+--------------------------------------------------------------------------+

Устройство подсистемы Linux VRF и драйвера l3mdev

В ядре Linux механизм VRF реализован как специализированный драйвер виртуальных сетевых устройств (drivers/net/vrf.c). В отличие от пространств имен, мастер-интерфейс VRF не дублирует сетевые протоколы, а служит привязкой к конкретному идентификатору таблицы маршрутизации FIB.

Физические или виртуальные сетевые интерфейсы переводятся в подчиненный режим (enslaved) по отношению к мастер-устройству VRF. После этого инфраструктура Layer 3 Master Device перехватывает обработку маршрутов:

1. Разделение поиска в таблицах FIB

Когда пакет поступает на подчиненный интерфейс, ядро вызывает обработчик l3mdev. Этот обработчик подменяет стандартный поиск по таблице main на поиск исключительно в таблице, привязанной к данному VRF (например, Таблица 100).

Поскольку записи внутри Таблицы 100 изолированы от глобальной таблицы 254, утечка маршрутов между доменами исключена:

  • Обратная фильтрация (rp_filter): проверка легитимности адреса источника выполняется строго в контексте таблицы VRF, блокируя поддельные входящие пакеты.
  • Изоляция исходящего шлюза: пакеты приложений, привязанных к VRF, не могут использовать маршруты по умолчанию из глобальной таблицы.

2. Привязка сокетов к домену VRF

Процессы операционной системы могут взаимодействовать с VRF через три стандартных механизма:

  1. Опция сокета SO_BINDTODEVICE: процесс привязывает дескриптор сокета к имени мастера VRF (например, vrf-secure). Все операции ввода-вывода используют соответствующую таблицу маршрутизации.
  2. Cgroups v2 и утилита ip vrf exec: механизм меток cgroup позволяет изолировать дерево процессов в нужном VRF без модификации исходного кода приложений.
  3. Опция SO_BINDTOIFINDEX: высокопроизводительный интерфейс привязки сокетов на уровне индексов устройств без блокировок.
+--------------------------------------------------------------------------+
|            СРАВНЕНИЕ МЕХАНИЗМОВ: VRF И СЕТЕВЫЕ ПРОСТРАНСТВА ИМЕН         |
+--------------------------------------------------------------------------+
| Характеристика         | VRF (l3mdev)            | Пространства имен     |
+------------------------+-------------------------+-----------------------+
| Разделение маршрутов   | Строго по таблицам FIB  | Полный клон стека     |
| Расход оперативной памяти | Минимальный (<10 КБ) | Ощутимый (>1 МБ/netns)|
| Междоменная пересылка  | Zero-copy внутри ядра   | Задержки veth и BPF   |
| Пространство сокетов   | Единое для хоста        | Полностью изолировано |
| Управление sysctl      | Централизованное        | Требует дублирования  |
| Пропускная способность | 40GbE - 100GbE line-rate| Снижается под нагрузкой|
+--------------------------------------------------------------------------+

Обслуживание сервисов с помощью tcp_l3mdev_accept

Классическая сложность при разделении маршрутизации заключается в работе сетевых демонов. Если локальный DNS-резолвер (например, Unbound) или служба SSH слушают сокет 0.0.0.0:53, они по умолчанию принимают соединения только из глобального домена. Интерфейсы из изолированных VRF не могут связаться с демоном из-за изоляции FIB.

Для решения этой задачи ядро Linux предоставляет системные параметры:

# Разрешить демонам TCP глобального домена принимать запросы из всех VRF
sysctl -w net.ipv4.tcp_l3mdev_accept=1

# Разрешить демонам UDP глобального домена принимать пакеты из всех VRF
sysctl -w net.ipv4.udp_l3mdev_accept=1

При активации tcp_l3mdev_accept входящий пакет TCP SYN на интерфейсе VRF успешно сопоставляется с глобальным слушающим сокетом. По завершении рукопожатия ядро автоматически связывает дочерний сокет с мастер-устройством входящего VRF. Все последующие пакеты ответа следуют строго через правильную таблицу маршрутизации.

Пошаговая настройка шлюза VPN с защитой от утечек

Развертывание защищенного домена VRF на сервере Linux выполняется стандартными средствами утилиты ip:

Шаг 1: Создание мастер-интерфейса VRF

Создаем виртуальный адаптер vrf-vpn, привязанный к таблице 100:

# Создание интерфейса VRF с таблицей 100
ip link add dev vrf-vpn type vrf table 100

# Активация интерфейса
ip link set dev vrf-vpn up

Шаг 2: Привязка туннеля и клиентских сетей

Включаем туннельный интерфейс (riceguard0) и локальный клиентский интерфейс (vlan20) в состав vrf-vpn:

# Подчинение интерфейсов мастеру VRF
ip link set dev riceguard0 master vrf-vpn
ip link set dev vlan20 master vrf-vpn

# Перевод интерфейсов в активное состояние
ip link set dev riceguard0 up
ip link set dev vlan20 up

Шаг 3: Наполнение изолированной таблицы маршрутов

Настраиваем сетевые маршруты исключительно внутри таблицы 100:

# Маршрут к подсети туннеля
ip route add 10.8.0.0/24 dev riceguard0 table 100

# Маршрут к клиентской локальной подсети
ip route add 192.168.20.0/24 dev vlan20 table 100

# Единый шлюз по умолчанию через зашифрованный туннель
ip route add default dev riceguard0 table 100

Шаг 4: Проверка и диагностика

Тестирование сетевой доступности внутри изолированного домена:

# Просмотр маршрутов в таблице 100
ip route show table 100

# Проверка связи через изолированный VRF
ip vrf exec vrf-vpn ping -c 3 10.8.0.1

# Контроль глобальной таблицы маршрутов
ip route show table main

При падении соединения riceguard0 трафик внутри Таблицы 100 теряет шлюз и отбрасывается ядром на месте. Поскольку физический порт eth0 находится в глобальной таблице, данные пользователей никогда не утекут в открытую сеть.

Интеграция с RiceGuard и VPNRice

В инфраструктуре сервиса VPNRice протокол туннелирования RiceGuard взаимодействует с механизмами Linux VRF и l3mdev, обеспечивая фундаментальные гарантии безопасности:

  1. Исключение утечек DNS: клиентские операционные системы нередко направляют DNS-запросы параллельно по всем активным адаптерам. Помещение адаптера RiceGuard и резолвера в закрытый домен VRF предотвращает выход запросов в физическую сеть Wi-Fi.
  2. Линейная скорость Multi-WAN: шлюзы агрегации обслуживают изолированные маршруты тысяч клиентов без снижения производительности пакетной обработки.
  3. Безопасность плоскости управления: административные интерфейсы (SSH, системы мониторинга) выносятся в выделенный служебный VRF, недоступный из пользовательских сессий.

Эксплуатационные требования

При проектировании промышленных систем с использованием VRF необходимо учитывать:

  • Строгая обратная проверка (rp_filter): активация net.ipv4.conf.all.rp_filter=1 защищает от междоменной подмены IP-адресов.
  • Единые правила межсетевого экрана: применение критериев iifname и oifname в nftables для мастер-интерфейса VRF упрощает фильтрацию подчиненных портов.
  • Параметры conntrack: общий пул отслеживания соединений требует своевременного увеличения лимита nf_conntrack_max.

Связка Linux VRF и l3mdev обеспечивает надежную изоляцию маршрутов без ущерба для скорости передачи данных, представляя собой надежную архитектурную основу для современных шлюзов VPN.