了解 Stun 工作

Posted 2023-04-15

【中文标题】了解 Stun 工作

【英文标题】：Understanding Stun working

【发布时间】：2018-01-06 01:19:48

【问题描述】：

我浏览了Programming P2P application SO 帖子。但我想我仍然不清楚 STUN 是如何工作的。

所以，我想发表我的理解并希望得到纠正。

按照示例

假设机器 (A) IP 是 192.168.1.2 运行在（STUN 服务器上的 TCP 客户端请求）4900（TCP 客户端请求 STUN 服务器 over TCP 运行在 4900）并且 Stun 服务器返回了公共 IP NAT设备即128.11.12.138888

现在我希望机器 B（假设现在 B 通过公共 IP 128.11.12.13 知道）通过端口 3000 (TCP) 连接到机器 A

这之后发生了什么 -

B 试图用128.11.12.13 上的 IP 连接 A

问题 1：但是哪个端口？ （不能直接连接3000端口）

我想答案是将4900 请求转发到3000。

但这里有一件事

问题 2：连接到 4900 上的 STUN 服务器的 TCP 客户端怎么样（发送指示等）。如果应用端口转发，从 Stun 服务器到 TCP 客户端的所有流量现在都将重定向到端口 3000。对吗？

我在这方面是正确的吗？

这有什么办法，还是我在这里大声思考？ :)

【参考方案1】：

确实，您不能直接连接到端口 3000。您必须连接到在 NAT 上打开的端口，它是 STUN 响应中收到的地址：端口

client A                 NAT                  STUN server        client B   
   |---- STUN request --->|                       |                   |
   | src:192.168.1.2:3000 |                       |                   |
   |                      |---- STUN request ---->|                   |
   |                      | src:128.11.12.13:8888 |                   |
   |                      |                       |                   |
   |                      |<----STUN response-----|                   |
   |                      | ext:128.11.12.13:8888 |                   |
   |<----STUN response----|                       |                   |
   | ext:128.11.12.13:8888|                       |                   |
   |                                                                  |
   |======= APP protocol over rendezvous server =====================>|
   |        my address is 128.11.12.13:8888                           |
   |                                                                  |
   |<======= APP protocol over rendezvous server =====================|
   |          my address is 1.2.3.4:9999                              |
   |                                                                  |
   |-- direct protocol -->|                                           |
   | src:192.168.1.2:3000 |                                           |
   | dst:1.2.3.4:9999     |<--------- direct protocol ----------------|
   |                      |           dst:128.11.12.13:8888           |
   |<-- direct protocol --|                                           |
   | dst:192.168.1.2:3000 |                                           |
   |                      |                                           |

STUN 仅向客户端提供可能在 NAT 设备上打开的外部 IP 地址和端口。客户端 B 必须尝试连接到此 IP 和端口（128.11.12.13:8888），客户端 A 必须在源地址中使用的相同 IP：端口（192.168.1.2:3000）侦听 STUN 请求中的端口.

如果你幸运的话，上面的场景效果很好。但是您可能会很不走运，因为有很多 NAT 类型，并且可能会发生一些错误，尤其是对于 TCP。

编辑（回答评论中的其他问题）：

最好保持与 STUN 服务器的连接打开。 NAT 设备在检测到连接关闭时可能会关闭针孔。但这取决于 NAT 设备内部处理，据我所知，这不是标准化的。

客户端 A 的直接协议的侦听套接字必须设置 SO_REUSEADDR 选项。如果设置了该选项，则可以建立与 STUN 服务器的连接，然后在同一端口创建一个监听套接字。

【讨论】：

你能解释一下最后一件事，stun-client 在收到成功的 stun 响应后必须关闭与 stun 服务器的连接。（原因是，Stun RFC 声明代理（可以是客户端或 stun 服务器）可以随时发送指示消息。如果我不关闭端口 3000 的 stun-client，我将无法在特定端口（即 3000）启动 TCP 服务器，对吧？ . 假设 TCP 服务器将使用any address

从例子中我不清楚，这一切的意义何在？如果客户端 A 可以发送到客户端 B，则 NAT 将被映射，端口将打开，客户端 B 可以响应。拥有 STUN 服务器的价值是什么？

回答我自己的问题，我认为答案是即使两个客户端都在 NAT 之后，STUN 服务器有时仍然可以工作。由于 STUN 服务器不在 NAT 后面，所以两个客户端仍然可以打开一个 NAT“洞”。