NAT转换无法从网络内部进行(发夹状态)。

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

要回复问题请先登录注册