这篇部落格文章已经 4 年了，可能已经过时。

WSL2 下的 Linux 可能存在泄漏问题

2020 年 9 月 30 日

我们发现，在 WSL2（Windows Subsystem for Linux 2）下运行 Linux 时，可能会泄漏你的网路流量。

我们的调查显示，这些泄漏也会发生在其他 VPN软体上。尽管我们目前没有解决方案可以提出，但我们觉得有必要引起大家的注意。就在你阅读这篇文章的同时，我们正在针对这个问题寻找解决方案。

最近，我们收到了关于 WSL2 下 Linux 泄漏的报告。我们的调查结论是，Linux 客户端的流量绕过了 Windows 主机上的
WFP（防火墙）的所有正常层级，直接发送到网路中。因此，应用程式在防火墙中的所有封锁措施都被忽略了。

Linux 客户端的网路流量始终会通过主机的预设路由发送，并未经过 WFP 的正常检查。这意味著，如果有一个活跃的 VPN 隧道，Linux客户端的流量将会通过 VPN 传送，并不会泄漏！但是，如果没有活跃的 VPN 隧道，例如在应用程式断开连接、连接中、重新连接或因错误而被阻止的情况下，那么
Linux 客户端的流量将会泄漏到常规网路中，即使启用了「始终需要 VPN」。

泄漏的原因

WSL2 使用 Hyper-V 虚拟网路，而这正是问题所在。Hyper-V虚拟以太网适配器在不让主机防火墙检查数据包的情况下，将流量传递至客户端。因此，转发的（NAT 化的）数据包在 WFP 的低层（OSI 第 2层）仅被视为以太网几框，这种型态的泄漏也可能发生在使用 Hyper-V 作为网路的 Windows Sandbox 或 Docker 客户端。

其他 VPN 软体

我们测试了几款竞争对手的 VPN 客户端，发现它们都以相同的方式泄漏。因此，这并不是 Mullvad VPN特有的问题，而是一个行业普遍存在的问题，并且目前很少有人提出解决方案。微软对 Linux 客户端的虚拟网路实现使得正确保护它们变得非常困难。

警惕

我们目前正在调查如何以及是否能够在 Hyper-V 虚拟交换器上阻止不必要的流量。当我们掌握更多信息时会进一步公布。在此之前，如果你在 WSL2 下使用
Linux，或是在 Hyper-V视讯下运行的其他客户端/容器，请注意，在连接、重新连接的过程中，以及在没有隧道运行的状态下，客户端的流量可能会泄漏。

此问题的历史

这个问题最初是在 2020 年 8 月 12日由一位消息人士报告给我们。在第一次处理时，仅由我们的支援团队负责，但因测试机上的不幸软体组合，他们未能重现这个泄漏。因此，这个问题没有被回报给开发团队。然后，在
2020 年 9 月 17 日，同一位提供资讯的人再次报告此问题，并立即转交给开发团队，他们能够验证这是一个我们应该重视的问题。目前我们正在寻找解决方案。

待续，
Mullvad VPN