Почему WebRTC не работает с симметричным NAT?

Допустим, у нас есть два одноранговых узла - A и B - которые пытаются установить одноранговое соединение WebRTC через симметричный NAT. Они обменялись кандидатами ICE через сигнализацию.

Общий адрес A: IP_A: Port_A
Общий адрес B: IP_B: Port_B

Сначала A пытается подключиться к B
IP_A: Port_A --- ›IP_B: Port_B

Однако запрос отклоняется NAT Б. Только STUN-сервер B может подключиться к B по этому адресу.

Теперь очередь B.
IP_B: Port_B --- ›IP_A: Port_A

Но здесь, разве не следует устанавливать связь? Потому что в таблице NAT узла A должен быть зарегистрирован адрес узла B, когда A первый раз отправил запрос B. Таким образом, любой ответ от B должен быть принят. Но, конечно, похоже, что это не работает. Итак, в чем я ошибаюсь?


webrtc nat nat-traversal
person Manu Soman    schedule 15.05.2021    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Думаю, я сам нашел ответ. Симметричный NAT даже более ограничен, чем я думал. Посмотрите объяснение в Википедии,

Симметричный NAT

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

Проблема в том, что симметричный NAT будет использовать другую комбинацию IP: Port для однорангового узла A при отправке запроса узлу B, чем комбинация IP_A: Port_A, предоставляемая STUN. Но удаленное описание узла B по-прежнему указывает на IP_A: Port_A. Итак, адреса не совпадают, и соединение никогда не происходит. Возможно, система прогнозирования портов все еще могла бы сделать эту работу, я полагаю: D

person Manu Soman    schedule 15.05.2021

arrow_upward
0
arrow_downward

Это имеет гораздо больше смысла, если вы думаете в терминах сопоставления / фильтрации. Другие термины NAT не очень хорошо описывают, как все работает на самом деле. Мой ответ взят из RFC 4787 и WebRTC для любопытных: подключение

Сопоставление - это когда ваш NAT выделяет IP / порт для исходящего пакета. Удаленный узел может отправлять трафик на это сопоставление. Фильтрация - это правила, определяющие, кто может использовать эти сопоставления.

Тогда фильтрация и сопоставления могут быть адресно-зависимыми и независимыми. Если сопоставление зависит от адреса, это означает, что новое сопоставление создается каждый раз, когда вы обращаетесь к новому IP / порту. Если отображение не зависит от адреса, это означает, что оно используется повторно независимо от того, куда вы отправляете трафик. Эти же правила применяются к фильтрации.

На ваш исходный вопрос похоже, что сопоставление с адресом + фильтрация вызывает проблему!

Я все еще ожидаю, что в описанной вами настройке все будет работать. WebRTC имеет Peer Reflexive Candidates. WebRTC может обнаруживать новых кандидатов во время проверок подключения ICE. Поскольку ICE аутентифицирован, мы можем принимать трафик от IP / портов, которые не были обменены, нам просто нужно подтвердить пользовательский фрагмент ICE и пароль - это то, что мы ожидаем.

person Sean DuBois    schedule 16.05.2021