Брандмауэр блокирует соединение со вторым сервером WebSocket - PullRequest
0 голосов
/ 11 декабря 2018

Короче говоря, у нас есть два отдельных сервера для нашего веб-приложения.Первый - это основной сервер, который использует Websockets для работы с «чатами», а второй сервер обрабатывает только аудио-чаты WebRTC через Websocket.Оба сервера используют Express для создания HTTPS-сервера, используют защищенный Websocket и порт 443.

Недавно я столкнулся с проблемой, когда брандмауэр корпоративного клиента блокировал соединение wss только с сервером WebRTC.Ошибка, зарегистрированная в браузере пользователя, была «ERR_CONNECTION_TIMED_OUT», что означает, что пользователь никогда не подключается через Websocket.Это не произошло ни с какими другими клиентами.

Соединение Websocket нормально работает между пользователем и главным сервером, и в их брандмауэр не было добавлено никаких правил для использования нашего приложения.

Есть кто-нибудьсталкивались с чем-то похожим?Какие настройки брандмауэра могут вызвать это?Может ли это быть проблемой cors, поскольку серверы находятся в своих собственных поддоменах?

Ответы [ 2 ]

0 голосов
/ 19 января 2019

Проблема заключалась в том, что основной сервер WebSocket использовал TCP, а сервер WebRTC использовал UDP, а UDP был заблокирован корпоративным брандмауэром по умолчанию.

WebRTC должен использовать TCP в качестве резервной копии, но я предполагаю, что UDPвсе еще нужен для рукопожатия.

0 голосов
/ 18 января 2019

Основной сервер может ограничивать тип данных, отправляемых через порт 443, который будет использовать SSL для защиты передаваемых данных.

Обратитесь к этой странице для получения информации о «общеизвестном порте».numbers ".

Может потребоваться передача аудиоданных WebRTC на свой собственный выделенный номер порта, который был настроен для этого на главном сервере.

...