Jingle/test

Конфигурация сети

• Binary: Primary: Indepndent Mapping, Port Dependent Filter, preserves ports, no hairpin
• Leksey: Primary: Indepndent Mapping, Port Dependent Filter, random port, no hairpin (nat на базе pf с nat on $ext_if from $int_net to any -> $ext_addr)
• leksey@дома: Primary: Port Restricted Nat, preserves ports, no hairpin (natd, FreeBSD 7.0 natd_enable="YES")
• b108: Primary: Indepndent Mapping, Port Dependent Filter, preserves ports, no hairpin (Return value is 0x000017)

Версии ПО

• Empathy версия 2.30.2 из Ubuntu 10.04.1 LTS (lsb_release -a) - настройки STUN в этом клиенте нету. Может брать из SRV? Но надо тогда чтобы у обоих JID был прописан у сервера?

Результаты

• Empathy leksey => Gmail leksey' pal в браузере под MS Windows (ставится плагин бинарный в браузер, чтоб можно было звонить) = голос слышали на стороне MS Windows, изображения не было (не умеет? или не сработало?)
• Empathy leksey => Gajim binary - не получилось установить соединение, кроме того, встретился баг Gajim с тем что клиент после первой попытки соединения полагает что оно уже установлено и отвергает последующие
• Empathy leksey <=> Empathy leksey' soworker - все работало - кроме звука в одну сторону. Но машины были в одной локалке при этом.
• Empathy leksey <=> Empathy b108 (21 April 2011) - не установилось даже соединение
• HabaHaba leksey <=> Empathy b108 (21 April 2011) - голос в обе стороны работал. но проблема что после минуты-другой падал флэш хабовский.

Клиенты которые следует проверить

• Psi c Psimedia (в генте есть пакет psimedia, который вроде ставится и на обычную пси)
• Psi+ c Psimedia
• Gajim
• Jitsi
• Habahaba

---

• В дебиане кривая сборка Psi+ - падает.
• Jitsi нет в репозитариях Ubuntu

Которые нет смысла проверять

• Gajim для MS Windows - тот фреймворк что они используют для виндоза отсутствует

Определение конфигурации

Берется из вывода stun-клиента, запущенного следующим образом. Версия для MS Windows, FreeBSD, Ubuntu (sudo apt-get install stun)

stun_client stun.xten.com

MS Windows

client.exe stunserver.org

Описание NAT

Random port означает, что данная реализация NAT не заботится о том, чтобы номер порта источника в исходящем наружу пакете оставался таким же, каким он был получен от хоста локальной сети, и заменяет его на случайное значение в диапазоне от 1024 до 65535. Можно предположить, что по замыслу автора идеи «random ports» такая замена уменьшает вероятность конфликта между записями, если несколько хостов локальной сети одновременно попытаются отправить наружу пакеты с совпадающим номером порта источника.

Поскольку номер порта источника в исходящих пакетах формируется хостами локальной сети также случайным образом, преимущества такой замены сомнительны, из недостатков же можно назвать хотя бы потенциальную проблему с протоколом RPC, да и не только.

Как видно из примера, наш маршрутизатор старается сохранять номер порта неизменным (11.22.33.44:1053 и 192.168.0.141:1053), из чего следует, что запущенный в его локальной сети STUN-клиент сообщил бы о нем preserves ports.

К слову, на FreeBSD этот результат достигается ключом «-same_ports» или «-s» в строчке запуска или конфигурационном файле демона natd. Есть возможность поставить ключ и проверить?

FreeBSD, Psi 0.14 + Psi-media

Внешний IP с единственной настройкой в rc.conf ifconfig_age0="dhcp"

Проблема - случайно выбирается порт для установления соединения, что не позволяет работать когда на одной из сторон NAT. Видимо, psi не делает специального указания, с какого порта слать

• Сменен порт в настройках Psi (в поле Data transfer base port) с 8010 на 49152 (в соответствие с The Ephemeral Port Range). Поле Data transfer externak adress для указания "внешнего" адреса при работе со STUN и поэтому оно должно быть пустым.

Не помогло.

• Выключена рандомизация (Ports are allocated at random within the specified port range in order to increase the difficulty of random spoofing attacks) sysctl net.inet.ip.portrange.randomized=0

После этого вместо рандовного выбора - стало последовательно наращивать адреса, но тоже выбирая рандомно их диапазон.

18:42:24.588741 IP 89.250.8.14.51357 > 217.25.221.127.60529: UDP, length 92
51357 != 49152