单个 TURN 服务器是否足以支持受限 NAT 配置后面的两个设备?

Is a single TURN server sufficient for two devices behind restricted NAT configurations?

让我们假设两个设备位于对称 NAT 之后。

  1. Device_1 仅收集 HOST 和 REFLEXIVE 候选人。它在 SDP OFFER 中将它们发送到 Device_2。

  2. Device_2 收集 HOST、REFLEXIVE 和 RELAY 候选。它在 SDP ANSWER 中将它们发送到 Device_1。

  3. 在 ICE 连接检查期间,Device_2 将在其 TURN 服务器中安装权限。这将是 Device_1.

    的自反候选者
  4. 在某些时候,STUN 指示将从 Device_1(自反)发送到 Device_2(中继)。如果 Device_2 为 Device_1 的自反地址创建了权限,UDP 数据包应该到达 TURN 服务器,包裹在 STUN 消息中,然后到达 Device_2。此连接检查应该通过,因此双向流量应该流动。

这个理解对吗?

          RESTRICTED_NAT                         RESTRICTED_NAT
                |                                      |
Device_1 <----> | <--UDP--> [Device_2_TURN] <--SEND--> | <----> Device_2
Peer            |                                      |        Client

Host                                                            Host
Reflexive                                                       Reflexive
                                                                Relay

我刚才问了一个类似的问题 ,但现在我怀疑对称 NAT 后面的两个对等点是否需要两个 TURN 服务器。原因是,在 TURN 服务器上创建的权限仅包含一个 IP 地址。

https://datatracker.ietf.org/doc/html/rfc5766#section-9.1

   When forming a CreatePermission request, the client MUST include at
   least one XOR-PEER-ADDRESS attribute, and MAY include more than one
   such attribute.  The IP address portion of each XOR-PEER-ADDRESS
   attribute contains the IP address for which a permission should be
   installed or refreshed.  The port portion of each XOR-PEER-ADDRESS
   attribute will be ignored and can be any arbitrary value.  The
   various XOR-PEER-ADDRESS attributes can appear in any order.

这意味着只要同一个服务器自反IP向中继传输地址发送一个UDP报文,它就应该通过。意思是,应该只使用一个 TURN 服务器。

这取决于您使用的转向服务器软件对 RFC 的实现程度。您需要检查一下。

该端口是发送到 TURN 服务器的 xor-peer-address 的一部分,因此自然假设是任何查找都是针对完整地址进行的。

但如果另一端位于对称 NAT 之后,则使用的端口(有时是 IP,但这种情况很少见)会有所不同。这可能是 RFC 中特定要求的原因。

是的,Philipp 是对的,这取决于实施细节。

但是您没有指定的其他标准是您的假设列表是 Device_1 和 Device_2 前面的 NAT 是否允许 UDP 通过。

最evil/problematic的情况是如果Device_1和Device_2不能使用UDP连接到互联网。在那种情况下,他们都必须使用 TCP 连接到他们的每个 TURN 中继。由于大多数(?)TURN 服务器今天只在这种情况下处理我们的 UDP 候选 Device_1 使用 TCP 连接 Device_1_TURN。这同样适用于 Device_2。但是由于现在都分发了 UDP 候选人,所以 TURN 服务器需要连接到 TURN 服务器。

Device_1 <--TCP--> Device_1_TURN <--UDP--> Device_2_TURN <--TCP--> Device_2

在这种情况下,您无法只使用一个 TURN 中继,因为 Device_1 无法通过 UDP 连接到 Device_2 的基于 UDP 的中继候选者。

如果 TURN 服务器和 Device_2 都实现了对 TURN TCP 候选者的支持,您可以再次将这种情况减少到一个 TURN 服务器。然后 Device_1 需要支持 ICE TCP 并通过 TCP 连接到 TURN 服务器:

Device_1 <--TCP--> Device_2_TURN <--TCP--> Device_2