我无法使用 srvflx candidate 在同一 LAN 中的两个客户端之间建立冰连接

I couldn't establish ice connection between two clients in same LAN using srvflx candidate

我想做的是创建一个测试脚本 (javascript) 来检查客户端是否可以通过 "server reflexive candidates".

连接

我从 test.webrtc.org 复制了脚本,它基本上创建了两个对等点并通过数据通道发送一些文本并检查双方是否收到文本。

我遇到的问题是我的 "ice connection state" 将从 "checking" 更改为 "failed"。

我知道我的浏览器 (chrome) 可以通过 "server reflexive candidates" 连接,我们没有使用对称 NAT。

我知道在正常情况下,当两个客户端在同一个 LAN 中时,它们几乎总是通过 "host candidates" 连接(有时通过中继候选,不知道为什么)

我 "forcing" 它通过 "server reflexive candidates" 连接的唯一原因是我想创建一个测试脚本,以便我们的用户可以自行检查他们的浏览器能够连接哪些候选者。

连接场景可以描述如下:

客户端 A 源 - 本地 IP - 192.168.1.142 - 源端口 - 52245 客户端 A 目标 - 远程 IP - 99.99.99.99 - 目标端口 - 43353

客户端 B 源 - 本地 IP - 192.168.1.110 - 源端口 - 43353 客户端 B 目标 - 远程 IP - 99.99.99.99 - 目标端口 - 52245

在我的路由器中使用 "netstat" 时,我得到以下信息:

Proto Source Address                      Destination Address              State 
udp   192.168.1.142:52245                 99.99.99.99:43353                UNREPLIED   
udp   192.168.1.110:43353                 99.99.99.99:52245                UNREPLIED  

我不确定这是否与路由器行为有关,而且我在路由器管理控制台中没有看到任何与上述相关的设置,所以我换了不同的路由器,但我仍然得到与描述相同的结果.是不是因为上面的连接是不允许的?

[编辑 - 包括路线 table]

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
99.99.99.254    *               255.255.255.255 UH    0      0        0 WAN
99.99.99.0      *               255.255.255.0   U     0      0        0 WAN
192.168.1.0     *               255.255.255.0   U     0      0        0 LAN
default         99.99.99.254    0.0.0.0         UG    0      0        0 WAN

并非所有 NAT 都支持将来自内部 IP 的数据包重定向到另一个内部 IP。这称为发夹。 wiki 中的示例与您的情况非常相似,

让我们考虑一个具有以下内容的专用网络:

Gateway address: 192.168.0.1
Host 1: 192.168.0.5
Host 2: 192.168.0.7

The gateway has an external IP : 192.0.2.1
Host 1 runs a P2P application P1 on its port 12345 which is externally mapped to 4444.
Host 2 runs a P2P application P2 on its port 12345 which is externally mapped to 5555.

如果 NAT 设备支持发夹,则 P1 应用程序可以使用外部端点 192.0.2.1:5555 连接到 P2 应用程序。否则,通信将无法进行。

when both clients are in the same LAN they will almost always connect via "host candidates" (sometimes via relay candidates, not sure why)

只有当一​​个或两个主机屏蔽了另一个主机的 IP 地址时,才会发生这种情况。除此之外,同一局域网下的两个设备不可能没有主机到主机连接。

我能够使用 srvflx 候选者在同一 LAN 中的两个客户端之间建立冰连接,仅通过 VPN 隧道连接一个客户端。

如果不使用 VPN,连接永远不会成功。

我从 VPN 隧道客户端测试的 STUN 服务器在确定我的本地地址和映射地址时没有问题。