我要做的是创建一个测试脚本（javascript）来检查客户端是否可以通过“服务器反身候选人”进行连接。
我从test.webrtc.org复制了脚本，它基本上创建了两个对等体并通过数据通道发送了一些文本，并检查双方是否收到了文本。
我遇到的问题是我的“冰连接状态”会从“检查”变为“失败”。
我知道我的浏览器（chrome）可以通过“服务器反身候选人”连接，我们没有使用对称NAT。
我知道在正常情况下，当两个客户都在同一个局域网时，他们几乎总是通过“主持人候选人”连接（有时通过接力候选人，不知道为什么）
我“强迫”它通过“服务器反身候选人”进行连接的唯一原因是因为我想创建一个测试脚本，以便我们的用户可以自我检查他们的浏览器能够选择哪些连接。
连接方案可以如下所述：
客户端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
我不确定这是否与路由器行为有关，我在路由器管理控制台中没有看到与上述相关的任何设置，所以我已经改为不同的路由器，我仍然得到相同的结果描述。是因为不允许上面的连接吗？
[编辑 - 包括路线表]
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
答案 0 :(得分：3)
所有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应用程序。如果没有，通信将无法正常工作。
当两个客户都在同一个局域网中时，他们几乎总是通过主机候选人连接＃34; （有时通过接力候选人，不知道为什么）
只有当一个或两个主机阻止了另一个主机的IP地址时，才会发生这种情况。除此之外，同一LAN下的两台设备无法与主机进行主机连接。
答案 1 :(得分：0)
我只能通过VPN隧道连接一个客户端，使用srvflx候选者在同一局域网中的两个客户端之间建立冰连接。
如果不使用VPN，连接将永远不会成功。
我从VPN隧道客户端测试的STUN服务器在确定我的本地和映射地址时没有问题。