2

在对我的 Web 应用程序进行故障排除时，我发现了 draft-mdns-ice-candidates，它是关于使用 mDNS 混淆主机候选者中的地址。

而且我发现当两个peer（agent L，agent R）处于如下图7的拓扑中时，WebRTC peer连接失败，因为agent R的主机地址被混淆了，agent R的srflx地址被丢弃，因为代理 R 不在 NAT 后面。rfc8445中关于丢弃agent R的srflx地址的相关表述如下。

5.1.3. 消除冗余候选人

接下来，ICE 代理（发起和响应）消除多余的候选人。两个候选者可以有相同的传输地址但不同的基数，这些不会被认为是多余的。通常，当代理不在 NAT 之后时，服务器自反候选和主机候选将是多余的。一个候选者是冗余的当且仅当它的传输地址和基址与另一个候选者的相同。代理应该消除具有较低优先级的冗余候选者。- RFC8445 第 5.1.3 节

图 7

（图 7 来自rfc8445 的第 15.1 节）

并且在draft-mdns-ice-candidates 的第 5 节中，我没有找到关于图 7 的情况的解释。当我测试最新版本的 Chrome、Firefox 和 Safari 时，WebRTC 对等连接在所有浏览器中都失败了。图 7 的情况，因为我上面写的原因——代理 R 的主机地址被混淆，代理 R 的 srflx 地址被丢弃。

通过更改浏览器设置关闭混淆本地地址时（默认情况下进行混淆），WebRTC对等连接成功建立。（我在 Chrome 和 FireFox 上测试了这个成功的连接。在 Chrome 中，通过Anonymize local IPs exposed by WebRTC在“about:flags”页面中禁用。在 Firefox 中，通过false media.peerconnection.ice.obfuscate_host_addresses在“about:config”页面中设置。）

这是 IETF 的 WebRTC 规范的问题吗？（可能是draft-mdns-ice-candidates和rfc8445之间的冲突？）还是现代浏览器的实现问题？有没有办法在不关闭混淆主机地址的情况下，在图 7 的情况下建立 WebRTC 对等连接？我想知道。

4

1 回答 1

1

来自draft-ietf-mmusic-mdns-ice-candidates-02，第 3.1.2.2 节：

不管结果如何，都会生成一个服务器自反候选；该候选者的传输地址是一个 IP 地址，因此与关联的 mDNS 候选者的主机名传输地址不同，因此根据 [RFC8445] 第 5.1.3 节中的指南，不得将其视为冗余。为避免意外的 IP 地址泄露，该服务器自反候选必须将其 raddr 字段设置为“0.0.0.0”/“::”，并将其 rport 字段设置为“9”，如 [ICESDP] 第 9.1 节所述。

由于 SRFLX 候选者的服务器自反 IP 地址与用于生成本地混淆候选者的 IP 地址匹配而忽略它似乎是明显不合格的。

于 2021-11-18T19:07:37.980 回答