许多用户通常假定，只要安全网络连接处于激活状态，底层的密码学套件就能抵御所有外部窥探。现代加密算法如 ChaCha20-Poly1305 和 AES-256-GCM 确实在数学层面上保护了物理介质上的数据完整性。然而，加密协议本身从不决定数据包流向何处。决定数据包传输出口的核心机构，始终是操作系统内核中的路由表。

2023 年，安全研究员 Mathy Vanhoef、Nian Xue、Yashaswi Malla、Zihang Xiao 和 Cristina Nita-Rotaru 披露了一项影响深远的底层架构漏洞：TunnelCrack。该漏洞被分配为 CVE-2023-36664 与 CVE-2023-35838，揭示了不可信的本地局域网或恶意无线热点如何通过操纵系统路由规则，使敏感通信脱离安全隧道，以明文形式向外暴露。

要深入理解 TunnelCrack 的攻击逻辑，必须分别剖析其两大核心衍生形态：LocalNet 攻击与 ServerIP 攻击。

+-----------------------------------------------------------------------------+
|                     TUNNELCRACK LOCALNET 路由泄露数据流                     |
|                                                                             |
|  [受害者客户端设备]                                                         |
|         │                                                                   |
|         ├── 访问目标：公共服务 IP（例如：142.250.190.46）                   |
|         │                                                                   |
|         ▼                                                                   |
|  [内核路由判定流程]                                                         |
|         │                                                                   |
|         ├─► 路径 A：默认加密隧道（0.0.0.0/1 经由 utun0）                    |
|         │                                                                   |
|         └─► 路径 B：恶意 LocalNet 本地子网（142.250.0.0/16 经由 wlan0）     |
|                    （最长前缀匹配 Longest Prefix Match 优先判定）           |
|                                                                             |
|         ▼                                                                   |
|  [物理网络接口：wlan0] ──────────────────────► [恶意无线路由器]             |
|  （未加密的以太网数据帧脱离隧道外泄）          （攻击者监听记录明文）       |
+-----------------------------------------------------------------------------+

LocalNet 攻击（CVE-2023-36664）：利用局域网路由例外机制

LocalNet 漏洞根植于多数网络客户端为了便利性而保留的“允许局域网访问”功能。在家庭或企业环境中，用户在接入安全隧道的同时，往往需要访问局域网内的网络打印机、私有 NAS 存储或智能物联设备。为此，操作系统内核会为本地子网保持链路级直接路由。

当设备连接到 Wi-Fi 热点时，DHCP 服务器会下发 IP 地址、子网掩码与网关。通常情况下，网络会分配 RFC 1918 私网网段，如 192.168.1.0/24。内核随后自动安装一条链路作用域路由：

192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.105

这条链路路由告知内核，发往 192.168.1.0/24 的数据包无需经过默认网关，可直接在物理网卡上通过底层地址解析协议发送。客户端软件为了保持局域网可用性，通常会保留该路由或将其加入例外放行名单。

攻击者控制的恶意热点便利用此机制，向受害者通告一个广阔的公共 IP 地址段作为“本地网络”。例如，恶意 DHCP 服务器为客户端分配属于 142.250.0.0/16 的 IP 并配置 255.255.0.0 掩码：

# 内核在物理无线网卡上误装了指向公网网段的直连链路路由
142.250.0.0/16 dev wlan0 proto kernel scope link src 142.250.10.45

当受害者发起针对该公网网段内服务的连接时，操作系统内核查找转发信息库（FIB）。按照标准 IP 路由解析规则：

  1. 虚拟网络接口通常配置两条覆盖全网的 /1 默认前缀（0.0.0.0/1 与 128.0.0.0/1）。
  2. 恶意本地子网路由具有 /16 的前缀长度，其精确度远高于 /1。
  3. 根据最长前缀匹配原则，内核将优先选择精确度更高的 /16 物理网卡链路。

这一决策导致未加密的 IP 数据包直接被发送至物理接口 wlan0。原本的加密隧道未被调用，恶意热点得以无感知拦截传输中的明文内容。

ServerIP 攻击（CVE-2023-35838）：利用服务器网关连接特性

如果说 LocalNet 是滥用子网声明，那么 ServerIP 攻击则是针对安全网络协议自身的连接引导机制发起的定向诱导。

为了通过互联网与远程网关建立加密通信，物理网络接口必须知道如何抵达该网关服务器的公网 IP。如果客户端盲目将所有出站数据包直接导向自身的虚拟接口，发送往网关的封装流量将会被再次塞入虚拟通道，引发异常死循环并造成通信中断。

为了防止这种递归错误，客户端必须在激活虚拟接口前，在内核路由表中增加一条指向外部物理网关的特定主机路由（IPv4 为 /32，IPv6 为 /128）：

# 为直连远程网关而预先设定的物理主机路由
198.51.100.50/32 via 192.168.1.1 dev wlan0

ServerIP 漏洞发生的诱因在于：客户端在建立连接阶段，如果使用本地网络提供的不可信 DNS 服务解析服务器域名，便会引入严重安全风险：

  1. 客户端在发起连接时，向本地网络发起网关域名解析请求。
  2. 局域网内的假冒 DNS 服务器返回攻击者希望窃听的特定目标服务器 IP。
  3. 客户端误将该目标 IP 视为合法服务节点，并为其在物理接口上配置 /32 直连放行路由。
  4. 尽管针对该假冒节点的握手随后可能失败，但该目标 IP 的物理放行规则已被固化在系统中，导致后续发往该目标的流量脱离加密保护。

即使客户端采用固定 IP 地址连接，攻击者亦可通过在本地污染其他公共网站的 DNS 记录使其指向该服务器 IP，从而促使发往这些网站的通信脱离安全通道。

+-----------------------------------------------------------------------------+
|                      LOCALNET 与 SERVERIP 攻击机制对比                      |
+------------------------+----------------------------------------------------+
| 攻击类型               | 核心诱发机制                                       |
+------------------------+----------------------------------------------------+
| LocalNet               | 恶意 DHCP 声明广域公共 IP 子网掩码                 |
| (CVE-2023-36664)       | 最长前缀匹配覆盖虚拟接口的 /1 默认路由             |
|                        | 滥用客户端保留的“允许局域网访问”功能               |
+------------------------+----------------------------------------------------+
| ServerIP               | 在连接初始化阶段伪造域名解析响应                   |
| (CVE-2023-35838)       | 系统的 /32 主机路由使目标流量直接发往外部接口      |
|                        | 针对防范路由递归机制的针对性利用                   |
+------------------------+----------------------------------------------------+

TunnelCrack 与 TunnelVision 的机制差异

理解 TunnelCrack 时，必须将其与 TunnelVision（CVE-2024-3661）清晰区分。尽管二者都利用了操作系统路由判定逻辑，但实现路径截然不同：

  • TunnelVision 严重依赖 DHCP Option 121（RFC 3442 无类别静态路由选项）来推送静态路由条目。对于从底层就不解析 Option 121 的系统（如标准 Android），TunnelVision 无法生效。
  • TunnelCrack 不需要任何可选 DHCP 扩展参数。其 LocalNet 变种依靠自 1997 年 RFC 2132 就已标准化的基础子网掩码字段。由于所有网络设备都必须解析子网掩码，TunnelCrack 广泛波及 iOS、macOS、Windows、Linux 以及 Android。

路由系统仅依照掩码长度执行最长匹配，并不具备自动校验加密意图的能力。一旦物理接口匹配到更精确的前缀，数据便会直接脱离安全通道发送。

操作系统内核路由查找优先级层级：
┌────────────────────────────────────────────────────────┐
│  主机路由 (/32)：特定目标服务器 (ServerIP)             │  ◄── 最高优先级
├────────────────────────────────────────────────────────┤
│  本地子网路由 (/16, /24)：本地链路网段 (LocalNet)       │  ◄── 高于默认隧道
├────────────────────────────────────────────────────────┤
│  虚拟专网拆分路由 (/1)：0.0.0.0/1 与 128.0.0.0/1       │  ◄── 标准加密通道
├────────────────────────────────────────────────────────┤
│  默认网关路由 (/0)：0.0.0.0/0                          │  ◄── 最低优先级
└────────────────────────────────────────────────────────┘

体系化防御：现代通信架构如何根治路由风险

要彻底免疫 TunnelCrack，单纯在路由表内修补已显不足。前沿的安全架构通过内核级数据包过滤、网络命名空间及套接字设备绑定实现纵深防御。

1. 内核级防火墙规则与强制断网保护

可靠的断网保护（Kill Switch）绝不能只依赖路由表优先级配置，而应在内核协议栈中部署强硬的数据包过滤规则，确保除合法的加密握手端口外，物理接口丢弃所有未封装的数据包。

在 Linux 平台使用 nftables 时，可实施严格的出站流量限定策略：

# 物理接口严格限制为仅允许通往合法服务器的已封装 UDP 流量
table inet vpn_filter {
    chain output {
        type filter hook output priority 0; policy drop;

        # 放行本地回环与虚拟加密接口
        oifname "lo" accept
        oifname "rice0" accept

        # 仅允许发往指定网关的加密封装数据通过物理网卡
        oifname "wlan0" udp dport 51820 ip daddr 203.0.113.10 accept
    }
}

在 Windows 系统中，基于 Windows Filtering Platform（WFP）在传输层驱动中直接拦截未加密数据；在 macOS 上，则依托 pf 规则锚点，强制禁止非虚拟通道接口处理常规应用通信。

2. 在公共网络环境中主动禁用局域网共享

由于 LocalNet 攻击直接依赖局域网例外规则，安全的客户端在接入开放的外部网络时，应主动关闭局域网访问特权：

  • 清理链路作用域的直接路由。
  • 将除本机环回以外的所有流量无差别导入加密通道。
  • 即便恶意 DHCP 下发了异常的 /8 大子网，防火墙规则也会直接阻断直接物理投递。

3. 网络命名空间与 SO_BINDTODEVICE 绑定

在 Linux 与 Android 环境下，网络命名空间提供了物理隔离手段。通过将物理无线网卡置于专用的隔离网络命名空间，而将用户态应用程序保留在仅包含虚拟通道的主命名空间中，应用程序在物理层面就无法检索到外部 Wi-Fi 的路由节点。

对于单一进程，开发者还可通过套接字选项直接绑定虚拟设备：

// 强制应用程序套接字直接绑定到虚拟网卡
setsockopt(sock_fd, SOL_SOCKET, SO_BINDTODEVICE, "rice0", strlen("rice0"));

当套接字明确绑定到特定网络接口后，内核将忽略全局路由表的最长前缀判定，确保数据流只从安全通道输出。

验证设备防御能力的实操步骤

系统管理员与关注通信安全的用户可依照以下方式排查自身环境：

  1. 审查当前路由表配置： 在连接安全网络前后，检查系统路由表，确认是否存在可疑的链路直连路由或 /32 主机例外：
    ip route show table all
  2. 搭建受控模拟网段： 在测试路由器上配置通过本地 DHCP 下发公网 IP 网段（如 198.51.100.0/24）。接入设备并开启客户端，检测发往 198.51.100.1 的流量是否被正确送入加密隧道或由安全机制丢弃。
  3. 关闭公共 Wi-Fi 下的局域网共享开关： 检查客户端设置，确保在不受信任的公共网络中禁用局域网共享。

VPNRice 客户端在底层深度集成了 RiceGuard 协议与三层内核网络隔离技术，通过严格的接口设备绑定与主动防火墙过滤机制，全面免疫虚假子网与恶意路由条目的干扰。

欢迎前往官方下载中心安装最新版本，获取跨平台的全方位通信安全护航：获取 VPNRice。