假设我们有两个对等点 - 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 : Port_B ---> IP_A : Port_A
但是在这里，不应该建立连接吗？因为，当 A 第一次向 B 发送请求时，Peer A 的 NAT 表应该已经注册了 Peer B 的地址。因此，必须接受来自 B 的任何响应。但是，当然，它似乎不起作用。那么，我哪里错了？
【问题讨论】：
标签： webrtc nat nat-traversal
我想我自己找到了答案。对称 NAT 比我想象的更严格。看看维基百科的解释，
对称 NAT
- 从同一内部 IP 地址和端口到特定目标 IP 地址和端口的每个请求都映射到一个唯一的 外部源IP地址和端口；如果同一内部主机发送一个 即使具有相同的源地址和端口但发送到不同的数据包 目的地，使用不同的映射。
- 只有从内部主机接收数据包的外部主机才能发回数据包。
问题是，Symmetric NAT 在向 Peer B 发送请求时，会为 Peer A 使用不同的 IP : Port 组合，而不是由眩晕。但是 Peer B 的远程描述仍然指向 IP_A : Port_A。因此，地址不匹配，连接永远不会发生。也许港口预测系统仍然可以完成这项工作，我认为：D
【讨论】：
如果您从映射/过滤的角度考虑，它会更有意义。其他 NAT 术语并不能很好地描述事物的实际工作方式。我的回答来自RFC 4787和WebRTC for the Curious: Connecting
映射是指您的 NAT 为出站数据包分配 IP/端口。远程对等方可以向此映射发送流量。过滤是围绕谁可以使用这些映射的规则。
过滤和映射可以是地址相关和独立的。如果映射依赖于地址，则意味着每次联系新 IP/端口时都会创建一个新映射。如果映射与地址无关，则意味着无论您将流量发送到何处，它都会被重复使用。这些相同的规则也适用于过滤。
对于您的原始问题，地址相关映射+过滤似乎导致了问题！
我仍然希望在您描述的设置中可以正常工作。 WebRTC 有Peer Reflexive Candidates。 WebRTC 可以在 ICE 连接检查期间发现新的候选者。由于 ICE 已经过身份验证，我们可以接受来自尚未交换的 IP/端口的流量，我们只需要断言 ICE 用户片段和密码就是我们所期望的。
【讨论】：