Nat punch，MasterServer/Server/Client。客户端无法通过已知的公共IP和端口与服务器通信

Question

我有3个应用程序：MasterServer，Server和Client。

的MasterServer上运行：70.105.155.5:15555（端口转发的UPnP）

我创建了一个服务器，让MasterServer知道我的存在。 MasterServer保留我的公共IP和端口。 MS获取的端口由我的路由器随机分配（可以说：70.105.155.5:16666）。服务器每10秒保持发送一次MasterServer消息以保持相同的端口打开。

我打开客户端，在其上向服务器请求MasterServer以获取公共IP和端口。 MasterServer返回：70.105.155.5:16666。我知道100％确定服务器的公共端口16666仍然打开，因为我可以在我的日志中检查该端口。

但从Client => Server发送的所有消息都不会收到。同时服务器仍然通过16666从MasterServer获得消息。

所以这真的令人费解。我忘记了什么吗？我对NAT的理解有缺陷吗？

感谢您的帮助！

Answer 1

这里有很多问题，它也取决于路由器的安全配置，通常用户无法控制。一般的借口是，这是一个安全防范措施，但真正的防火墙和NAT是两个不同的问题。无论如何，大多数家庭用户都被卡住了。他们通常可以选择显式映射端口，如果路由器支持，UPnP也可以帮助您。

但是回到NAT之前，如果你的服务器和客户端坐在同一个NAT之后，你可能会遇到问题，这似乎是你上面引用的地址的情况。大多数NAT仅重写来自公共接口的传入数据包 - 因此，物理到达私有接口的数据包（即使它们发往公用IP）也不会被转发。要在野外支持这种配置，您需要设备将其私有地址通告给MasterServer，并检测他们何时想与同一NAT后面的其他设备通话，如果是，请使用私有地址而不是通过NAT。这在许多方面都存在缺陷，特别是嵌套的NAT，但我认为这是你能做的最好的。

除此之外，在所有设备都位于不同NAT后面的情况下，一些路由器只允许转发端口上的传入流量（如果它们来自最初将传出流量发送到的端口）（导致端口首先开放）。有些还要求它来自远程设备上的相同源端口。

解决方法是让MasterServer做更多的工作。要点是，它应该告诉两个同伴相互发送一个数据包;这些可能会或可能不会通过，但只是通过服务器的NAT将数据包发送到客户端的公共IP地址可能足以让服务器的NAT正确地转发来自客户端的较晚数据包。反之亦然。

实际上它更加复杂，因为服务器的NAT可能会在与客户端交谈时与使用MasterServer交谈时使用不同的端口。因此，虽然这可能会打开一个端口供客户端与服务器通话，但它可能不是客户端期望使用的端口。如果NAT的行为如此，那么你需要看看它的端口编号选择是如何可预测的。有些只是逐个增加（但要记住同一个NAT后面可能有其他设备，导致该数字一次跳跃超过一个步骤）。对于这些客户端，客户端需要发送一系列服务器端口垃圾邮件来试图找出哪一个端口被打开。 MasterServer再次处于协调这一状态的最佳位置。

其他在端口分配上看起来完全是随机的，并且这些可以做的事情不多。但是，如果两端都在这些随机NAT之后，那么这只是终端。只要一端更容易被打开，随机结束就不重要了。

还要注意，有些NAT为目标上的每个端口使用不同的出站端口 - 即使端口未被随机分配，这也会使预测困难得多。再次，只要连接的一端是灵活的，你可以容忍这些NAT，但是在对等的环境下，它们最终将成为一场噩梦，因为它们无法互相交流。