我正在尝试学习网络，但我还是个新手。我对虚拟适配器和我的 wifi 卡之间的路由方式感到困惑
当我从 WSL ping google.com 时，我可以在我的 WSL 虚拟适配器上的 Wireshark 上看到请求从 172.30.85.15（我的 WSL 虚拟适配器）到 142.250.178.131（google.com）
Wireshark => WSL 适配器：
当监控我的无线网卡时，我还可以看到我的请求从我的无线网卡适配器（192.168.157.57）到 142.250.178.131。
线框 => WiFi 卡：
我猜这是由于 Windows 路由表造成的：
，请求首先通过 WSL 虚拟适配器，然后转发到我的 192.168.157.57 接口，然后请求以 192.168.157.57 作为“来源”
然后，当响应返回时，它会转到 192.168.157.57，这就是我感到困惑的地方。我知道不知何故使用了 172.30.95.255 路由，但如果响应的最终目的地（如 wireshark 中的目的地字段中所述）针对我的 wifi 卡，那么响应究竟是如何从 192.168.157.57 转到 172.30.95.255 的？我没有看到任何数据包从我的 wifi 卡转到我的虚拟适配器。
我不明白这是如何工作的，如果我尝试删除 172.30.xx 路由，它就会停止工作，这意味着它们正在被使用。
答案1
它的工作方式与家用路由器相同。使用默认的 vSwitch 配置WSL2 创建的，你的主机操作系统实际上变成了一个路由器具有状态 NAT 功能– NAT 是因为它还会重写（转换）出站数据包上的 IP 地址，从而隐藏 WSL 网络；状态 是因为它跟踪通过它的所有流（例如 TCP 连接），从而允许它自动对入站回复数据包执行相反的转换。
也就是说，当你从 WSL 发送初始 ICMP 数据包（或者更典型的例子是 UDP 数据包）时，Hyper-V NAT 功能会记住它刚刚执行的映射：
| 类型 | 原始来源 | 原目的地 | 预期答复来源 | 预期答复目的地 |
|---|---|---|---|---|
| ICMP | 172.30.85.15 | 142.250.178.131 | 142.250.178.131 | 192.168.157.57 |
| TCP | 172.30.85.15:23456 | 8.8.8.8:53 | 8.8.8.8:53 | 192.168.157.57:34567 |
这样，当收到回复时，它会查找匹配的“预期回复”字段并恢复原始的源/目标字段（只因为它是回复而交换）前路由数据包，因此在“这是一个本地地址吗”检查之前。
（这是一个简化的例子。状态表中通常包含更多信息，例如，不同的 ICMP“ping”通过其 ID 进行跟踪，而不同的 TCP 或 UDP 流通过端口号进行跟踪；当然，还有清理过期条目的超时时间。）
用于Get-NetNatSession查看 Windows 上的 Hyper-V NAT 状态（或conntrack -L查看 Linux 上的 iptables/nftables 状态）。该示例仿照 conntrack 建模，但 Hyper-V NAT 中的字段类似。