На панели задач операционной системы отображается активное защищенное соединение. Виртуальный сетевой адаптер исправно передает данные, рукопожатие WireGuard регулярно обновляется, а системный брандмауэр рапортует о полной готовности функции аварийного отключения (Kill Switch). Однако каждый незашифрованный HTTP-запрос, DNS-вызов и конфиденциальный сетевой пакет, отправляемый через публичный Wi-Fi кафе, беспрепятственно поступает на сервер злоумышленника в виде открытых Ethernet-фреймов.

Эта архитектурная угроза деанонимизации зарегистрирована как CVE-2024-3661 и получила название TunnelVision. Обнаруженная исследователями компании Leviathan Security Group, атака TunnelVision не опирается на уязвимости повреждения памяти или сбои криптографических алгоритмов. Она задействует документированный сетевой механизм, встроенный в протокол динамической конфигурации узла (DHCP) еще в 2002 году: опцию DHCP Option 121 (стандарт RFC 3442, The Classless Static Route Option).

Внедряя произвольные статические маршруты на этапе согласования локального IP-адреса, злоумышленник в том же сегменте локальной сети (LAN) манипулирует системной таблицей маршрутизации ядра, направляя пользовательский трафик мимо шифрованного туннеля без разрыва VPN-сессии.

[Пользовательское приложение / Браузер]
                   │
                   ▼
     [Таблица маршрутизации ядра ОС]
     ┌─────────────────────────────┐
     │ Анализ правил маршрутизации │
     └─────────────┬───────────────┘
                   │
     ┌─────────────┴───────────────────────────────┐
     │                                             │
[Маршрут по умолчанию VPN]          [Внедренные маршруты Option 121]
  Префикс: 0.0.0.0/0 (Метрика 1)       Префикс: 0.0.0.0/1 + 128.0.0.0/1
  Интерфейс: tun0 (Шифрованный)        Интерфейс: wlan0 (Открытый физический)
     │                                             │
     │ (Игнорируется: короткий префикс)            │ (Выбирается: наиболее длинный префикс!)
     │                                             ▼
     ▼                                [Поддельный шлюз перехвата данных]
[Защищенный VPN-сервер]                  (Чтение открытого трафика жертвы)

Механика TunnelVision: использование правила Longest Prefix Match

Чтобы понять, почему TunnelVision преодолевает защиту традиционных VPN-клиентов, необходимо рассмотреть базовый принцип пересылки IP-пакетов в ядре операционной системы: правило наибольшей длины префикса (Longest Prefix Match — LPM).

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

Большинство стандартных VPN-клиентов перехватывают трафик путем создания маршрута по умолчанию (Default Route):

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.1        0.0.0.0         UG    50     0        0 tun0

Маршрут 0.0.0.0/0 покрывает все адреса сети Интернет, но имеет нулевую длину префикса (/0), обладая наименьшим приоритетом при сопоставлении.

При подключении к недоверенной точке Wi-Fi устройство рассылает широковещательный запрос DHCP Discover. Поддельный DHCP-сервер атакующего отправляет ответ DHCP Offer, содержащий опцию Option 121. Стандарт RFC 3442 позволяет серверу внедрить произвольные бесклассовые статические маршруты напрямую в таблицу клиента.

Злоумышленник передает два маршрута, перекрывающих всё адресное пространство IPv4:

  1. 0.0.0.0/1 через локальный шлюз 192.168.1.1 (диапазон 0.0.0.0 — 127.255.255.255)
  2. 128.0.0.0/1 через локальный шлюз 192.168.1.1 (диапазон 128.0.0.0 — 255.255.255.255)

Поскольку длина префикса /1 больше длины /0, сетевой стек отправляет исходящие пакеты через физический адаптер wlan0, а не через туннельный интерфейс tun0. Трафик покидает устройство в открытом виде, поступая напрямую на аппаратуру злоумышленника.

+--------------------------+-----------------+--------------------+------------------------+
| Запись маршрутизации     | Длина префикса  | Целевой интерфейс  | Приоритет применения   |
+--------------------------+-----------------+--------------------+------------------------+
| Маршрут по умолчанию     | /0 (Широкий)    | tun0 (Шифрование)  | Перекрывается маской /1|
| Option 121 (0.0.0.0/1)   | /1 (Специфичный)| wlan0 (Открытый)   | Выбирается (1-я часть) |
| Option 121 (128.0.0.0/1) | /1 (Специфичный)| wlan0 (Открытый)   | Выбирается (2-я часть) |
| Конкретный хост (/32)    | /32 (Точный)    | wlan0 (Открытый)   | Абсолютный приоритет   |
+--------------------------+-----------------+--------------------+------------------------+

Причины неэффективности классических Kill Switch

Многие пользователи полагаются на встроенную функцию экстренного отключения трафика (Kill Switch). Однако классические модули Kill Switch разрабатывались для защиты при обрыве соединения, а не для противодействия отравлению таблиц маршрутизации:

  • Контроль состояния туннельного адаптера: Большинство реализаций Kill Switch отслеживают активность виртуального интерфейса (tun0). Если соединение разрывается, брандмауэр блокирует исходящий трафик. При атаке TunnelVision VPN-туннель остается активным и исправно передает служебные пакеты, поэтому защитный механизм не срабатывает.
  • Исключения для локальной подсети: Для сохранения доступа к сетевым принтерам и накопителям NAS брандмауэры часто разрешают прямой обмен пакетами в пределах локальной сети. Опция 121 маскирует маршруты ко всему Интернету под локальные направления, в результате чего фильтры пропускают открытые пакеты наружу.
  • Особенности операционных систем: Windows и большинство дистрибутивов Linux применяют маршруты RFC 3442 от DHCP автоматически без подтверждения пользователя, что делает рабочие станции уязвимыми без специальной изоляции.

Архитектурные методы защиты

Надежная защита от TunnelVision требует перехода от манипуляций с маршрутами к строгой системной изоляции сетевых стеков.

[Пользовательские программы (Браузер, Почта, Мессенджер)]
                          │
                          ▼
        [Сетевое пространство имен (Network Namespace)] <── (Полная изоляция)
                          │
                          ▼
               [Интерфейс tun0 / wg0]
                          │ (Шифрованный поток WireGuard)
                          ▼
 [Физическое пространство: wlan0] ──> [Выпуск только шифрованных пакетов]

1. Сетевые пространства имен (Network Namespaces)

В среде Linux сетевые пространства имен обеспечивают непреодолимый барьер. Помещая прикладные программы в изолированное пространство имен, содержащее только виртуальный интерфейс VPN (wg0 или tun0), система полностью скрывает физический адаптер wlan0. Любые маршруты, передаваемые через DHCP Option 121 на физический интерфейс, остаются недоступными для прикладных программ.

2. Маршрутизация на основе политик (PBR) и метки брандмауэра

Современные конфигурации WireGuard задействуют механизм маркировки пакетов (fwmark):

# Перенаправление немаркированного трафика в таблицу 51820
ip rule add not fwmark 51820 table 51820
ip rule add table main suppress_prefixlength 0

Параметр suppress_prefixlength 0 блокирует попытки локальной таблицы перехватить трафик с помощью более специфичных маршрутов, принудительно направляя пакеты в таблицу VPN.

3. Отключение обработки Option 121 в клиенте DHCP

На рабочих станциях можно отключить автоматический прием бесклассовых маршрутов в конфигурации DHCP-клиента (/etc/dhcp/dhclient.conf), удалив rfc3442-classless-static-routes из списка запрашиваемых параметров.

4. Комплексная изоляция трафика в RiceGuard

Протокол RiceGuard от VPNRice устраняет проблему отравления маршрутов на уровне ядра. С помощью правил nftables и подсистемы eBPF сетевой стек RiceGuard уничтожает любые нешифрованные пакеты, пытающиеся покинуть физический интерфейс мимо виртуального туннеля, независимо от содержимого ответов локального DHCP-сервера.

Практические рекомендации при работе в публичных сетях

  • Контроль таблицы маршрутов: После подключения к общественному Wi-Fi проверяйте маршруты командами ip route show или route print, обращая внимание на появление сторонних подсетей /1.
  • Использование мобильной точки доступа: При необходимости передачи конфиденциальных данных предпочтительнее использовать защищенный режим модема смартфона.
  • Проверка внешнего IP-адреса: Регулярно подтверждайте соответствие внешнего IP-адреса серверу VPN с помощью консольных утилит (curl https://ipinfo.io).