翻译：https://www.leviathansecurity.com/blog/tunnelvision

最近，我们发现了一种绕过 VPN 封装的新颖网络技术。攻击者可以使用此技术，利用 DHCP（动态主机配置协议）的内置功能强制目标用户的流量离开其 VPN 隧道。其结果是用户传输的数据包从未经过 VPN 加密，攻击者可以窥探其流量。我们使用术语解除隐形来指代这种效果。重要的是，VPN控制通道得以保持，因此像断开vpn这样的功能从未被触发，我们在所有观察到的案例中用户都继续显示为连接到VPN。

我们花费了大量时间来研究此功能，并尝试通知尽可能多的受影响方。我们还知道，作为安全研究人员，我们有责任向安全社区以及公众通报这一威胁。我们还相信，这项技术早在 2002 年就已经有可能使用这种技术，并且可能已经被发现并在野外使用。因此，我们认为公开披露信息至关重要，因为通知每个 VPN 提供商、操作系统维护者、自托管 VPN 管理员和 VPN 用户远远超出了我们小型研究团队的能力。

我们已经看到了这种技术的缓解方法，并且还确定了在基于Linux的操作系统上存在的一个修复方案。然而，这种缓解措施提供了一个可能被用于针对性拒绝服务审查的侧信道，以及通过流量分析来匿名化流量目的地。在世界上的某一些地方，仅凭这个侧信道就可能导致依赖VPN以确保安全的记者或告密者入狱或死亡，这些人通常是监视或间谍软件的常见目标。

仅通过删除对 DHCP 功能的支持来解决该问题是不可行的，因为这可能会在某些合法情况下中断 Internet 连接。我们最强烈的建议是 VPN 提供商在支持它们的操作系统上实现网络命名空间，类似于 WireGuard 文档中描述的方法。网络命名空间是 Linux 的一项功能，可以将接口和路由表分段，远离本地网络的控制，其他操作系统维护人员应该考虑命名空间是否可行。

为了让尽可能多的人能够接触到这项工作，我们正在构建这篇博文来介绍网络、VPN 技术和 DHCP 的基础知识，以充分解释解密行为。欢迎高级读者直接跳至概念验证部分。

解除隐形入门：底层网络

什么是网络？

计算机网络是由相互连接的计算机设备组成的，它们可以相互发送和接收数据。

这是一个基本的例子：使用以太网电缆将两台笔记本电脑连接起来，使它们组成一个网络。然而，在普通用户看不见的低层次网络中，还有更多的东西。这些笔记本电脑正在使用一套规则进行相互通信，我们称之为协议。每个协议都有自己的目的，并在我们所说的层上运行。

这些层次旨在解决不同类型的问题，并且构建得不需要知道较高层或较低层正在发生什么。这称为封装。例如，用户可以信任低于其浏览器（HTTP）的层次，这些层次决定了如何通过电缆（同轴电缆）发送电力，知道与谁通信（以太网，IP），并确保将数据正确交付给接收服务器（TCP）。这就像某人写信时只需要考虑他们想写什么或对方写了什么。他们不需要关心信件是如何到达的。

当我们在本博客文章中提到层时，我们指的是实际的 TCP/IP 模型，该模型几乎在每台设备和网络上都有实现。我们还决定使用模型的 5 层变体，因为它没有将较低的层合并在一起；这就是为什么在查看其他 TCP/IP 模型图时可能会有差异。当我们提到由所有这些层打包的数据时，我们通常将其称为数据包。

层次	简要描述	类比	协议
Application Layer 应用层	确定应发送给收件人的实际数据。	邮件中一封信的一页上的文字。	HTTP, DNS, HTTPS, DHCP
Transport Layer 传输层	在主机上的进程和接收者上的进程之间建立端到端通信。	一封寄往特定公寓号码的信件。	TCP, UDP
Network Layer 网络层	通过 Internet 将流量从源系统发送到目标系统	向城市中的一栋建筑投递一封信。	IP, ARP
Data Link Layer 数据链路层	控制同一本地网络上的系统之间的流量。	邮局卡车将邮件从一个地方运送到另一个地方或从一个城市运送到另一个城市。	Ethernet
Physical 物理层	确定如何通过“物理介质”（例如铜线或无线电波 (Wi-Fi)）对数据进行编码。	亲手写下这封信并将其放入信封中。	Fiber optic, Coax, Satellite, Microwave（光纤、同轴电缆、卫星、微波）

什么是网络接口？

网络接口最基本的例子是物理设备，如无线网卡或网络卡，它们连接到计算机的主板上。这些设备允许计算机通过物理介质（例如铜线、光纤电缆或无线电频率）传输数据位。它们是网络的基本组成部分，因为它们使计算机能够在一定距离内相互通信。

网络接口有两种类型：

物理网络接口
虚拟网络接口

重要的是，这两种接口都是为了封装而设计的，因此它们可以以相同的方式被更高层交互。
这就是虚拟网络接口发挥作用的地方，它是 VPN 客户端和服务器的关键组件。虚拟网络接口不是使用物理硬件，而是创建一个可以通过软件应用程序读取或写入的文件描述符。由于文件描述符仅存在于主机的内存中，因此虚拟网络接口在虚拟化环境中特别有用，在这些环境中，流量可能永远不需要通过物理介质传输。

图 1：一个虚拟接口的简化示例，该接口没有物理接口支持。虚拟机之间的流量永远不会离开主机。

然而，在某些情况下，用户可能希望虚拟接口能够通过物理介质发送数据。在这些情况下，虚拟接口也可以由物理网络接口支持。在幕后，虚拟接口将出站数据转发到物理网络接口。

图 2：一个由物理接口支持的虚拟接口示例。

什么是VPN

虚拟专用网络（VPN）允许用户在他们的主机设备和不同网络上的服务器之间建立网络流量的隧道。由此产生的虚拟网络不受地理位置的限制，同时与物理网络的行为完全相同。

为了实现这一点，VPN 客户端创建一个虚拟网络接口，并使用底层文件描述符在较高层加密/解密流量，然后再将其发送到物理网络接口。

图 3：一个简化的 VPN 设置，其中 VPN 用户正在访问不同网络上的资源。

VPN 的使用旨在尽可能简化用户操作。通常，用户只需登录并点击一个按钮即可连接到他们的服务器。
用户所做的事情：

选择他们想要的 VPN 客户端
点击一个按钮进行连接
登录（在某些情况下是可选的，取决于客户端）
阅读来自 VPN 的确认信息，确认他们已连接
使用 VPN 的远程资源

重要的是，VPN 实际上增加了主机的攻击面，因为来自较低网络层的流量被发送到互联网上。VPN 通过在较高层内部封装较低层来在互联网上创建局域网（LAN）。局域网流量被认为比旨在发送到互联网的流量更受信任。拥有局域网访问权限的攻击者比局域网外的攻击者有更多的被动和主动攻击选项。通过在互联网上创建局域网，VPN 将局域网攻击面扩展到外部攻击者。通常，VPN 通过使用补偿控制（如数据包加密）来缓解这种攻击面。
这是一个关于 VPN 的经常被误解的事实。加密的原因并不是为了增加使用物理局域网的安全性，而是为了减轻 VPN 在互联网上创建虚拟局域网时引入的额外风险。尽管常见的VPN营销材料和广泛提供的建议都声称如此，但VPN并不能保护您免受物理局域网上本地网络攻击的威胁。

VPN如何使用虚拟网络接口？

VPN 客户端进程创建了数据包的加密版本，该数据包最初是从与其虚拟网络接口关联的文件描述符接收的。它将这个加密的有效载荷放置在其底层 VPN 协议的层中，然后使用该协议与 VPN 服务器通信。

VPN 发送数据包到 VPN 服务器的整个过程相当复杂。这里给出详细的步骤列表，供安全研究人员或开发人员在需要更细致的细节时参考。

应用程序进程将有效负载发送到它创建的套接字。
套接字将有效负载格式化为数据包并将其发送到路由表以确定应通过哪个接口发送。
路由表确定数据包应通过 tun0 发送。
路由表将数据包发送到防火墙。
防火墙规则允许数据包继续发送至 tun0。
网络接口序列化数据包并将其写入用户态 /dev/net/tun 处的文件描述符中。
VPN 客户端进程读取文件描述符中数据包的未加密原始字节。
VPN 进程创建加密的有效负载并将其发送到 VPN 制作的套接字。
套接字将有效负载格式化为绑定到 VPN 服务器的数据包，并将其发送到路由表以确定应通过哪个接口发送。
路由表确定数据包必须通过 wlan0 接口发送。
路由表将数据包发送到防火墙。
防火墙规则确定出站数据包可以继续使用 wlan0。
网络接口将数据包传输到其 Wi-Fi 驱动程序。
Wi-Fi 驱动程序将 VPN 绑定数据包发送到物理网络接口卡 (NIC)。
数据包通过 Internet 发送到 VPN 服务器。
VPN 服务器将响应数据包发送回物理 NIC。
NIC将响应数据包发送给Wi-Fi驱动程序。
Wi-Fi 驱动程序将响应数据包发送到 wlan0。
响应数据包被发送到防火墙。
防火墙规则允许数据包继续传输。
数据包返回到 VPN 套接字。
套接字接收数据包并将数据包的加密负载发送到 VPN 客户端进程。
VPN 客户端进程解密有效负载并将响应数据包的未加密原始字节写入文件描述符。
tun0 接口反序列化文件描述符中的字节并将其格式化为数据包。
tun0 接口将数据包发送到防火墙。
防火墙规则允许数据包继续传输。
数据包返回到用户应用程序进程打开的套接字。
数据包中的有效负载将返回到应用程序进程。

图 4：Linux 主机上 VPN 的数据流图。

基于路由的 VPN 如何配置主机？

用户连接到 VPN 服务器后，他们的 VPN 客户端进程将配置主机的设置，以通过其建立的隧道路由流量。如果所有流量都通过 VPN 路由，我们将其称为“全局VPN”。如果存在用户定义的流量例外（例如本地网络流量），我们将其称为“规则VPN”(例如国内ip不走vpn流量）。 VPN 客户端还可以配置主机上的其他设置，例如主机的防火墙。稍后，我们将讨论使用基于主机的防火墙观察到的缓解措施。

通常，这些配置更改是在建立或断开连接时通过“启动脚本”和“关闭脚本”进行的。VPN 客户端的运行时进程也可能执行配置更改，但这因vpn供应商而异。

注意：当我们说“所有流量”时，我们实际上是指“除维持 VPN 正常工作状态所必需的流量之外的所有流量”。例如，VPN 会为其自身先前配置的路由规则创建例外。发送到 VPN 服务器 IP 地址的所有流量必须通过硬件支持的接口发送，而不是通过其自身的隧道发送。否则，它会破坏主机与 VPN 服务器的连接，VPN 客户端将无法发送加密数据包。此外，由于 VPN 必须保持其主机的 IP 地址租约，因此对 DHCP 流量也存在其他配置例外。

什么是路由和路由表？

路由是我们根据目的地描述将流量发送到何处的方式。路由表是网络堆栈使用的路由的集合。将网络堆栈视为操作系统上处理从网络发送和接收数据的所有代码。
一条常见的路由是将所有流量（以无类别域间路由[CIDR]表示法表示的 0.0.0.0/0 ）发送到您的路由器（ 192.168.1.1 ）通过物理网络接口（ eth0 ）。
该规则在表格中的一个例子是：

0.0.0.0/0 via 192.168.1.1 dev eth0

路由表的另一个行为是，在大多数网络堆栈中，默认情况下，CIDR 范围内最具体的前缀长度具有最高优先级。范围 192.168.1.1/32 的前缀长度为 32 ，范围 0.0.0.0/0 的前缀长度为 0 。前缀长度的最高数值将优先用于路由选择（除非另有配置）。
例如：

0.0.0.0/0 via 192.168.1.1 dev eth0
10.10.10.1/24 via 192.168.1.1 dev wifi1
10.10.10.2/32 via 192.168.1.2 dev eth0

在这种情况下，如果我们向 10.10.10.2 发送流量，那么最具体的规则是 /32 规则，因此尽管它与上面的其他两个规则匹配，但网络堆栈将使用该规则。
大多数全隧道 VPN 使用最不具体的规则来捕获所有流量。请注意，以下示例还包括对假设的 VPN 服务器地址（ 12.34.56.78 ）的例外路由。

0.0.0.0/0 via 10.13.37.1 dev tun0
12.34.56.78/32 via 192.168.1.1 dev eth0

另外，提供者可以使用两个 /1 规则来获得对默认路由的优先权。即使在非对抗性环境中，DHCP 通常也会将默认路由设置为物理网关。

0.0.0.0/0 via 192.168.1.1 dev eth0
0.0.0.0/1 via 10.13.37.1 dev tun0
128.0.0.0/1 via 10.13.37.1 dev tun0
12.34.56.78/32 via 192.168.1.1 dev eth0

什么是 DHCP？

DHCP 最初被开发为一种强大的方式，用于动态地向本地网络上的设备分配 IP 地址，而不是手动为每个设备分配地址。所有现代操作系统都有自己的 DHCP 客户端，可以自动请求 IP 地址。
需要理解的主要概念是，DHCP 为 IP 地址提供基于时间的租约，并且它包含许多称为选项的附加功能，允许您远程和动态地调整设备的配置。一些值得注意的选项包括设置默认网关，作为通往互联网的主要路由，或 DNS（域名系统）服务器，它们将域名（如“google.com”）解析为 IP 地址。

一个想要获取 IP 地址的客户端会使用广播发送一个 DHCPDISCOVER 包到整个本地子网。其他主机会忽略这个包，除了服务器会用 DHCPOFFER 单播直接回复客户端，提供一个有时间限制的租约。

或者，如果客户端知道 DHCP 服务器是谁，它可以选择将 DHCPDISCOVER 单播到 DHCP 服务器，而不是广播。通常，这是用于续租其租约。

图 5：DHCP 客户端如何获取 IP 地址并维护其租约。Source: https://docs.oracle.com/cd/E23824_01/html/821-1453/dhcp-overview-3.html
如上图所示，一旦 DHCP 服务器发出一个提供，客户端可以选择接受或拒绝该提供。例如，如果它收到多个提供，它将选择最佳的一个。DHCP 客户端最常实现的选取方式是“先到先得”。未被选中的服务器将从客户端收到一个 DHCPDECLINE 消息。值得注意的是，DHCPOFFER 将包括选项。

DHCP 选项 121 是什么？

在 1997 年，DHCP RFC 中有一个选项 33，它允许网络管理员指定一条静态路由并将其安装到客户端的路由表中。然而，这使用的是基于类的静态路由，随着时间的推移，由于公共 IP 地址空间的限制，这种做法逐渐不再受欢迎。到了 2002 年，RFC 3442 引入了选项 121，即无类静态路由，并使选项 33 变得过时（尽管根据不同的人的观点，它仍然应该得到支持）。选项 121 也允许管理员向客户端的路由表添加静态路由，但是使用的是无类范围。除了数据包大小之外，没有限制可以同时安装多少条不同的路由。
DHCP 选项 121 的一个有趣的特点是，它安装的路由的网络接口设备不能由 DHCP 服务器指定。下面你可以看到在 Wireshark 中捕获的一个 DHCPOFFER 数据包。它指定了 CIDR 范围和要使用的路由器，但没有指定接口设备。

图 6：包含选项 121 路由的 DHCPOFFER 数据包。网络接口未在设计中指定。
相反，在为此选项安装其路由规则时，DHCP 客户端将隐式选择客户端与 DHCP 服务器通信的网络接口。

"解除隐形"攻击

https://www.youtube.com/watch?v=ajsLmZia6UU

解除隐形VPN流量的要求

目标主机必须接受来自攻击者控制的服务器的 DHCP 租约
目标主机的 DHCP 客户端必须实现 DHCP 选项 121

我们想强调的是，与目标用户位于同一网络的攻击者可以通过以下方式成为他们的 DHCP 服务器：

恶意 DHCP 服务器对真正的 DHCP 使用 DHCP 饥饿攻击，然后响应新客户端。我们已经在实验室环境中实现了这一目标，并且正在撰写后续博客文章。
恶意 DHCP 服务器竞相响应 DHCPDISCOVER 广播，滥用 DHCP 客户端实施优先租约选择的常见行为。
ARP 欺骗拦截真正的 DHCP 服务器和客户端之间的流量，然后等待客户端续订其租约。

执行攻击

我们的技术是在与目标 VPN 用户相同的网络上运行 DHCP 服务器，并将我们的 DHCP 配置设置为将其自身用作网关。当流量到达我们的网关时，我们使用 DHCP 服务器上的流量转发规则将流量传递到合法网关，同时监听它。
我们使用 DHCP 选项 121 在 VPN 用户的路由表上设置路由。我们设置的路线是任意的，如果需要我们也可以设置多条路线。通过推送比大多数 VPN 使用的 /0 CIDR 范围更具体的路由，我们可以制定比 VPN 创建的虚拟接口的路由具有更高优先级的路由规则。我们可以设置多个 /1 路由来重新创建大多数VPN设置的 0.0.0.0/0 所有流量规则。
推送路由还意味着网络流量将通过与 DHCP 服务器相同的接口而不是虚拟网络接口发送。这是 RFC 中没有明确说明的预期功能。因此，对于我们推送的路由，它永远不会由 VPN 的虚拟接口加密，而是由与 DHCP 服务器通信的网络接口传输。作为攻击者，我们可以选择哪些 IP 地址通过隧道，哪些地址通过网络接口与我们的 DHCP 服务器通信。

图 7：恶意 DHCP 选项 121 路由导致流量永远不会被 VPN 进程加密。
我们现在有流量在 VPN 的加密隧道之外传输。一旦 VPN 用户的主机需要从我们的 DHCP 服务器续订租约，该技术也可以用于已建立的 VPN 连接。我们可以通过在 DHCP 租约中设置较短的租约时间来人为地创建这种情况，以便用户更频繁地更新其路由表。此外，VPN 控制通道仍然完好无损，因为它已经使用物理接口进行通信。在我们的测试中，VPN 始终继续报告为已连接，并且终止开关从未用于断开我们的 VPN 连接。

POC

概念视频证明：
https://www.youtube.com/watch?v=ajsLmZia6UU
实验室设置代码：
https://github.com/leviathansecurity/TunnelVision
DHCP 服务器镜像：
https://drive.google.com/file/d/1WLJGs3ZUypf6hLh5WL4AJmsKdUOZo5yZ

实验室场景的构建是为了代表：

攻击者破坏 DHCP 服务器/接入点
流氓管理员本身拥有基础设施并对其进行恶意配置
攻击者在咖啡店或公司办公室等物理位置设置邪恶双向无线 AP
我们发布了我们的工具 ArcaneTrickster，该实验室还可以用来模仿在网络上拥有相邻主机的攻击者，否则不处于特权网络位置

修复

网络命名空间

在 Linux 上使用网络命名空间可以完全解决此问题。然而，根据我们的经验，它的实施较少。
WireGuard 的文档展示了如何为所有应使用 VPN 的流量的应用程序使用命名空间，然后再将其发送到包含物理接口的另一个命名空间。然而，这似乎是 Linux 特有的功能，目前尚不清楚是否有针对 Windows、MacOS 或其他操作系统的具有相同鲁棒性的解决方案。

缓解措施

防火墙规则

我们观察到 VPN 提供商通过防火墙规则拒绝所有进出物理接口的入站和出站流量。 DHCP 和 VPN 服务器 IP 需要例外，因为它们需要保持与 LAN 和 VPN 服务器的连接。深度数据包检查也可以仅允许 DHCP 和 VPN 协议，但可能会导致性能损失。

防火墙规则缓解问题

防火墙缓解措施会使用 DHCP 路由对流量创建选择性拒绝服务并引入旁路。攻击者可以使用此旁路来确定流量的目的地。为了确定流量的目的地，攻击者可以对用户发送的 VPN 加密流量进行流量分析。攻击者需要没有安装恶意软件的基准流量。然后，攻击者需要修改租约配置以安装拒绝流量的路由并观察流量差异。
有了足够的样本，就可以统计证明目标用户是否正在将流量发送到特定目的地。对于普通互联网用户来说，大多数互联网流量已经受到 TLS 的保护。因此，TunnelVision 截获的流量除了目的地和协议之外，大部分都无法读取。这意味着这个侧通道具有几乎相同的影响，并且应该被认为是不够的。

侧通道使用灵活：

可以根据预定义的列表检查流量。
作为一种审查机制，可以选择性地拒绝流量。
攻击者可以使用二分查找的IP空间拒绝（acl?）方法，在对数时间内确定所有当前连接。

忽略选项 121

另一种可能的缓解措施是在 VPN 开启时忽略选项 121。我们注意到，由于 Android 没有实现对 DHCP 选项 121 的支持，因此它没有受到影响。缺点是选项 121 的存在是有原因的，忽略这些路由可能会破坏网络连接（这经常被作为在 Android 上实现它的原因提出）。如果实施此缓解措施，则必须是强制性的，因为攻击者可以简单地拒绝网络访问，直到 VPN 或用户重新启用选项 121。

使用热点或虚拟机

热点是由蜂窝设备控制的临时 Wi-Fi 网络。他们创建了一个具有自动网络地址转换功能的密码锁定 LAN。由于该网络完全由蜂窝设备控制并且需要密码，因此攻击者不应具有本地网络访问权限。只要虚拟机的网络适配器不处于桥接模式，虚拟机也会以类似的方式工作。

如果您需要绝对保密您的流量，请勿使用不受信任的网络

行业影响

TunnelVision 是漏洞吗？

这是有争议的。我们称其为一种技术，因为 TunnelVision 不依赖于违反底层技术的任何安全属性。从我们的角度来看，TunnelVision 是 DHCP、路由表和 VPN 的工作方式。
然而，它与营销材料中常见的 VPN 提供商的保证相矛盾；我们认为，当 VPN 提供商保证其产品能够保护客户免受不可信网络上的攻击者侵害时，TunnelVision 就成为一个漏洞。保护传输中的数据和防御所有 LAN 攻击之间存在很大差异。 VPN 的设计初衷并不是为了减轻物理网络上的 LAN 攻击，否则是危险的。
在我们的技术中，我们没有破坏 VPN 的加密安全协议，并且 VPN 仍然具有完整的功能。相反，攻击者会强制目标用户不使用其 VPN 隧道。无论我们是否将其归类为一种技术，当 VPN 用户依赖 VPN 可以保护他们免受本地网络攻击者的侵害时，他们就会受到影响。

受影响的操作系统

在我们的测试中，我们观察到任何根据 RFC 规范实现 DHCP 客户端并支持 DHCP 选项 121 路由的操作系统都会受到影响。这包括 Windows、Linux、iOS 和 MacOS。值得注意的是，它不会影响 Android，因为它们不支持 DHCP 选项 121。

受影响的 VPN 提供商和 VPN 协议

我们发现仅依靠路由规则来保护主机流量的 VPN 很容易受到攻击。那些托管自己的 VPN 服务器（例如系统管理员）并且没有强化其 VPN 客户端配置的人也可能容易受到攻击。我们观察到一些 VPN 提供商采取了缓解措施，通过防火墙规则丢弃流向非 VPN 接口的流量。可能还有我们在测试过程中没有遇到的其他方法来缓解或修复此问题。
如前所述，我们在测试的每个操作系统上都观察到相同的行为，除了一个。此外，VPN 使用的加密算法的强度也没有影响。 TunnelVision 的效果独立于底层 VPN 协议（例如 WireGuard、OpenVPN 或 IPsec），因为它重新配置 VPN 所依赖的操作系统网络堆栈。

结论

作为一个由两人组成的研究团队，我们有一个限制——市场上的 VPN 太多，无法单独测试每一个。我们采取的第一种方法是通过错误赏金或安全披露电子邮件通知公司，但这很快就变得无法扩展。在公开发布这项研究之前，我们还与 EFF 和 CISA 合作，帮助尽可能广泛地披露信息。我们非常感谢他们的帮助。我们希望通过发表我们的工作，能够接触到更多受影响的各方，特别是因为我们相信这项技术早在 2002 年就已经可行。

尽管这项技术的公开披露对各方的影响不同，但最终还是有共同的责任。
应让用户了解这种技术，并且对于敏感流量，应警告他们不要使用不受信任的网络。如果他们必须使用不受信任的网络，则应使用能够有效缓解此技术的 VPN 提供商。为了确定提供商是否有有效的缓解措施或修复措施，我们的实验室设置可用于测试，并且 VPN 提供商本身将能够在其文档中详细说明其现有缓解措施。如果 VPN 解密确实发生，则本地网络攻击者将看不到大多数用户数据，假设他们使用 HTTPS 访问网站，而 HTTPS 已变得越来越普遍。
企业 VPN 通常用于咖啡店、酒店或机场等区域。网络管理员应告知员工，在这些地方工作存在风险，应尽可能避免。如果这样的策略不切实际，那么管理员应建议使用能够实现前面提到的缓解措施或修复的 VPN。一些替代方案是使用受信任的热点，然后连接到 VPN。最后，在从虚拟化 DHCP 服务器获取租约的虚拟机内部运行 VPN 将阻止本地网络 DHCP 服务器完全安装路由。
控制自己网络或拥有站点到站点 VPN 的公司应检查他们使用的交换机并启用 DHCP 监听和 ARP 保护等功能。这些第 2 层保护有助于防止恶意 DHCP 服务器，但不能消除恶意管理员情况。此外，对内部资源实施HTTPS或其他加密协议将防止来自不可信网络连接的VPN用户的数据泄露。
VPN 提供商可以向客户端添加功能来配置防火墙规则，以丢弃到网络接口的出站数据包。然而，这样的设置将意味着 VPN 用户将无法与本地网络资源进行交互。如果 VPN 客户端适用于 Linux 并且打算成为完整隧道，请使用网络命名空间进行隔离。因此，VPN 提供商应公开提供有关他们针对 TunnelVision 采取的任何缓解措施或修复措施的文档，并警告其最终用户有关 TunnelVision 的存在。我们还建议审查他们的营销材料，并停止声称 VPN 可以保护不受信任网络上的客户的营销声明，直到得到证实。
操作系统维护者（Linux 之外）应确定添加或增强与网络命名空间相关的功能是否可行。

即将进行的研究

在披露过程中，我们遇到了多个案例，但我们披露的实体并不认为这是一个严重问题。他们假设先决条件包括特权地位或帐户，尽管唯一的先决条件是本地网络访问。这种假设部分是由于我们故意简化了实验室设置，我们是唯一的 DHCP 服务器，并且我们认为该实体对低级网络缺乏熟悉。
根据这些反馈，我们决定开发一个强大的对抗性基础设施库，以实现进一步的 LAN 安全研究并演示实际攻击。例如，我们可以证明，只要与同一 LAN 上的目标主机相邻，就可以一致地执行 TunnelVision。我们将其称为“ArcaneTrickster”，并计划稍后发布。不过，我们在视频中提供了演示，可在概念验证部分中找到。