2

假设我们有两个对等点 - A 和 B - 试图通过对称 NAT 建立 WebRTC 对等点连接。他们通过信号交换了 ICE 候选人。

A 的公共地址：IP_A：Port_A
B 的公共地址：IP_B：Port_B

首先，A 尝试连接到 B
IP_A : Port_A ---> IP_B : Port_B

然而，该请求被 B 的 NAT 拒绝。只有 B 的 STUN 服务器可以在该地址连接 B。

接下来轮到B了。
IP_B : 端口_B ---> IP_A : 端口_A

但是在这里，不应该建立连接吗？因为，当 A 第一次向 B 发送请求时，Peer A 的 NAT 表应该已经注册了 Peer B 的地址。因此，必须接受 B 的任何响应。但是，当然，它似乎不起作用。那么，我哪里错了？

4

2 回答 2

0

我想我自己找到了答案。对称 NAT 比我想象的更严格。看看维基百科的解释，

对称 NAT

  • 从相同的内部 IP 地址和端口到特定目标 IP 地址和端口的每个请求都映射到唯一的外部源 IP 地址和端口；如果相同的内部主机发送一个数据包，即使具有相同的源地址和端口但到不同的目的地，则使用不同的映射。
  • 只有从内部主机接收数据包的外部主机才能发回数据包。

问题是，对称 NAT在向对等体 B 发送请求时将使用不同的IP : 对等体 A 的端口组合，而不是 STUN 提供的IP_A : 端口_A组合。但是 Peer B 的远程描述仍然指向IP_A : Port_A。因此，地址不匹配，连接永远不会发生。也许港口预测系统仍然可以完成这项工作，我假设：D

于 2021-05-15T16:40:58.097 回答
0

如果您从映射/过滤的角度考虑，它会更有意义。其他 NAT 术语并不能很好地描述事物的实际工作方式。我的回答来自RFC 4787和WebRTC for the Curious: Connecting

映射是您的 NAT 为出站数据包分配 IP/端口。远程对等方可以向此映射发送流量。过滤是围绕谁可以使用这些映射的规则。

然后过滤和映射可以是地址相关和独立的。如果映射依赖于地址，则意味着每次联系新 IP/端口时都会创建一个新映射。如果映射与地址无关，则意味着无论您将流量发送到何处，它都会被重复使用。这些相同的规则适用于过滤。

对于您的原始问题，地址相关映射+过滤似乎导致了问题！

我仍然希望事情在您描述的设置中起作用。WebRTC 有Peer Reflexive Candidates. WebRTC 可以在 ICE 连接检查期间发现新的候选者。由于 ICE 已经过身份验证，我们可以接受来自尚未交换的 IP/端口的流量，我们只需要断言 ICE 用户片段和密码就是我们所期望的。

于 2021-05-16T14:00:11.827 回答