☰

利用 NAT 中的 Wireguard 服务器状态 UDP 防火墙

tag-icon • tag-icon firewall iptables nat wireguard
利用 NAT 中的 Wireguard 服务器状态 UDP 防火墙

我有一个“客户端-服务器”设置，由一台 Wireguard 服务器计算机和一台客户端组成，它们都位于各自的 NAT 下。我希望它们可以在客户端路由器上进行通信，而无需端口转发。显然，我仍然需要在服务器的路由器中进行端口转发。

根据此评论如果服务器的回复来自客户端用于访问它的同一端口，则可以利用状态 UDP 防火墙。为此，我ListenPort在两端都设置为 58120：

[Interface]
ListenPort = 51820
...snip...

现在，通过tcpdump在客户端的路由器上执行，我可以证明数据包通过源端口 51820 和目标端口 51820 传出。与tcpdump在服务器的路由器上执行相同：传出的数据包的源和目标设置为 51820。

但是，在传入方向，客户端路由器显示数据包来自端口 1025。看起来服务器端 NAT 将端口 51820 更改为 1025。这是因为端口 51820 已被端口转发占用吗？如何让源端口和目标端口相等，以便客户端路由器检测到 UDP“连接”？

实施细节：防火墙和 NAT 都是由 iptables 驱动的。

答案1

根据此评论，如果服务器的回复来自客户端用于访问它的同一端口，则可以利用状态 UDP 防火墙。

评论里不是这么说的。端口不必平等的;他们只需要对称。也就是说，如果数据包从源端口 51820 和目标端口 28150 发出，则 NAT 将期望入站数据包从端口 28150 到 51820。

（例如，查看 DNS 请求 - 您不会看到带有 53→53 的数据包，而会看到 [随机]→53，并且防火墙只会期待带有 53→[随机] 的回复。）

但是在传入方向，客户端的路由器显示数据包来自端口 1025。看起来服务器端 NAT 将端口 51820 更改为 1025。这是因为端口 51820 已被端口转发占用吗？

更可能是因为 NAT 已经在跟踪使用相同本地端口（但可能来自不同的内部 IP 地址，或者转到不同的远程端口）的与该目的地的另一个 UDP 对话。

iptables 中的标准 SNAT / MASQUERADE 模块不会查看您拥有哪些端口转发规则 - 它仅包含有关 conntrack 状态（当前跟踪的流）的信息，但它会尝试重写本地端口以确保入站主机的唯一性：端口（参见 nf_nat_used_tuple）。

检查conntrack -L -p udp网关；如果您频繁编辑实验的 NAT 规则，您可能需要清除旧状态。

网关中的一些 NAT 实现使用自定义 iptables NAT 模块和总是更改所有出站连接的源端口。这通常与术语“对称 NAT”一起使用（与标准 iptables 实现的更宽松的“锥形 NAT”相反）。

相关文章（来自基于 WireGuard 的 VPN 应用程序开发人员）：https://tailscale.com/blog/how-nat-traversal-works/

相关内容