TURN Server Nat 遍历 ICE STUN

Posted 2023-04-15

【中文标题】TURN Server Nat 遍历 ICE STUN

【英文标题】：TURN Server Nat traversal ICE STUN

【发布时间】：2017-10-17 22:41:52

【问题描述】：

我正在实现一个 TURN 服务器，我将在我的问题中使用 TURN rfc5766 术语。

有一部分我没有得到。 假设我们有一个连接到 TURN 服务器的客户端（A）和一个尚未连接到任何东西的对等点（B）。我们从另一种机制中获取对等体（B）的反身地址，并使用 SIP 或电子邮件将其传递给客户端（A）。无论如何可能。

接下来假设我们为客户端 (A) 创建了分配、权限和中继地址

它表示当客户端（A）向 TURN 服务器发送对端（B）的数据指示以进行中继时，它将对端（B）的服务器自反地址附加到该指示。然后服务器从指示中提取 udp 和 peer(B) 的反射地址并将其发送给 peer(B) . 我没有得到的是服务器如何到达其 NAT 后面的对等点（B）。只知道 peer(B) 的服务器自反地址并不能正确处理它。 如果 peer(B) 从未与服务器通信，则 peer(B) 的 NAT 将永远不会在 TURN 服务器上创建从 Peer(B) 到客户端 (A) 中继地址的映射。

如果服务器可以在没有 ip:port 映射的情况下到达对等点 (B) 的服务器自反地址，那么客户端 (A) 也可以（因为客户端也知道对等点 (B) 的服务器自反地址）。而且它不需要转向服务器。它只会使用 STUN。

那么 TURN Server 的意义何在？ 我错过了什么。

有人可能会争辩说，Maybe peer(B) 事先对同一台服务器做了一个 STUN 绑定请求，这就是我们获得 peer(B) 服务器反射地址的方式，并且该请求在 peer(B) 上创建了一个 NAT 映射' s侧。好吧，这只适用于使用端点独立映射和地址相关映射但不使用地址和端口相关映射的 NAT。因为client(A)的relay-address与发送STUN绑定请求的Turn服务器的地址不同。 前任： 转服务器地址：121.121.121.121:8080 客户端中继地址：121.121.121.121:8081（同转服务器不同端口。）。 由于 stun 绑定消息发送到 121.121.121.121:8080，因此 Peer(B) 的 NAT 上没有映射 121.121.121.121:8081。 基本上桥断了。

谢谢。

【参考方案1】：

您解释中的问题是对等方（B）在消息传递开始之前不会连接到 TURN 服务器。这不是真的。

对于 WebRTC 客户端，需要配置 STUN 和 TURN 服务器地址。当客户端创建 PeerConnections 时，它们都将在实际消息传递开始之前连接到 TURN 服务器。为此，两个对等点都必须连接到 TURN 服务器，并进行“打孔”，然后允许流量通过 NAT。

当通过 TURN 服务器中继流量时，客户端不会知道彼此的 IP 地址，只知道要与之通信的 TURN 端点。