DHCP Option 121与TunnelVision漏洞：抵御VPN路由劫持与流量泄露

操作系统的任务栏明确显示虚拟专用网络（VPN）已建立加密连接，隧道握手保持活跃，系统防火墙的紧急断网开关（Kill Switch）亦处于就绪状态。然而，当设备接入公共无线网络时，浏览器发出的HTTP请求、DNS查询以及未加密的数据报文，却正通过本地物理以太网帧直接流向攻击者控制的恶意网关。

这种流量剥离攻击的技术代号为CVE-2024-3661，安全业界通称为TunnelVision。该漏洞由Leviathan Security Group的研究人员披露。TunnelVision并不依赖加密算法的数学缺陷或内存损坏攻击，而是利用了动态主机配置协议（DHCP）自2002年起便正式标准化的基础管理特性：DHCP Option 121（即RFC 3442规范中的无类静态路由选项 The Classless Static Route Option）。

在本地局域网（LAN）中，攻击者通过在DHCP租约协商过程中注入自定义静态路由表项，直接操控客户端操作系统的内核路由决策，迫使流量脱离加密隧道外发，而整个过程完全不会导致VPN连接断开。

[用户应用程序 / 网页浏览器]
                 │
                 ▼
     [操作系统内核路由表决策]
     ┌───────────────────────┐
     │ 匹配路由最长前缀原则  │
     └───────────┬───────────┘
                 │
     ┌───────────┴───────────────────────────────┐
     │                                           │
[常规VPN默认路由]                  [DHCP Option 121 注入的静态路由]
  前缀: 0.0.0.0/0 (掩码 0位)          前缀: 0.0.0.0/1 + 128.0.0.0/1
  接口: tun0 (加密管道)               接口: wlan0 (明文物理链路)
     │                                           │
     │ (前缀较短，优先级较低)                    │ (匹配前缀更长，具有更高优先级！)
     │                                           ▼
     ▼                              [攻击者部署的中间人监听网关]
[可信远端VPN服务器]                   (截获并分析全部明文通信流量)

TunnelVision的运作机制：最长前缀匹配原则

要理解TunnelVision如何打破传统VPN的保护，必须考察IP网络转发的核心决策逻辑：最长前缀匹配（Longest Prefix Match - LPM）。

当操作系统内核转发IP数据包时，会查询系统路由表中的所有条目。如果数据包的目标IP地址同时匹配多个子网规则，内核将严格选择子网掩码最长（即前缀位数最多）的规则进行转发，路由度量值（Metric）或虚拟接口设定在此原则面前均退居次席。

常规VPN软件在建立连接时通常设置一条默认路由：

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位（/0），是路由表中最宽泛、匹配优先级最低的条目。

当客户端接入不受信任的网络并发起DHCP Discover请求时，攻击者控制的恶意DHCP服务器在响应报文中包含Option 121。根据RFC 3442规范，Option 121允许DHCP服务器向客户端操作系统直接推送无类静态路由。

攻击者推送两条覆盖全部IPv4地址空间的路由：

0.0.0.0/1 指向本地流氓网关 192.168.1.1（涵盖 0.0.0.0 至 127.255.255.255）
128.0.0.0/1 指向本地流氓网关 192.168.1.1（涵盖 128.0.0.0 至 255.255.255.255）

由于 /1 的前缀长度大于 /0，操作系统的路由机制无条件将出站数据包分流至物理无线网卡 wlan0，而非加密隧道接口 tun0。网络通信以明文形式从物理层流出，VPN隧道表面保持联通，实际流量却已被完全旁路。

+--------------------------+-----------------+-------------------+-----------------------+
| 路由表条目               | 前缀长度        | 出口网络接口      | 内核转发优先级        |
+--------------------------+-----------------+-------------------+-----------------------+
| 默认路由 (0.0.0.0/0)     | /0 (最宽泛)     | tun0 (加密隧道)   | 被 /1 规则完全压制    |
| Option 121 (0.0.0.0/1)   | /1 (更精确)     | wlan0 (明文外发)  | 优先匹配前半段公网IP  |
| Option 121 (128.0.0.0/1) | /1 (更精确)     | wlan0 (明文外发)  | 优先匹配后半段公网IP  |
| 特定目标主机 (/32)       | /32 (绝对精确)  | wlan0 (明文外发)  | 具备绝对最高转发权    |
+--------------------------+-----------------+-------------------+-----------------------+

传统断网保护（Kill Switch）失效根源分析

许多用户认为开启VPN客户端的“Kill Switch”即可确保无虞。然而，传统Kill Switch的设计逻辑大多针对连接意外中断，而非路由表污染：

隧道状态监控局限： 传统Kill Switch主要监听虚拟网络接口（tun0）的心跳状态。在TunnelVision攻击下，VPN进程与远端服务器的会话始终存活，心跳正常响应，因此断网保护机制不会被触发。
局域网流量放行规则： 为保证用户在开启VPN时仍能使用本地无线打印机或NAS存储设备，防火墙策略普遍对局域网网段予以放行。Option 121恰好将目标网段重定向至本地网关地址，导致防火墙将其误判为合法的本地流量予以放行。
不同平台的默认行为： Windows与主流Linux发行版默认会自动采纳来自DHCP Option 121的静态路由，使得这些操作系统在公共网络环境下天然面临侧信道风险。

架构级防御方案：从根源阻断路由泄露

消除TunnelVision威胁需要构建严格的系统级网络隔离，而非单纯依赖应用层的路由指令修正。

[用户应用程序（浏览器、通信工具、终端）]
                        │
                        ▼
       [Linux 网络命名空间（Network Namespace）] <──（强隔离边界）
                        │
                        ▼
             [虚拟接口 tun0 / wg0]
                        │（WireGuard 加密数据流）
                        ▼
      [宿主物理命名空间: wlan0] ──> [仅允许外发外层加密握手报文]

1. 网络命名空间隔离（Network Namespaces）

在Linux环境中，网络命名空间能够提供彻底的隔离保护。通过将用户应用程序放置在仅包含VPN虚拟网卡（wg0 或 tun0）的独立网络命名空间中运行，应用程序将完全失去与物理无线网卡 wlan0 的通信视野。即便流氓DHCP服务器在宿主系统中注入恶意路由，隔离命名空间内的进程也无法解析或使用这些外部路径。

2. 基于策略的高级路由（PBR）与防火墙标记

现代WireGuard套件（wg-quick）通过数据包防火墙标记（fwmark）建立策略路由机制：

# 将未标记的数据包重定向至自定义路由表 51820
ip rule add not fwmark 51820 table 51820
ip rule add table main suppress_prefixlength 0

suppress_prefixlength 0 规则强制忽略主路由表中特定前缀的干扰，确保本地应用程序发出的数据报文无条件进入安全隧道表处理。

3. 在客户端中禁用 Option 121 协商

在缺少命名空间特性的桌面系统中，可在DHCP客户端配置（如 /etc/dhcp/dhclient.conf）中剔除 rfc3442-classless-static-routes 请求项，拒绝接收公共接入点推送的静态路由。

4. RiceGuard 协议的底层过滤机制

VPNRice的RiceGuard协议在操作系统内核驱动层实施严格的流量门禁。借助内核级nftables与eBPF过滤挂钩，RiceGuard确立了单向受控规则：任何未经加密且目标非本地私有网段的报文若尝试脱离物理接口外发，均会被底层过滤引擎直接丢弃，从根本上化解恶意DHCP诱导。

公共网络安全操作守则

排查系统活动路由表： 接入不可信网络后，在终端执行 ip route show（Linux）或 route print（Windows），检查是否存在反常的 /1 静态路由。
优先选用个人移动热点： 在处理高敏感事务时，优先通过蜂窝移动网络连接，避免在未经认证的开放式Wi-Fi网络中暴露DHCP请求。
定期验证真实出口IP： 保持定期使用网络诊断命令（如 curl https://ipinfo.io）核验公网出口节点，确保数据传输始终受到端到端通道保护。