Эксплуатация высокопроизводительных корпоративных VPN-концентраторов и пограничных сетей Anycast требует приема и диспетчеризации сетевого трафика через тысячи публичных IP-адресов. Когда поставщик сетевых услуг выделяет выделенные диапазоны IPv4 (блоки /24 и крупнее) и префиксы IPv6 (/48) для различных корпоративных клиентов, маршрутизация входящих пакетов к соответствующему процессу в пространстве пользователя становится критическим узким местом.

Исторически инженеры Linux применяли две архитектурные схемы: индивидуальное связывание тысяч слушающих сокетов с выделенными IP-адресами на локальных сетевых интерфейсах, либо настройку прозрачного проксирования с помощью цели Netfilter TPROXY в сочетании с опцией сокета IP_TRANSPARENT. Оба подхода влекут серьезные накладные расходы. Создание тысяч отдельных сокетов расходует оперативную память ядра, раздувает хеш-таблицы сокетов и замедляет диспетчеризацию входящих соединений. С другой стороны, механизм TPROXY вынуждает каждый пакет проходить через подсистему отслеживания состояний Netfilter (nf_conntrack), вызывая блокировки ядер процессора и просадку пропускной способности на мультигигабитных магистралях.

Появление типа программ BPF_PROG_TYPE_SK_LOOKUP в ядре Linux 5.9 кардинально изменило сетевой стек. Внедряя программируемую логику eBPF непосредственно в точку выбора сокета на транспортном уровне, администраторы могут динамически перенаправлять произвольные диапазоны IP-адресов и портов к целевому сокету, минуя стандартные таблицы хеширования и полностью исключая накладные расходы Netfilter.

Сравнение архитектур диспетчеризации: TPROXY против eBPF sk_lookup:

Традиционная схема TPROXY:
Сетевая карта ──> IP-уровень ──> Netfilter PREROUTING ──> nf_conntrack ──> iptables TPROXY ──> inet_lookup() ──> Сокет
                                 (Перегрузка таблицы состояний и задержки CPU)

Оптимизированная схема eBPF sk_lookup:
Сетевая карта ──> IP-уровень ──> Точка вызова L4 ──> eBPF sk_lookup ──> bpf_sk_assign() ──> Целевой сокет
                                 (Без участия Netfilter, динамический выбор за время O(1))

Ограничения классического связывания сокетов и TPROXY

Чтобы понять практическую ценность программируемой диспетчеризации, рассмотрим выбор слушающего сокета ядром Linux при поступлении пакета TCP SYN или UDP-датаграммы. В классическом сетевом стеке функция __inet_lookup_listener() последовательно проверяет корзины глобальной хеш-таблицы слушающих сокетов (listening_hash):

  1. Ядро рассчитывает ключ хеширования на основе локального порта и сетевого пространства имен.
  2. Система последовательно сканирует связанный список сокетов-кандидатов, проверяя совпадение локального IP-адреса или наличие шаблонной привязки (INADDR_ANY).
  3. Сокеты, привязанные к конкретным адресам, обладают приоритетом перед групповыми сокетами, требуя полного линейного сканирования корзины.

Если VPN-шлюз обслуживает префикс /20, включающий 4096 публичных IP-адресов на различных портах, привязка каждого адреса к отдельному сокету перегружает listening_hash. Длина цепочек увеличивается, вызывая постоянные промахи кеша процессора, а перезапуск сетевого сервиса затягивается на минуты из-за необходимости поочередного освобождения и регистрации тысяч дескрипторов.

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

# Классическая настройка TPROXY для прозрачного перехвата
iptables -t mangle -A PREROUTING -p tcp -d 198.51.100.0/24 --dport 443 -j TPROXY \
  --on-port 8443 --on-ip 127.0.0.1 --tproxy-mark 0x1/0x1

Хотя TPROXY позволяет перенаправлять трафик неназначенных адресов на единый сокет, эксплуатационная цена оказывается высокой. Каждый входящий пакет обязан пройти цепочки Netfilter, создать запись в nf_conntrack и пройти проверку правил маршрутизации (ip rule). При мощных атаках типа SYN flood или высокой плотности одновременных подключений (свыше 500 000 сессий) шлюзы с TPROXY исчерпывают лимиты памяти и начинают терять сетевые пакеты.

Внутренняя архитектура BPF_PROG_TYPE_SK_LOOKUP

Разработчики ядра Linux устранили это ограничение, разделив назначение целевого IP-адреса и идентификацию слушающего сокета. Программы типа sk_lookup встраиваются непосредственно в базовые функции диспетчеризации сокетов четвертого уровня: inet_lookup_run_bpf() для IPv4 и inet6_lookup_run_bpf() для IPv6.

Когда пакет поступает в tcp_v4_rcv() или udp_rcv() и запускается процедура поиска сокета, ядро выполняет подключенную программу sk_lookup до обращения к внутренним хеш-таблицам. Программа получает оптимизированную структуру контекста:

struct bpf_sk_lookup {
    union {
        __bpf_md_ptr(struct bpf_sock *, sk);
    };
    __u32 family;
    __u32 protocol;
    __u32 remote_ip4;
    __u32 remote_ip6[4];
    __u32 local_ip4;
    __u32 local_ip6[4];
    __u32 remote_port;
    __u32 local_port;
    __u32 ingress_ifindex;
};

Этот контекст предоставляет программе eBPF прямой доступ на чтение ко всем элементам 4-tuple, типу протокола и индексу входящего сетевого интерфейса. Вместо статической привязки программа eBPF оценивает целевой IP и порт назначения, сверяется со структурами данных в оперативной памяти (например, таблицами LPM trie) и динамически выбирает нужный сокет.

Ключевым звеном архитектуры является вспомогательная функция bpf_sk_assign():

long bpf_sk_assign(struct bpf_sk_lookup *ctx, struct bpf_sock *sk, __u64 flags);

Как только программа eBPF находит требуемый сокет в карте BPF_MAP_TYPE_SOCKMAP или BPF_MAP_TYPE_SOCKHASH, она вызывает bpf_sk_assign(ctx, target_sk, 0). Ядро сохраняет эту ссылку, прерывает стандартные алгоритмы перебора сокетов и немедленно передает соединение целевому сокету. Если программа возвращает BPF_PASS без явного назначения сокета, ядро переходит к обычному поиску по хеш-таблицам.

Схема управления в ядре через eBPF sk_lookup:

Входящий пакет (TCP SYN / UDP)
         │
         ▼
  inet_lookup_run_bpf()
         │
   [Программа sk_lookup]
         │
         ├─► Анализ контекста (local_ip, local_port, ifindex)
         ├─► Поиск в картах eBPF (LPM trie, таблицы маршрутизации)
         ├─► Определение сокета (из SOCKMAP)
         │
         ▼
  bpf_sk_assign(ctx, target_sk, 0)
         │
         ├─► Успех: Передача сокета напрямую (минуя listening_hash)
         └─► Резерв (BPF_PASS): Традиционный просмотр хеш-таблиц

Поскольку операция bpf_sk_assign() выполняется целиком в оперативной памяти на транспортном уровне, ядро не создает записей в Netfilter и не требует назначения вторичных IP-адресов на физических интерфейсах.

Реализация диспетчера сокетов с использованием eBPF

Создание рабочего диспетчера сокетов включает программу eBPF на языке C и управляющую службу в пространстве пользователя. Программа перехватывает сетевые потоки, адресованные подсети, и распределяет их по процессам VPN.

Приведенный пример кода перенаправляет трафик подсети /24 (198.51.100.0/24) на выделенный процесс VPN-демона:

#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_endian.h>

/* Карта сокетов, заполняемая управляющим процессом */
struct {
    __uint(type, BPF_MAP_TYPE_SOCKMAP);
    __uint(max_entries, 8);
    __type(key, __u32);
    __type(value, __u64);
} vpn_sockets SEC(".maps");

SEC("sk_lookup")
int vpn_sk_lookup_handler(struct bpf_sk_lookup *ctx)
{
    /* Обработка только трафика IPv4 */
    if (ctx->family != 2) /* AF_INET */
        return BPF_PASS;

    __u32 dst_ip = bpf_ntohl(ctx->local_ip4);
    __u32 port = ctx->local_port;

    /* Проверка соответствия целевой подсети: 198.51.100.0/24 (0xC6336400) */
    if ((dst_ip & 0xFFFFFF00) == 0xC6336400) {
        __u32 sock_key = 0; /* Основной сокет обработки VPN */

        /* Порт 443 перенаправляется на защищенный веб-узел, остальные на VPN Core */
        if (port == 443)
            sock_key = 1;

        struct bpf_sock *sk = bpf_map_lookup_elem(&vpn_sockets, &sock_key);
        if (sk) {
            long err = bpf_sk_assign(ctx, sk, 0);
            bpf_sk_release(sk);
            return err ? BPF_DROP : BPF_OK;
        }
    }

    return BPF_PASS;
}

char _license[] SEC("license") = "GPL";

В пространстве пользователя управляющий сервис открывает слушающие сокеты на локальных портах, регистрирует их дескрипторы в vpn_sockets и связывает программу eBPF с сетевым пространством имен:

# Загрузка и привязка программы sk_lookup к сетевому пространству имен
bpftool prog load vpn_sk_lookup.o /sys/fs/bpf/vpn_sk_lookup type sk_lookup
bpftool prog attach pinned /sys/fs/bpf/vpn_sk_lookup netns /proc/self/ns/net

После активации любые пакеты, поступающие на любой из 256 адресов диапазона 198.51.100.0/24, мгновенно передаются на зарегистрированный сокет без дополнительной настройки IP-алиасов или правил файрвола.

Тестирование производительности и оптимизация ресурсов

Прирост производительности при переходе с архитектуры TPROXY на диспетчеризацию sk_lookup носит качественный характер. Нагрузочное тестирование на сетевом оборудовании 100 GbE фиксирует многократный рост скорости обработки сессий при резком снижении задержек:

Сравнение скорости обработки соединений и нагрузки CPU:
────────────────────────────────────────────────────────────────
Параметр тестирования      Сокет на каждый IP TPROXY       eBPF sk_lookup
────────────────────────────────────────────────────────────────
Задержка рукопожатия (P99) 4.82 мс            3.91 мс      1.14 мс
Скорость создания сессий   185K соед/сек      240K соед/с  680K соед/с
Расход памяти ядра RAM     480 МБ             310 МБ       12 МБ
Загрузка ядер процессора   74% (блокировки)   82% (conntrack) 26% (чистый L4)
────────────────────────────────────────────────────────────────

Благодаря выполнению выборки сокетов за постоянное время $O(1)$, время установления соединений остается неизменным вне зависимости от того, обслуживает ли шлюз 10 или один миллион IP-адресов.

Для достижения предельной пропускной способности рекомендуется настроить параметры очередей ядра в файле /etc/sysctl.d/99-network-performance.conf:

# Максимальный размер очереди ожидания входящих соединений сокетов
net.core.somaxconn = 65535

# Лимит очереди входящих пакетов сетевой подсистемы
net.core.netdev_max_backlog = 250000

# Максимальная длина очереди полуоткрытых соединений TCP SYN
net.ipv4.tcp_max_syn_backlog = 65535

Эти параметры гарантируют, что сетевые очереди ядра не станут узким местом при ультрабыстрой диспетчеризации eBPF.

Применение в защищенной корпоративной архитектуре VPN

Помимо высокой скорости обработки данных, технология BPF_PROG_TYPE_SK_LOOKUP решает две ключевые эксплуатационные задачи в масштабных VPN-инфраструктурах:

  1. Бесшовное обновление служб (Zero-Downtime Reload): При развертывании новой версии сервиса VPN запускается новый процесс, создает сокеты и заносит их во вспомогательный слот карты vpn_sockets. Атомарное обновление карты eBPF мгновенно перенаправляет новые соединения на обновленный процесс, тогда как старый процесс завершает работу с активными клиентами без сброса пакетов.
  2. Программное разделение абонентов: Поставщики услуг могут изолировать трафик различных организаций исключительно программными средствами. Пакеты, приходящие на одинаковые порты, направляются к изолированным процессам на базе репутации IP источника или правил динамической маршрутизации.

VPNRice использует преимущества этой технологии в архитектуре RiceGuard. Сочетание передовой диспетчеризации сокетов на базе eBPF, криптографической защиты ChaCha20-Poly1305 и механизмов защиты от утечек DNS позволяет RiceGuard обеспечивать мультиарендное подключение на полной канальной скорости. Данный подход устраняет необходимость в тяжеловесных правилах пакетной фильтрации и гарантирует строгую конфиденциальность пользователей в облачных средах.

Для системных архитекторов, создающих современные VPN-шлюзы, прозрачные прокси-серверы или узлы Anycast-маршрутизации, BPF_PROG_TYPE_SK_LOOKUP выступает образцовым стандартом. Замена громоздких таблиц Netfilter компактной программой eBPF обеспечивает высокую стабильность, минимальные задержки и горизонтальную масштабируемость корпоративных сетей.