Я посмотрел настройки сервера STUN в openfire, и это утверждение оттуда:
"Для того, чтобы выступать в качестве сервера STUN, требуются два разных общедоступных IP-адреса на одном компьютере, а также два разных номера порта для каждого IP-адреса.
Я исследовал Google, и, как правило, оглушающим серверам нужны два общедоступных IP-адреса, что является причиной этого?
Потому что в некоторых редких случаях поведение NAT-трансляции является функцией целевого IP-адреса. Значит, вы должны "пинговать" два разных IP-адреса, чтобы найти точное поведение NAT (зависит от целевого IP-адреса или нет?)
Если вы "ping" дважды на одном сервере с двумя отдельными портами, это не будет правильно покрывать этот случай (т.е. вы не будете покрывать все ваши базы).
P.S.: Два IP-адреса не обязательно должны быть на одном сервере, это могут быть разные серверы.
При попытке установить P2P-связь, запрос STUN-привязки и ответ на/из первичного адреса службы STUN (IP и порт) - это все, что действительно имеет значение. Отображенный адрес, возвращенный в тело ответа этого запроса, передается (через XMPP или другую службу) удаленному node, который локальный клиент пытается установить с помощью прямой связи.
Второй IP-адрес и порт, которые прослушивает служба STUN, полезны для определения поведения отображения NAT-порта и поведения фильтрации NAT.
Выполняя запросы привязки к альтернативному IP: порту службы, клиент может обнаружить, имеет ли его NAT последовательную семантику сопоставления для локальных портов. В случае, если он получает разные значения сопоставления портов для каждого теста, клиент может заключить, что он находится за "симметричным NAT", которые наиболее трудно пересечь для P2P.
Отправляя запрос на связывание с атрибутом "запрос на изменение", который запрашивает службу для ответа от другого IP-порта или порта, клиент может определить, может ли его NAT просто фильтровать дейтаграммы с удаленных хостов на основе IP и порта или позволяет для дейтаграмм из альтернативных портов на хостах он отправил исходящие датаграммы на.
Поведение отображения и тесты фильтрации предоставляют ограниченную информацию для последующих соединений P2P. В случае определения симметричного NAT между хостом и Интернетом некоторые реализации могут наблюдать за NAT, чтобы иметь последовательное инкрементное значение порта в каждом ответе привязки. (например, внешний порт, наблюдаемый службой STUN, увеличивается на единицу). Таким образом, клиент может предложить IP-адрес и угадать номер порта для удаленного клиента, чтобы попытаться отправить его вместо того, который был отображен обратно из первого запроса привязки. Или клиент может использовать этот тест поведения/фильтрации для ведения журнала. Или автоматически назначить реле в случае симметричного NAT.
Я предполагаю, что требуется определить тип выполняемого NAT - какой-либо NAT будет использовать один и тот же исходный IP-адрес и кодировать идентификатор сеанса через номер порта (я думаю, что он называется cone NAT, но не уверен) некоторые NAT будут использовать комбинацию исходного IP и порта для кодирования идентификатора сеанса. Ответ на сервер STUN должен дать клиенту разное в зависимости от типа NAT.