TunnelCrack 与 TunnelVision：各自究竟破坏了什么

两个研究名称常被混用，用来指代任何离开隧道的 VPN 流量，但它们背后的机制并不相同。TunnelCrack 描述两类路由例外；TunnelVision 描述端点由 DHCP 下发的路由。两者都不破坏加密，也都不能告诉你某个具体客户端构建今天会怎么做。五项核查可以把机制与标题区分开。

第一步：说清你在审查哪个机制

2023 年八月公布的 TunnelCrack 描述了两类攻击。在本地网络情形下，被客户端视为本地网络流量的数据会走本地访问例外而离开隧道。在服务器地址情形下，客户端为到达 VPN 服务器本身所需的路径位于隧道之外，而控制该地址的对手可以利用这一例外。

TunnelVision 是关于 DHCP 下发的无分类静态路由的另一份报告。恶意 DHCP 服务器可以给端点下发改变流量走向的路由，其中也包括通往 VPN 服务器的路径。该报告承认了此前关于相关路由效果的研究，这提醒我们：底层机制比名字更古老。

把名字与其机制绑定。因为另一个上了新闻就为其中一个打补丁，正是审查产生动作却没有覆盖面的方式。

第二步：看本地访问例外

多数客户端会豁免本地网络流量，以便在隧道开启时打印机、投屏和文件共享继续可用。这项例外是一项带有安全成本的政策决定：同一网络中的对手可以把自己伪装成本地主机，而到达它的流量从未进入隧道。

要问部署的配置文件是否真的需要这项例外。从不使用本地发现的远程团队往往可以关掉它，其余本地服务可以改走有文档记录的路径。在确实需要例外的地方，应说明它覆盖哪些目标，而不是笼统地称其为本地流量。

核查是配置问题，不是抓包。要读配置文件设置以及你所部署构建的客户端文档，因为默认值在不同产品之间、同一产品的不同版本之间并不相同。把答案写在配置文件旁边，下一位审查者就不必从行为反推。没有人记录过的例外，就是没有人审查的例外。

第三步：看服务器地址是如何学到的

客户端必须在任何隧道存在之前到达 VPN 服务器，因此该目标按设计走在隧道之外。如果地址是从名称学来的，解析步骤就是信任路径的一部分，能应答该查询的对手就能把客户端指向自己控制的主机。

固定地址、使用名称正确的已验证证书，以及拒绝回退到未验证的服务器，都能降低暴露面。这些做法都不能取消在隧道之外到达服务器的需要；它们改变的是谁能对该地址负责。

resolvectl query vpn.lab.example
ip route get 198.51.100.24
ip rule show

路由查询会显示客户端为服务器地址将使用的接口，这就是例外的具体形态。如果该查询返回隧道接口，客户端根本无法建立隧道，所以外部路由是预期之中的，问题只在于它的目标如何选择。

第四步：看 DHCP 下发的路由

无分类静态路由让 DHCP 服务器可以下发路由表条目，端点通常会不加询问地接受。在对手能比合法服务器更快应答 DHCP 的网络里，这些条目可能把用户以为在隧道内的流量改道。

把端点上的路由与你预期的路由做比较。隧道开启时指向本地网关的默认路由或宽前缀，就是值得调查的特征，而且无需任何攻击流量即可看到。

ip route show table all
ip route get 203.0.113.55
nmcli -g ipv4.ignore-auto-routes con show "Wired connection 1"

最后一项设置是许多客户端和平台以某种形式提供的端点侧控制：忽略网络下发的路由。关闭自动接受路由是一种取舍，因为它也会关闭企业 DHCP 服务器提供的合法分流路由，所以应按网络类别而非全局来决定。

第五步：把公告与当前构建分开

已公布的攻击描述的是在特定时间、特定客户端版本上观察到的行为。它并不能证明你面前的笔记本受到影响，也不能证明它已被修复。两种说法都需要实际的构建号以及厂商当前的公告。

记录客户端版本、平台、控制上述例外的配置文件设置，以及你核查的日期。那份记录会诚实地变旧，而一句“VPN 已针对 TunnelCrack 打补丁”的备注不会。每次客户端更新时都要重读它，因为你没有改动的版本也可能改变配置默认值。

真正验证时，请用经批准的方案针对你自己的端点和无害目标。在共享网络上对他人复现该攻击不是测试，而为了让观察更容易去关闭对端验证或应用加密，等于卸掉了你想衡量的保护。

最后，要把应用层保护留在画面里。路由例外可能暴露本应由隧道承载的流量，而 应用层 TLS 仍然端到端保护这些流量。两层各自独立失效，所以一个已连接的控制通道并不能证明每条流都走了预期路径。