为什么'；WebRTC是否与对称NAT一起工作？
假设我们有两个对等点-A和B-试图通过对称NAT建立WebRTC对等连接。他们通过信号交换了ICE候选人 A的公共地址：IP\u A:Port\u A为什么'；WebRTC是否与对称NAT一起工作？,webrtc,nat,nat-traversal,Webrtc,Nat,Nat Traversal,假设我们有两个对等点-A和B-试图通过对称NAT建立WebRTC对等连接。他们通过信号交换了ICE候选人 A的公共地址：IP\u A:Port\u A B的公共地址：IP\u B:Port\u B 首先，A尝试连接到B IP_A:端口_A--->IP_B:端口_B 然而，B的NAT拒绝了该请求。只有B的STUN服务器可以在该地址连接B 接下来轮到B了。 IP\u B:端口\u B--->IP\u A:端口\u A 但在这里，不应该建立联系吗？因为，当第一次向B发送请求时，对等方A的NAT表应该已
B的公共地址：IP\u B:Port\u B 首先，A尝试连接到B
IP_A:端口_A--->IP_B:端口_B 然而，B的NAT拒绝了该请求。只有B的STUN服务器可以在该地址连接B 接下来轮到B了。
IP\u B:端口\u B--->IP\u A:端口\u A
但在这里，不应该建立联系吗？因为，当第一次向B发送请求时，对等方A的NAT表应该已经注册了对等方B的地址。所以，必须接受B的任何响应。但当然，它似乎不起作用。那么，我错在哪里呢？我想我自己找到了答案。对称NAT比我想象的更具限制性。看看维基百科的解释 对称NAT
- 从相同内部IP地址和端口到特定目标IP地址和端口的每个请求都映射到一个唯一的 外部源IP地址和端口；如果相同的内部主机发送 数据包，即使源地址和端口相同，但发送到不同的 目的地，使用不同的映射
- 只有从内部主机接收数据包的外部主机才能发回数据包
问题是，对称NAT在向对等方B发送请求时，将为对等方a使用不同的IP:Port组合，而不是STUN提供的IP\u a:Port\u a组合。但对等方B的远程描述仍然指向IP\u A:Port\u A。因此，地址不匹配，连接永远不会发生。也许一个端口预测系统仍然可以做到这一点，我想：如果你从映射/过滤的角度考虑，它会更有意义。其他NAT术语不能很好地描述事物的实际工作方式。我的答案来自和 映射是指NAT为出站数据包分配IP/端口。远程对等方可以将流量发送到此映射。筛选是关于谁可以使用这些映射的规则 然后，筛选和映射可以是地址相关和独立的。如果映射依赖于地址，则表示每次联系新的IP/端口时都会创建一个新映射。如果映射与地址无关，则意味着无论在何处发送流量，它都会被重复使用。这些规则同样适用于过滤
对于您最初的问题，似乎是地址相关映射+筛选导致了问题 我仍然希望在您描述的设置中工作。WebRTC有
对等自反候选对象