Если настроен TURN, то клиенты коннектятся к KMS через него, а не напрямую на порт 8888. Соответственно без разницы на каком там он ипшнике сидит, главное чтобы клиенты могли достучаться до TURN-сервера. STUN и TURN могут жить на одном и том же порте, к примеру дефолтном 3478, и их лучше не заносить на разные порты для упрощения конфигурации. Диапазон UDP-портов для TURN которые надо открыть указываются в конфиге coturn в min-port/max-port. По умолчанию согласно rfc5766 это 49152-65535. Можете попробовать взять turnserver-no-tls.conf за основу, прописав свои ипшники, домен и пароли. При этом нужно не забыть прописать p:turnUrl и p:turnSecret для OM в webapps/openmeetings/WEB-INF/classes/applicationContext.xml.
Рабочую строчку запуска KMS в docker можно глянуть в reinstall-kms-docker.sh. Основное тут что не надо пытаться изменить WebRtcEndpoint.conf.ini через подсовывание переменных типа KMS_EXTERNAL_ADDRESS, он должен быть пустой. Что касается "--network host", это заставляет docker использовать тот же namespace что и хост, вместо дефолтного режима моста с отдельным namespace (обычно с адресами 172.17.x.x). Т.е. выключить изоляцию и использовать сетевой стек хоста напрямую, приложения запущенные там будут использовать сеть и биндиться к любым портам хоста как будто они запущены прямо на хосте, а не в контейнере. Подробнее можно прочитать в документации к docker. Но docker с KMS в режиме бриджа с "-p 8888:8888", как и рекомендуют в туториалах, тоже полностью рабочая конфигурация. пн, 11 мая 2020 г. в 19:20, Eugene <roginovi...@hotmail.com>: > Благодарю за ответ! > > Считаю необходимым дать подробное описание конфигурации сети и системы. > > $ cat /etc/os-release > > PRETTY_NAME="CentOS Linux 8 (Core)" > > Внутренняя сеть организована таким образом, что находится в сегменте > 192.168.104.1/24. В сервере установленно несколько сетевых карт. Одна из > которых у провайдера получает ip из сегмента 10.0.0.1/16 по dhcp, а все > остальные "собраны" в мост br0 которому присвоен ip 192.168.104.14. > Выход в интернет через vpn туннель с именем интерфейса ppp0. Для выхода > из "домашней" сети в мир установлены правила маршрутизации: > > $IPTABLES -t nat -A POSTROUTING -o enp6s0f1 -j MASQUERADE > $IPTABLES -t nat -A POSTROUTING -o ppp0 -j MASQUERADE > $IPTABLES -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS > --clamp-mss-to-pmtu > > где enp6s0f1 -- сетевой интерфейс с адресом из сегмента 10.0.0.1/16 (тот > что выдает провайдер по dhcp). > > На время настройки OpenMeetings файервол максимально упрощен. После > старта Kurento-Media-Server (KMS) через docker start kms (как по > инструкции) выхлоп iptables -L: > > Chain INPUT (policy ACCEPT) > target prot opt source destination > ACCEPT all -- anywhere anywhere > ACCEPT all -- anywhere anywhere > > Chain FORWARD (policy ACCEPT) > target prot opt source destination > TCPMSS tcp -- anywhere anywhere tcp > flags:SYN,RST/SYN TCPMSS clamp to PMTU > ACCEPT all -- anywhere anywhere > ACCEPT all -- anywhere anywhere > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > > Chain DOCKER (0 references) > target prot opt source destination > ACCEPT tcp -- anywhere 172.17.0.2 tcp > dpt:ddi-tcp-1 > > KMS сервер крутится и доступен из внутренней сети. > > $ netstat -lntp | grep 8888 > tcp6 0 0 :::8888 :::* LISTEN > 10707/docker-proxy > > $ netstat -lnutp | grep 3478 > tcp 0 0 внешний_ip:3478 0.0.0.0:* LISTEN 4724/turnserver > tcp 0 0 192.168.104.14:3478 0.0.0.0:* LISTEN > 4724/turnserver > tcp 0 0 10.0.0.50:3478 0.0.0.0:* LISTEN 4724/turnserver > tcp 0 0 127.0.0.1:3478 0.0.0.0:* LISTEN > 4724/turnserver > tcp6 0 0 ::1:3478 :::* LISTEN > 4724/turnserver > > + несколько копий но порты udp > > $ netstat -lntup | grep 8888 > tcp6 0 0 :::8888 :::* LISTEN > 10707/docker-proxy > > $ netstat -lntup | grep 5349 > > Примерно также как и с портом 3478 > > Проверка STUN на > https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ > > Done и для STUN на порту 3478 и для TURN на порту 5349 > > Я думаю тут что-то с настройками интерфейса docker контейнера. Сейчас в > девелопмент git ветке вышла KMS версии 7.0 которая не привязана к форку > gstreamer 1.5 и мне ее вроде удалось собрать под CentOS 8 (относительно > безболезненно), но работать даже с тестом hello-world она отказывается. > > Еще заметил, что когда клиент из "внешнего" мира пытается соедениться с > мультимедиа сервером он обращается по адресу 172.17.0.2 -- это адрес > docker контейнера и если соединение из "домашней" сетки доходит до > адрессата, то из внешнего мира такие покеты просто теряются. Подозреваю > если на клиенте сделать подмену адресов, то все заработет, но это не > универсальное решение. > > Я не очень хорошо чувствую пока работу docker контейнеров, но я даже > пробовал пробросить 8888 порт, и это не особо помогает. Играл я и с ssh > тунелями, 8888 порт я могу пропустить на docker контейнер, но что делать > с прорвой udp портов? > > Как я понимаю работу docker, он создает мост docker0 и добавляет в него > интерфейсы с забавными именами типа veth594ffca, все соединения за > docker0 маскируются. Получается, что у меня сейчас что бы "достучаться > до" KMS надо пройти два NAT'a сначала на интерфейсе docker0 (пакеты от > kms контейнера с адресом 172.17.0.2 маскируются мостом docker0 с адресом > 172.17.0.1), а затем на ppp0 с реальным ipv4 адресом глобальной сети. Но > ведь такая настройка рекомендуется в туториал... Вероятно, проблема > больше относиться к KMS чем к OpenMeetings, но я решил спросить здесь, > поскольку надеялся найти опытных пользователей, кто уже сталкивался с > подобным. > > Извиняюсь с большое количество текста, хотел максимально подробно > описать конфигурацию. > > С уважением, Евгений > >
