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