单个 TURN 服务器是否足以支持受限 NAT 配置后面的两个设备?
Is a single TURN server sufficient for two devices behind restricted NAT configurations?
让我们假设两个设备位于对称 NAT 之后。
Device_1 仅收集 HOST 和 REFLEXIVE 候选人。它在 SDP OFFER 中将它们发送到 Device_2。
Device_2 收集 HOST、REFLEXIVE 和 RELAY 候选。它在 SDP ANSWER 中将它们发送到 Device_1。
在 ICE 连接检查期间,Device_2 将在其 TURN 服务器中安装权限。这将是 Device_1.
的自反候选者
在某些时候,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
让我们假设两个设备位于对称 NAT 之后。
Device_1 仅收集 HOST 和 REFLEXIVE 候选人。它在 SDP OFFER 中将它们发送到 Device_2。
Device_2 收集 HOST、REFLEXIVE 和 RELAY 候选。它在 SDP ANSWER 中将它们发送到 Device_1。
在 ICE 连接检查期间,Device_2 将在其 TURN 服务器中安装权限。这将是 Device_1.
的自反候选者在某些时候,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
我刚才问了一个类似的问题
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