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

问题描述

假设有两个设备位于对称 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 的 REFLEXIVE 候选对象。

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

不久前我问了一个类似的问题 Will ICE negotiations between peers behind two symmetric NAT's result in requiring two TURN servers?，但现在我怀疑对称 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 是对的，这取决于实现细节。

但您没有指定的另一个标准是您的假设列表是设备_1 和设备_2 前面的 NAT 是否确实让 UDP 通过。

最邪恶/最有问题的情况是 Device_1 和 Device_2 无法使用 UDP 连接到 Internet。在这种情况下，他们都必须使用 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