NAT转换无法从网络内部进行(发夹状态) [英] NAT translation not working from inside the network (hairpin condition)

问题描述

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

I'm writing a P2P application. Peers regularly ping a main server to update their current IP/port, so when a peer wants to reach another one it can ask the server for that information. For now peers use UPnP to configure the NAT (for classic home setups) to be accessible from outside.

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

So everything works, except when a peer's client tries to reach another (or the same) peer's server and both are behind the same NAT. 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.

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

For now I'm thinking of two solutions:

• 使用UPnP查询NAT，以查看将端口转发到哪个本地IP
• 在主服务器上存储对等方的内部IP

您能想到其他解决方案吗?主流的P2P应用程序采用什么策略来解决这个问题?

Can you think of other solutions? What strategies do mainstream P2P applications implement to solve this problem?

推荐答案

由于在这种情况下，客户试图达到自己的外部" NAT后面的(公共)IP地址，NAT不做端口 转发并且无法路由IP数据包.

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都能正确解决此问题.解决方案是:

This is known as the hairpin condition. Not all router/NAT solve this properly. The solutions are:

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

a) Check whether your router/NAT can be configured to enable 'hairpining'. This solution works iff you control all router/NATs in your deployment.

b)购买另一台允许这样做的路由器/节点.就像a)一样，当您控制部署中的所有路由器/NAT时，它就会起作用.

b) Buy another router/node allowing this. Just like a), it works iff your control all router/NATs in your deployment.

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

c) If you can get obtain the port information for from UPnP, this is a solution too, but not all Router/NAT know or support UPnP. It does not cover for all cases in large deployment.

d)使用多播来发现" LAN上的其他节点，甚至与它们通信是解决此问题的常见方法.您需要在IP地址上达成共识，并让同龄人收听.

d) Using multicasting to 'discover' other nodes on the LAN and even communicate with them is a common solution to this problem. You need to agree on an IP address and have peers listen to it.

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

e) Storing the private IP address on the server is a solution too, but it requires more storage capacity on the server than solution d. There is a timeout (i.e., expiration of data validity) to handle too.

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

f) Use a TURN like communication between peers (i.e., communication between nodes pass through central server). This solution is rock solid, but not the most efficient in terms of bandwidth consumption.

希望这会有所帮助.

这篇关于NAT转换无法从网络内部进行(发夹状态)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！