Спасибо! Вроде теперь сложилась полная картина.
coturn настраивал по инструкции тут
https://docs.bigbluebutton.org/2.2/setup-turn-server.html
затем в applicationContext.xml изменил p:turnUrl="myserver:port" и в
p:turnSecret="" вставил значение переменной static-auth-secret из
конфига coturn-a
Надо ли в настройках KMS в файле WebRtcEndpoint.conf.ini выставлять
переменные stunServerAddress и turnURL?
И последний вопрос (я надеюсь). Для чего в Docker контейнер
расшаривается директория webapps/openmeetings/data ? Если она нужна для
нужд Kurento-Media-Server как он "догадывается", что имено в
webapps/openmeetings/data необходимые данные?
Доброй ночи,
Евгений
В случае бриджа надо ли
On 5/12/20 1:54 AM, Konstantin Kuzov wrote:
Если настроен 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, но я решил спросить здесь,
поскольку надеялся найти опытных пользователей, кто уже сталкивался с
подобным.
Извиняюсь с большое количество текста, хотел максимально подробно
описать конфигурацию.
С уважением, Евгений
