我正在编写一个 P2P 应用程序。对等点定期 ping 主服务器以更新其当前 IP/端口，因此当对等点想要访问另一个对等点时，它可以向服务器询问该信息。目前，对等方使用 UPnP 将 NAT（用于经典家庭设置）配置为可从外部访问。
所以一切正常，除非对等的客户端试图到达另一个（或相同的）对等的服务器并且两者都在相同的 NAT 后面。由于在这种情况下，客户端试图从 NAT 后面到达其自己的“外部”（公共）IP 地址，因此 NAT 不会进行端口转发，也无法路由 IP 数据包。
目前我正在考虑两种解决方案：
你能想到其他解决方案吗？主流 P2P 应用都采取了哪些策略来解决这个问题？
由于在这种情况下，客户端试图从 NAT 后面到达其自己的“外部”（公共）IP 地址，因此 NAT 不会进行端口转发，也无法路由 IP 数据包。
这被称为发夹条件。并非所有路由器/NAT 都能正确解决这个问题。解决方案是：
a) 检查您的路由器/NAT 是否可以配置为启用“hairpining”。如果您控制部署中的所有路由器/NAT，则此解决方案有效。
b) 购买另一个允许这样做的路由器/节点。就像 a)，如果您控制部署中的所有路由器/NAT，它就可以工作。
c) 如果您可以从 UPnP 获取端口信息，这也是一种解决方案，但并非所有 Router/NAT 都知道或支持 UPnP。它并不涵盖大型部署中的所有情况。
d) 使用多播来“发现” LAN 上的其他节点，甚至与它们通信是解决此问题的常见解决方案。您需要就 IP 地址达成一致并让对等方监听它。
e) 在服务器上存储私有 IP 地址也是一种解决方案，但它比解决方案 d 需要更多的服务器存储容量。还有一个超时（即数据有效性到期）需要处理。
f) 在对等点之间使用类似于 TURN 的通信（即，节点之间的通信通过中央服务器）。该解决方案坚如磐石，但在带宽消耗方面不是最有效的。
希望这可以帮助。
交互式连接建立 (ICE) 是专门为解决此类 NAT 问题而开发的。它使用 STUN 和 TURN 来实现结果，并用于现代 p2p 应用程序。（例如语音聊天）
PJNATH 库有一个文档解释
与独立的 STUN 解决方案不同，它 (ICE) 解决了发夹问题，因为它还提供主机候选者。