Не работает flashphoner при работе из-за NAT

edemin

New Member
Здравствуйте!


Переносим флешфонер на сервер в локальной сети за NAT (на NAT сервере стоит nginx для проксирования веб-сокетов) (https://docs.flashphoner.com/pages/viewpage.action?pageId=9241031). При установке флешфонера ip и ip_local корректно устанавливаются в flashphoner.properties ip=<PUBLIC_IP> (публичный IP NAT сервера), ip_local=<PRIVATE_IP>, но после рестарта сервера (systemctl restart webcallserver) ip всегда сбрасывается в 0.0.0.0. Удаляли и ставили заново флешфонер, после рестарта аналогично сбрасывается в 0.0.0.0. Не знаю с этой настройкой связано или нет, но в процессе проверки в веб-интерфейсе флешфонера (по этой инструкции https://docs.flashphoner.com/pages/viewpage.action?pageId=9241019) в логах всегда Failed by ICE timeout, я так понимаю, что это из-за UDP, но порты проброшены с NAT сервера на сервер с флешфонером (см ниже.). Также во вложении скрины правил файрвола в облаке на NAT сервере.


диапазон локальных порты исправлен
Code:
root@flashphoner:/usr/local/FlashphonerWebCallServer # sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 59999    63000
На NAT сервер настроен проброс портов на сервер с флешфонером
Code:
-A PREROUTING -d <NAT_IP>/32 -p udp -m udp --dport 30000:40000 -j DNAT --to-destination <PRIVATE_IP>:30000-40000
-A PREROUTING -d <NAT_IP>/32 -p tcp -m tcp --dport 30000:40000 -j DNAT --to-destination <PRIVATE_IP>:30000-40000
-A PREROUTING -d <NAT_IP>/32 -p tcp -m tcp --dport 1935 -j DNAT --to-destination <PRIVATE_IP>:1935
-A POSTROUTING -d <PRIVATE_IP>/32 -p udp -m udp --sport 30000:40000 -j SNAT --to-source <NAT_IP>:30000-40000
-A POSTROUTING -d <PRIVATE_IP>/32 -p tcp -m tcp --sport 30000:40000 -j SNAT --to-source <NAT_IP>:30000-40000
-A POSTROUTING -d <PRIVATE_IP>/32 -p tcp -m tcp --sport 1935 -j SNAT --to-source <NAT_IP>:1935

Конфиг nginx (который находится на NAT сервере) на котором происходит проксирование на сервер флешфонера
Code:
server {

server_name <domain>;
listen 8443 ssl;
keepalive_timeout 70;

ssl_certificate /etc/nginx/ssl/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/privkey.key;
ssl_session_cache shared:SSL:100m;
ssl_session_timeout 1h;


location / {
proxy_pass https://<PRIVATE_IP>:8443;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_read_timeout 86400;
}
access_log /var/log/nginx/flashphoner-access.log;
error_log /var/log/nginx/flashphoner-error.log;

}

Что еще можно посмотреть?
 

Attachments

Max

Administrator
Staff member
Конфигурация выглядит не совсем корректно. При такой конфигурации, если она заработает, весь медиа трафик пойдет через сервер, на котором установлен nginx. Тогда теряется смысл выделения WCS в отдельный сервер. WCS должен обрабатывать медиатрафик напрямую.
Т.е. nginx вполне может проксировать вебсокеты. Но при этом, в IP должен быть указан прямой внешний адрес WCS сервера для более эффективной работы. Проброс медиатрафика за NAT может также вносить дополнительные потери и влиять на качество видео.

но после рестарта сервера (systemctl restart webcallserver) ip всегда сбрасывается в 0.0.0.0
Не понятно, где конкретно сбрасывается IP адрес? Прямо в настройки прописывается?
Используете облачный хостинг? Какой?
Возможно поможет отключение проверок в скрипте запуска WCS_HOME/bin/webcallserver.sh

Попробуйте закомментировать проверки:
Code:
#check_amazon
#check_google
Ложное срабатывание проверок может влиять на прописывание адресов в конфиге.

1603819181687.png


Что еще можно посмотреть?
Скорее всего проблема в том, что прописывается не тот IP адрес в конфиг.
Если это так, отключение проверок должно помочь.

Дополнительно можно проверить доступность портов с помощью nc.

Размещать сервер за NAT рекомендуется после выхода в продакшен или непосредственно перед выходом, чтобы исключить сетевые проблемы при установке WebRTC соединений.
 

Max

Administrator
Staff member
Попробуйте закомментировать проверки:
Вместо этого можно добавить в файл flashphoner.properties настройку
Code:
hold_ip_settings=true
Эта настройка отключает автоматическое определение IP адресов при старте
Также просим сообщить, какой именно облачный хостинг используется, либо предоставить нам доступ к серверу, используя эту форму, чтобы мы могли воспроизвести проблему с определением IP адресов.
 

edemin

New Member
Используете облачный хостинг? Какой?
Используем Яндекс Облако.

Попробуйте закомментировать проверки:
Code:
#check_amazon
#check_google
Ложное срабатывание проверок может влиять на прописывание адресов в конфиге.
Да, это действительно помогло и больше проблема не воспроизводилась, также добавили в файл flashphoner.properties
Code:
hold_ip_settings=true
Спасибо за помощь!
 

Max

Administrator
Staff member
Используем Яндекс Облако.
В сборке 5.2.759 был фикс определения IP адресов для облачных провайдеров, использующих Google-совместимое API. Если Вы по-прежнему используете сборку 5.2.709, попробуйте обновить до последней сборки отсюда
Также есть тикет WCS-2868 по тестам совместимости с Яндексом.
 

edemin

New Member
В сборке 5.2.759 был фикс определения IP адресов для облачных провайдеров, использующих Google-совместимое API. Если Вы по-прежнему используете сборку 5.2.709, попробуйте обновить до последней сборки отсюда
Также есть тикет WCS-2868 по тестам совместимости с Яндексом.
У нас версия v.0.5.28.2753-5.2.795. Но наверное у Яндекса вряд ли google совместимое API.
 

Max

Administrator
Staff member
Но наверное у Яндекса вряд ли google совместимое API.
По документации Яндекса, это так. Более того, декларируется, что AWS EC2 API также поддерживается. Скорее всего, есть какие-то отличия. Мы этим занимаемся в тикете WCS-2868, сообщим о прогрессе в этой теме.
Пока Вам лучше эксплуатировать сервер с отключенным автооопределением адресов.
 

Max

Administrator
Staff member
Мы протестировали развертывание сервера с нуля в Yandex.Cloud. На актуальной сборке 5.2.798 проблема не воспроизводится, IP адреса определяются корректно с использованием AWS EC2 API (поскольку эта проверка стоит на первом месте в скрипте запуска).
В связи с этим, если в Вашей конфигурации инстанса проблема продолжает воспроизводиться, просим предоставить SSH доступ к инстансу для проверки при помощи этой формы.
 

edemin

New Member
Мы протестировали развертывание сервера с нуля в Yandex.Cloud. На актуальной сборке 5.2.798 проблема не воспроизводится, IP адреса определяются корректно с использованием AWS EC2 API (поскольку эта проверка стоит на первом месте в скрипте запуска).
В связи с этим, если в Вашей конфигурации инстанса проблема продолжает воспроизводиться, просим предоставить SSH доступ к инстансу для проверки при помощи этой формы.
После комментирования строк в файле WCS_HOME/bin/webcallserver.sh, где check облаков происходит и добавления в конфиг параметра hold_ip_settings=true все заработало. При случае обновимся до 5.2.798. Спасибо за помощь!
 
Top