这是我的网络拓扑：
我在 上启用了路由和远程访问服务 (RRAS) ，将其用作路由器。当我在 上DESKTOP执行时，一切顺利（顺便说一句：我在 Windows 防火墙管理器中允许了 ICMPv4）。但是当我在 上执行时，它失败并报告“无回复”。ping 192.168.43.188WSL2ping 172.31.24.203LAPTOP
于是我开始调查这里出了什么问题。我检查了路由表，没有什么可疑之处。然后我使用 wireshark 捕获经过的数据包，结果172.31.16.1如下192.168.43.107：
从截图中可以看出，WSL2 确实发送了回复，但192.168.43.107在发送到 时， IP 数据包的源地址被更改为LAPTOP。换句话说，IP 源在某处被伪造DESKTOP。
怎么会这样？这没有意义，还是有道理？这是 WSL2 的 bug 还是 Windows 的 bug，还是我的设置有问题？
答案1
因此，如果我理解正确的话，RRAS 是否正在为 WSL2 接口路由流量？否则，正常情况下，笔记本电脑根本看不到网络172.31.16.1/20，我想是的。
如果是这种情况，那么在我看来，问题在于 WSL2 交换机不知道该路由，并且仍然执行正常的 NAT，将传出的源地址更改为 Windows 接口的地址。同样，正如 @DanielB 和 @harrymc 指出的那样，这是正常的。
理论上，有一种方法可以禁用它，但据我所知，该方法需要 Windows 11，因此它不适用于 Windows Server。不过，我将在下面介绍它作为一种选项。
将流量从本地网络路由到 WSL2 有几种可能性：
RRAS 的可能性
我把这当作一种可能性，但我真的不知道它是否会起作用。考虑到 RRAS 的路由器和 VPN 功能，可能有一种方法可以将其配置为“修复”从 WSL2 接口接收的数据包的源地址。我已经有一段时间没戴 NAT 思考帽了，所以我需要在壁橱里找到它才能对此有更高的信心。
WSL1
此选项以及其余选项均取自我的 Ask Ubuntu 答案关于相关主题。它们不一定修复“路由所有 WSL2 流量”问题，而是根据应用程序/端口采取行动（当然，除了最后一个）。
对于大多数此类网络用例，WSL1 可能是更好的选择。虽然它不一定能解决ping用例问题，但在 WSL1 下运行的网络应用程序/服务正在视窗网络本身，因此不需要 NAT。
SSH 反向隧道
此外，对于单个应用程序/端口（而不是整个接口），您可以使用从 WSL2 到 Windows 主机的 SSH 连接。我不会在这里重复这些步骤，但会向您指出原始答案。
Windows 端口转发
@harrymc 指向 Microsoft 文档，其中推荐 Windows 端口转发。这当然是一种选择，但问题是，由于 WSL2 虚拟交换机地址在每次重新启动时都会发生变化，因此您必须不断删除并重新添加转发规则。文档中没有提到这个警告。
即使动态地址发生变化，上述 SSH 解决方案也始终有效。
具有桥接网络的 WSL2 预览版
这几乎肯定会起作用，并禁用 NAT，但您无法在 Windows Server 上执行此操作，我假设您正在使用 RRAS。它目前只能安装在 Windows 11 上，因为它是具有 WSLg 支持的最新主线。
安装 WSL2 预览版（可以从 Microsoft Store 安装，也可以直接从WSL Github 仓库），您可以关注这篇博文（不是我的）有关如何启用桥接网络的说明。
答案2
IP 地址并非由 DESKTOP 伪造，它只是按设计运行。
以下是一些注意事项：
地址段
172.31.16.X和192.168.43.X是不相交的。正常情况下，消息无法从一个地址段传递到另一个地址段。WSL2 使用主机适配器连接网络，因此来自它的任何消息实际上都来自 DESKTOP。如果没有此 IP 地址，其他设备将无法应答来自 DESKTOP 的任何消息。
WSL2 需要支持多个实例/发行版并行运行的情况，并能够区分它们。为此，WSL2 为每个实例/发行版分配一个
172.31.16.X段内的虚拟 IP，并在通过网络发送消息时进行所需的转换。这称为 网络地址转换 (NAT)。
您看到的是正常的，也是唯一可行的方法。从外部来看，您的 WSL2 发行版只是 DESKTOP，没有其他内容。
如果您使用 RRAS 在中间添加了另一个 NAT，则不能指望能够从外部访问 WSL2 特定的 IP。WSL2 使其 NAT 能够从外部寻址应用程序，尽管有一些限制。在中间添加另一个 NAT 只会破坏一切，
也可以看看 使用 WSL 访问网络应用程序。