☰

通过 WireGuard VPN 从一个子网连接到另一个子网时，为什么 TCP 需要两侧的 NAT，而 ICMP 却不需要 NAT 就可以工作？

tag-icon • tag-icon networking nat tcp icmp
通过 WireGuard VPN 从一个子网连接到另一个子网时，为什么 TCP 需要两侧的 NAT，而 ICMP 却不需要 NAT 就可以工作？

我今天在以下设置中遇到了这个问题：

[Cloud Server] --> [Cloud Gateway Server] <- WireGuard -> [Home Router] <-- [Home Device]
  • 我的路由器上有源 NAT。我的家用设备可以通过 SSH 连接到我的云服务器。
  • 我的云网关服务器上没有 NAT。网关上的路由表正确，并且已设置 iptables 来转发数据包。

我注意到，从网关后面的云服务器，我可以 ping 我的家庭设备，但无法建立 SSH 连接。在云网关上设置源 NAT 后，对于从云子网转发的数据包，一切正常。

我的问题是，为什么云网关需要 NAT？这与家庭设备的数据包经过 NAT 有什么关系吗？还是云子网、家庭子网和 WireGuard 子网共享不同的 IP 范围这一事实存在一些根本限制？

我对数据包的处理方式进行了一些模拟，但找不到问题所在。我不得不承认，我对网络的理解主要来自维基百科和谷歌搜索。如果可能的话，我正在寻找一些理论解释。提前致谢！

更新：

为了更好地描述该场景，我有以下设备：

  • 云端的服务器，有IP 172.16.0.2。
  • 云端的WireGuard网关服务器，具有云IP172.16.0.3和WireGuard IP 192.168.0.1。
  • 办公室路由器、IP10.0.0.1和 WireGuard IP 192.168.0.2。
  • 办公设备，IP 10.0.0.2。

还有一个172.16.0.1我无法访问的云网关。我已为 和 都设置了路由192.168.0.0/24，10.0.0.0/24下一跳为172.16.0.3。

172.16.0.2 和 10.0.0.2 上的输入和输出链均为空，且采用默认策略ACCEPT。我认为它们的前向链无关紧要，但它们被设置ACCEPT为默认使用。

在我的原始配置中，172.16.0.3（云中的 WireGuard）具有10.0.0.0/24通过 WireGuard 网络设备的路由。同样，10.0.0.1具有172.16.0.0/24通过其 WireGuard 网络设备的路由。它们的前向链使用ACCEPT并且除了 Docker 的配置外都是空的。

最后，10.0.0.1/192.168.0.2有一条 NAT 规则10.0.0.0/16：

-A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE

我可以做什么：

  • 172.16.0.3/192.168.0.1<=> 10.0.0.0/16，，，，。ping​​sshhttp
  • 172.16.0.2<= ，10.0.0.0/16单向ping，，，ssh。http
  • 172.16.0.2= > 10.0.0.1/192.168.0.2，，，，。ping​sshhttp
  • 172.16.0.2=> 10.0.0.2，ping仅此而已。

我设置了 NAT 规则之后172.16.0.3/192.168.0.1：

-A POSTROUTING -s 172.16.0.0/24 -j MASQUERADE

我有172.16.0.2=>10.0.0.2可以使用ssh/http。

云网关上的路由表如下所示：

default via 172.16.0.1 dev eth0 proto dhcp src 172.16.0.3 metric 100 
10.0.0.0/16 via 192.168.0.2 dev wg-xnzg proto static onlink 
172.16.0.1 dev eth0 proto dhcp scope link src 172.16.0.3 metric 100 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

相关内容