Я не мог установить соединение льда между двумя клиентами в той же локальной сети, используя кандидата srvflx

Question

То, что я пытаюсь сделать, это создать тестовый скрипт (javascript), чтобы проверить, может ли клиент подключаться через «серверные рефлексивные кандидаты».

Я скопировал скрипт из test.webrtc.org, где он в основном создает два одноранговых узла и отправляет некоторый текст через канал данных и проверяет, получают ли обе стороны текст или нет.

Проблема, которую я получаю, заключается в том, что мое «состояние подключения к льду» изменится с «проверки» на «сбой».

Я знаю, что мой браузер (хром) может подключаться через «серверные рефлексивные кандидаты», и мы не используем Symmetric NAT.

Я знаю, что в нормальных условиях, когда оба клиента находятся в одной и той же локальной сети, они почти всегда будут подключаться через «кандидатов хозяевах» (иногда с помощью кандидатов-ретрансляторов, не знаю, почему)

Единственная причина, почему я «принуждение» его для подключения через «серверные рефлексивные кандидаты», потому что я хочу создать тестовый скрипт, чтобы наши пользователи могли самостоятельно проверять, к каким кандидатам подключаются их браузеры.

Сценарий соединение может быть описано, как показано ниже:

Клиент A Источник - Локальный IP - 192.168.1.142 - Source Port - 52245 Клиент A Назначение - Remote IP - 99.99.99.99 - Destination Port - 43353

Client B Источник - Локальный IP - 192.168.1.110 - Source Port - 43353 Client B Назначение - Удаленный IP - 99.99.99.99 - Destination Port - 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 

Я не уверен, что это связано с поведением маршрутизатора, и я не вижу никаких настроек, связанных с указанным выше в консоли администратора маршрутизатора, поэтому я изменил их на разные маршрутизаторы, и я все равно получаю одинаковые результаты описано. Это потому, что соединение, подобное выше, не разрешено?

[EDIT - Включить маршрутную таблицу]

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 

Answer 1

Для перенаправления пакетов, поступающих от внутреннего IP на другой внутренний IP не поддерживаются всем NAT. Это называется Hairpinning. Пример из 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 поддерживает hairpinning, то приложение P1 может подключаться к приложению P2 с помощью внешняя конечная точка 192.0.2.1:5555. Если нет, сообщение не будет работать.

, когда оба клиента находятся в одной и той же локальной сети, они почти всегда будут подключаться через «кандидатов хозяевах» (иногда с помощью кандидатов-ретрансляторов, не знаю, почему)

Это может произойти только, если один или оба из хост заблокировал IP-адрес другого. Кроме того, нет возможности для двух устройств в одной локальной сети не иметь хост-соединение с хостом.

Answer 2

Я смог установить соединение льда между двумя клиентами в той же локальной сети, используя кандидатов srvflx, только посредством VPN-туннелирования одного клиента.

Соединение никогда не будет успешным без использования VPN.

STUN-серверы, которые я тестировал у туннелированного клиента VPN, не имели проблем с определением локальных и отображаемых адресов.