Относительно анализа типа nat

Question

Я загрузил оглушающего клиента с http://www.stunprotocol.org/ и попытался выяснить тип NAT по команде stunclient --mode full stun.stunprotocol.org --verbosity 9, и я получил ответ ниже.

config.fBehaviorTest = true 
config.fFilteringTest = true 
config.timeoutSeconds = 0 
config.uMaxAttempts = 0 
config.addrServer = 52.86.10.164:3478 
socketconfig.addrLocal = 0.0.0.0:0 
Sending message to 52.86.10.164:3478 
Got response (68 bytes) from 52.86.10.164:3478 on inter 
Other address is 52.201.75.212:3479 

Sending message to 52.201.75.212:3478 
Got response (68 bytes) from 52.201.75.212:3478 on inte 
Sending message to 52.201.75.212:3479 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Sending message to 52.201.75.212:3479 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Sending message to 52.86.10.164:3478 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Sending message to 52.86.10.164:3478 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Sending message to 52.86.10.164:3478 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Sending message to 52.86.10.164:3478 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Continuing to wait for response... 
Binding test: success 
Local address: 10.64.60.58:58841 
Mapped address: 125.19.34.60:24604 
Behavior test: fail 
Filtering test: success 
Nat filtering: Address and Port Dependent Filtering 

Я работаю в корпорации и, следовательно, по соображениям безопасности, типа NAT «адрес и порт Зависимая Filtering» кажется жизнеспособным.

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

Однако поиск в google для webrtc показывает, что 90% одноранговой связи устанавливается через сам оглушающий сервер (путем пробивания отверстий и т. Д.). Это означает, что тип NAT в этом случае полностью поддерживается для установления соединения.

Есть ли у экспертов какие-либо мнения о анализе типа NAT, которые следует учитывать для обмена сообщениями со сверстниками?

Answer 1

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

Stunclient выполняет два разных набора тестов. Во-первых, это тесты «поведение отображения», что является самым важным для понимания того, как ваш NAT/Firewall будет влиять на P2P-подключение. Другой набор - это «тесты фильтрации», которые являются индикатором того, как «открыть» ваш NAT, в отношении приема трафика от других комбинаций IP/портов.

Ваш тест поведения «не удался». Вероятно, это означает, что на основе вашего логарифмического вывода:

Тест 1: Выберите случайный порт, 58841, в этом случае. Из этого локального порта выполните базовый тест привязки к stun.stunprotocol.org:3478. Здесь клиент получает ответ, в котором сервер указывает сопоставленный адрес (125.19.34.60:24604), и что альтернативный IP-адрес для последующего анализа поведения и фильтрации находится на 52.201.75.212.

Испытание 2: один и тот же локальный порт, 58851. Отправьте запрос привязки на альтернативный IP-адрес и основной порт (52.201.75.212:3478). В вашем случае, похоже, что ответ, который вернулся, скорее всего, был другим ip или портом. И в этом случае требовалось «испытание 3».

Тест 3: Один и тот же локальный порт, 58851. Отправьте запрос на привязку к альтернативному ip и альтернативному порту (52.201.75.212:3479), чтобы он мог различать между зависимыми от адреса и адресными и порт-зависимыми сопоставлениями. И это интересная часть - у вас не было ответа. Несмотря на возможность общаться с обоими IP-адресами на порту 3478. Вот почему тест вернулся как неудачный.

Может быть одна из двух вещей:

а) Ваш NAT/Firewall на самом деле открыт для порта 3478, но не 3479. ли это из командной строки для обнаружения

stunclient 52.201.75.212 3479 

И если удастся получить сопоставленный адрес, затем немедленно выполните следующее:

stunclient 52.86.10.164 3478 

Попробуйте другие комбинации этих двух IP-адресов и портов.Результирующее поведение может означать следующее: 0). Ваш NAT/Брандмауэр отказывается от карты порта при изменении обоих IP-адресов и порта. Это означает, что ваша сетевая среда еще более ограничительна, поскольку «привязка адресов и портов зависит от NAT». Более известный как симметричный NAT.

Что касается фильтрующих тестов, просто проигнорируйте этот результат. Тесты фильтрации пытаются определить, можете ли вы отправить один ip: порт, но получать от другого ip или порта. 99% времени NAT запрещают это. Таким образом, результат почти всегда приводит к «Фильтрации адресов и портов». Результат теста фильтрации не очень указывает на то, как ваш NAT будет работать с P2P-связью.

И только потому, что ваша корпоративная сеть очень ограничительна, это не означает, что вы не можете общаться с одноранговым узлом в другой сети. Если у него более корректный NAT с Endpoint Independent Mapping, то все же вероятность подключения P2P будет успешной.

Я не поддерживал тенденции NAT в последние годы, но 80-90% соединений, следующих только с STUN, звучат правильно. Остальное потребуется релейное решение, такое как TURN.

Answer 2

Я предполагаю, что вы хотите установить связь между p2p во всех возможных сценариях (включая симметрию NAT). Мое предложение: попробуйте использовать webRTC и используйте оглушение и превратите серверы в список серверов льда. это даст вам диапазон кандидатов ICE, и webRTC позаботится о подключении к лучшим кандидатам. это должно избавить вас от проблем типа NAT.