networking - NAT 转换在网络内部不起作用(发夹条件)

Question

我正在编写一个 P2P 应用程序。对等点定期 ping 主服务器以更新其当前 IP/端口，因此当对等点想要访问另一个对等点时，它可以向服务器询问该信息。目前，对等方使用 UPnP 将 NAT(用于经典家庭设置)配置为可从外部访问。

所以一切正常，除非对等的客户端尝试访问另一个(或相同)对等的服务器并且两者都在相同的 NAT 后面。 由于在这种情况下，客户端试图从 NAT 后面访问其自己的“外部”(公共(public))IP 地址，因此 NAT 不进行端口转发并且无法路由 IP 数据包。

目前我正在考虑两种解决方案:

使用 UPnP 查询 NAT 以查看端口转发到哪个本地 IP

在主服务器上存储对等方的内部 IP

你能想到其他解决方案吗？主流 P2P 应用都采取了哪些策略来解决这个问题？

Answer 1

Since in that case the client is trying to reach its own "external" (public) IP address from behind the NAT, the NAT doesn't do the port forwarding and is unable to route the IP packet.

这被称为发夹条件。并非所有路由器/NAT 都能正确解决这个问题。解决方案是:

a) 检查您的路由器/NAT 是否可以配置为启用“hairpining”。如果您控制部署中的所有路由器/NAT，则此解决方案有效。

b) 购买另一个允许这样做的路由器/节点。就像 a)，如果您控制部署中的所有路由器/NAT，它就可以工作。

c) 如果您可以从 UPnP 获取端口信息，这也是一种解决方案，但并非所有 Router/NAT 都知道或支持 UPnP。它并不涵盖大型部署中的所有情况。

d) 使用多播来“发现”局域网上的其他节点，甚至与它们通信是解决此问题的常见解决方案。您需要就 IP 地址达成一致并让对等方监听它。

e) 在服务器上存储私有(private) IP 地址也是一种解决方案，但它比解决方案 d 需要更多的服务器存储容量。还有一个超时(即数据有效性到期)需要处理。

f) 在对等点之间使用类似于 TURN 的通信(即节点之间的通信通过中央服务器)。该解决方案坚如磐石，但在带宽消耗方面不是最有效的。

希望这可以帮助。