为什么 STUN 服务器需要两个不同的公共 IP 地址
我查看了 openfire 中的 STUN 服务器设置，并从那里得到了以下声明：
“为了作为 STUN 服务器，同一台机器上需要两个不同的公共 IP 地址，并且每个 IP 需要两个不同的端口号。”
我在google上研究过，一般stun服务器需要两个公共IP，这是什么原因？
I have took a look to STUN Server settings in openfire, and this statement from there:
"In order to act as a STUN server, two different public IP addresses on the same machine are required, as well as two different port numbers for each IP."
I have researched on google, and generally stun servers need two public IPs, what is reason for that?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对于尝试建立 P2P 连接，STUN 绑定请求和 STUN 服务的主地址（IP 和端口）的响应才是真正重要的。在此请求的响应正文中返回的映射地址被传递（通过 XMPP 或其他服务）到本地客户端尝试与之建立直接通信的远程节点。
STUN 服务侦听的第二个 IP 和端口对于确定 NAT 端口映射行为和 NAT 过滤行为非常有用。
通过向服务上的备用 IP:端口发出绑定请求，客户端可以发现其 NAT 是否对本地端口具有一致的映射语义。如果他为每次测试获得不同的端口映射值，客户端可以断定它位于“对称 NAT”之后 - 这是 P2P 最难遍历的。
通过发送带有“更改请求”属性的绑定请求，要求服务从其他 IP 或端口进行响应，客户端可以检测其 NAT 是否仅根据 IP 和端口过滤来自远程主机的数据报，或者允许来自其他主机的数据报。已向其发送出站数据报的主机上的备用端口。
映射行为和过滤测试仅为后续 P2P 连接提供有限的信息。在确定主机和互联网之间存在对称NAT的情况下，一些实现可以观察到NAT在每个绑定响应中具有一致的端口值增量值。 （例如STUN服务观察到的外部端口增加1）。因此，客户端可以为远程客户端提供尝试发送的 IP 和猜测的端口号，而不是从第一个绑定请求映射回的端口号。或者客户端可以使用此行为/过滤测试进行日志记录。或者在对称 NAT 的情况下自动分配中继。
For attempting to establish P2P connectivity, the STUN binding request and response to/from the STUN service's primary address (IP and port) is all that really matters. The mapped address returned in the response body of this request is passed (via XMPP or other service) to the remote node that the local client is attempting to establish directly communication with.
The second IP and port that the STUN service listens on are useful for determining NAT port mapping behavior and NAT filtering behavior.
By making binding requests to the alternate IP:port on the service, a client can discover if his NAT has consistent mapping semantics for local ports. In the event he gets different port mapping values for each test, the client can conclude it is behind a "symmetric NAT" - which are the most difficult to traverse for P2P.
By sending up a bind request with a "change request" attribute that asks the service to respond from the other IP or port, a client can detect if his NAT just filters datagrams from remote hosts based on IP and port, or allows for datagrams from alternate ports on hosts it has sent outbound datagrams to.
The mapping behavior and filtering tests only provide limited information for subsequent P2P connections. In the case of determining a symmetric NAT is between the host and the Internet, some implementations may observe the NAT to have a consistent incremental value of the port value in each binding response. (e.g. the external port observed by the STUN service increases by one). As such, the client can offer an IP and guessed port number for the remote client to try to send to instead of the one mapped back from the first binding request. Or the client may use this behavior/filtering test for logging. Or to automatically allocate a relay in the event of symmetric NAT.
因为在极少数情况下，NAT 转换的行为是目标 IP 地址的函数。这意味着，您必须“ping”两个不同的 IP 地址才能找到 NAT 的精确行为（它是否取决于目标 IP 地址？）
如果您使用两个不同的端口“ping”同一服务器两次，则不会涵盖正确地处理这种情况（即，您不会涵盖所有基础）。
PS：两个IP地址不需要在同一台服务器上，也可以是不同的服务器。
Because in some rare cases, the behavior of NAT translation is a function of the target IP address. Meaning, you must 'ping' two different IP addresses to find the precise behavior of the NAT (does it depend of the target IP address or not?)
If you 'pinged' twice the same server with two distinct ports, that would not cover this case properly (i.e., you would not be covering all your bases).
P.S.: The two IP addresses don't need be on the same server, it could be different servers.
我猜测需要识别正在执行的 NAT 类型 - 有些 NAT 将使用相同的源 IP 地址并通过端口号对会话 id 进行编码（我认为这称为锥体 NAT 但不确定），有些 NAT 会使用源 IP 和端口的组合来编码会话 ID。 STUN 服务器需要给客户端的答案根据 NAT 类型而不同。
I'm guessing that it is required to identify the type of NAT being performed - some NAT will use the same source IP address and encode the session id via the port number (I think it's called cone NAT but not sure), some NAT will use a combination of source IP and port to encode the session ID. The answer the STUN server needs to give the client is different based on NAT type.