Я пытаюсь запустить службу WebRTC через корпоративный брандмауэр. Служба работает в локальной сети, но похоже, что брандмауэр не позволяет ей работать в глобальном масштабе.
Я использую пример кода из Python aiortc пакет, найден Вотс незначительным добавлением URL-адреса STUN-сервера как на стороне клиента, так и на стороне сервера.
Клиентская сторона, похоже, работает должным образом и правильно отправляет свой внешний IP-адрес в качестве кандидата ICE.
Однако серверная сторона отправляет кандидатов только с локальными адресами. Похоже, STUN заблокирован.stunclient возвращает следующее:
$ stunclient --verbosity 9 --mode full --localaddr eno1
stun.stunprotocol.org
Resolved stun.stunprotocol.org to 52.15.67.208:0
config.fBehaviorTest = true
config.fFilteringTest = true
config.timeoutSeconds = 0
config.uMaxAttempts = 0
config.addrServer = 52.15.67.208:3478
socketconfig.addrLocal = <MyLocalIp>:0
Sending message to 52.15.67.208:3478
Continuing to wait for response...
...
Continuing to wait for response...
Sending message to 52.15.67.208:3478
Continuing to wait for response...
...
Continuing to wait for response...
Binding test: fail
Behavior test: fail
Filtering test: fail
Другие серверы STUN также выходят из строя.
Я думаю, это вызвано тем, что брандмауэр блокирует что-либо, кроме TCP, на порту, который я использую для HTTPS.
Как следует настроить брандмауэр, чтобы разрешить STUN и WebRTC?
Спасибо!
Я сопровождаю stun.stunprotocol.org и сам код каскадера. Просто так случилось, что немного поздно уловил ваш вопрос. Обычно я отслеживаю вопросы об оглушении на stackoverflow.com, но лишь изредка дохожу до serverfault.
Да, похоже, ваш брандмауэр блокирует трафик на оглушающий сервер. Это не является неожиданностью для крупных предприятий.
STUN по умолчанию работает на портах UDP, а не TCP. Вы можете попробовать указать --protocol tcp на stunclient командная строка, чтобы увидеть, имеет ли это значение. Но WebRTC использует только режим UDP. Одна интересная идея - разместить собственный сервер оглушения на 53-м UDP-порту (так же, как DNS) и посмотреть, работает ли это. Опять же, предприятия могут ограничивать трафик DNS хорошо известными или внутренними серверами.
Вашему ИТ-администратору следует попросить «открыть доступ к удаленному серверу, который прослушивает UDP-порты 3478 и 3479». Если они действительно откроют эти порты, вы можете обнаружить, что корпоративный брандмауэр действует как симметричный NAT и плохо справляется с включением соединений WebRTC. YMMV.