Вопрос или проблема
После прочтения документации по серверу LiveKit здесь и ознакомления с примером конфигурации здесь, я действительно не уверен, как можно удовлетворить заданные требования (даже с использованием нескольких доменов и/или IP-адресов).
Проблема следующая:
- Для wss:// (канал сигнализации) они требуют:
Вам также нужно будет настроить HTTPS/SSL терминацию с балансировщиком нагрузки или обратным прокси.
- Для TURN они требуют:
# по умолчанию 3478 - рекомендуется 443, если не работает HTTP3/QUIC сервер
# # только 53/80/443 разрешены, если меньше 1024
# udp_port: 3478
# # по умолчанию 5349 - если не используется балансировщик нагрузки, это должно быть установлено на 443
# tls_port: 5349
LiveKit выполнит терминацию TLS, поэтому вам нужно будет указать сертификаты в конфигурации. При запуске нескольких экземпляров LiveKit вы можете разместить балансировщик нагрузки уровня 4 перед TCP-портом.
Если вы не используете балансировщик нагрузки, turn.tls_port должен быть установлен на 443, так как это будет порт, который будет рекламироваться клиентам.
Таким образом, оказывается, что для Сигнализации они хотят 443 порт с обратным прокси. Обратный прокси будет слушать порт 443, завершать SSL и перенаправлять простой трафик на LiveKit. Затем для сервера TURN они снова хотят порт 443, но теперь они диктуют, что он не должен быть за обратным прокси. По крайней мере потому, что они все равно будут рекламировать клиентам порт, указанный в конфигурации LiveKit. Так что, если я хочу использовать порт 443 для TURN, так как это лучший вариант для ограниченных сетей, я должен указать его напрямую в конфигурации LiveKit. Но я не могу этого сделать, потому что этот порт уже используется обратным прокси для канала сигнализации.
Таким образом, конфликт заключается в следующем:
- Порт 443 используется обратным прокси, потому что LiveKit не управляет SSL-сертификатами для сигнализации и полагается на обратный прокси для SSL терминации для сигнализации.
- Они требуют, чтобы порт 443 использовался для TURN/TLS
- Они рекламируют порт, указанный в конфигурации LiveKit, клиентам, так что это должен быть порт, который виден клиентам. Поэтому я не могу использовать обратный прокси для TURN/TLS. Если я это сделаю, порт, рекламируемый клиентам, будет отличаться от фактически используемого порта.
- LiveKit не позволяет слушать порт только на одном IP, он слушает все интерфейсы. Таким образом, добавление второго IP не решает конфликт.
- Они требуют отдельного хоста (например, turn.yourserver.com) для TURN, но я не вижу, как это может решить проблему с конфликтующими портами (и не понимаю, зачем это вообще нужно).
Я что-то упускаю?
Ответ или решение
Ваша проблема с конфигурацией сервера LiveKit действительно вызывает значительные затруднения, учитывая необходимость совмещения использования порта 443 как для веб-сигнализации, так и для сервера TURN. Давайте детально рассмотрим, как эту проблему можно решить.
Теория
Основная задача заключается в удовлетворении требований LiveKit по использованию порта 443 для обоих сценариев: это обязательное использование этого порта для TURN-сервера в целях обеспечения непрерывности связи в ограниченных сетях и необходимость SSL-терминации для веб-сигнализации через reverse proxy. Порт 443 обычно используется для зашифрованного веб-трафика, и нам необходимо обойти его конфликты.
Пример
-
Веб-сигнализация через WSS (WebSocket Secure) требует установления SSL-сертификатов через реверсивный прокси типа Nginx или HAProxy, которые прослушивают порт 443. В этом сценарии трафик шифруется на уровне прокси и отправляется внутрь на сервер LiveKit без шифрования.
-
TURN-сервер также требует использования 443 порта, особенно если у вас нет балансировщика нагрузки. В конфигурации TURN-сервера указывается, что TLS-верификация производится самим LiveKit, что подразумевает необходимость прямого обращения к LiveKit по порту 443 для TLS-трафика.
Применение
Для решения конфликта можно использовать следующие подходы:
-
Дополнительные IP-адреса: Хотя вы указали, что LiveKit прослушивает все интерфейсы, добавление отдельного IP-адреса для TURN-сервера позволит разделить трафик, при этом назначив раздельные сертификационные профили на реверсивный прокси и напрямую на LiveKit. Это позволит разделить функционал таким образом, что веб-сигнализация будет обрабатываться одним IP/портом, а TURN-трафик другим.
-
Резервирование доменов: Используйте различные домены, такие как signaling.yourserver.com для веб-сигнализации и turn.yourserver.com для TURN-трафика. Это обеспечит логическое разделение трафика и позволит назначить различные конфигурации SSL, хотя порт останется 443.
-
Балансировщик нагрузки уровня 4: Если у вас есть возможность, используйте балансировщик нагрузки уровня 4 для управления TCP-соединениями, который будет распределять подключения по различным Backend-серверам в зависимости от протокола, домена или начального подключения.
Рекомендуется также рассмотреть возможность консультации с более специализированными системными администраторами, которые может быть уже реализовали подобные сетевые конфигурации с LiveKit, чтобы избежать трудностей в сетевой архитектуре.
Надеюсь, данные рекомендации помогут вам в разрешении конфликта портов при конфигурации сервера LiveKit.