База знаний (цифровой суверенитет)
База знаний (цифровой суверенитет)
  • A
    1,168
    0
    A

    Пойду по второму варианту, но непонятно как остальные порты пробрасывать из контейнера наружу, там же есть целый диапазон с 50000 udp до 60000 udp

    0
  • A
    1,168
    0
    A

    Да, пробросить диапазон UDP-портов (например, 50000–60000) из контейнера наружу возможно, но Incus proxy device имеет ограничения: он отлично работает для отдельных портов или небольших диапазонов, но для больших диапазонов (10 000+ портов) — это не самый удобный и производительный способ.

    Вот реальные варианты для твоего случая (WebRTC/Kurento использует большой диапазон UDP для медиа-трафика).

    Вариант 1 — Рекомендуемый для больших диапазонов: используй Incus network forward (не proxy)

    Incus позволяет делать network forward — это DNAT/SNAT на уровне сети, а не прокси-процесс. Работает для UDP и поддерживает диапазоны портов.

    1. Узнай имя твоей сети (обычно incusbr0 или default😞

      incus network list

      Предположим, сеть называется incusbr0 (или default).

    2. Добавь forward для диапазона UDP (пример: 50000–60000 на внешний IP хоста → контейнер):

      # Сначала добавь forward на IP хоста (если нужно несколько IP — повтори)
incus network forward create incusbr0 91.221.70.18  # или твой публичный IP хоста

# Теперь добавь порт-форвард для диапазона
incus network forward port add incusbr0 91.221.70.18 udp 50000-60000 10.155.64.99 50000-60000
      • 91.221.70.18 — внешний IP хоста (или 0.0.0.0, если все IP).
      • 10.155.64.99 — внутренний IP контейнера.
      • Диапазон 50000-60000 пробрасывается 1:1 (порт 50000 хоста → 50000 контейнера и т.д.).

    3. Проверь:

      incus network forward list incusbr0
incus network forward port list incusbr0 91.221.70.18

      Если нужно удалить — incus network forward port remove ... и incus network forward delete ....

    Преимущества:

    • Работает для тысяч портов без создания тысяч устройств.
    • Низкая нагрузка (это kernel-level NAT, а не userspace-прокси).
    • Поддерживает UDP полностью.

    Минусы:

    • Нужно знать внешний IP хоста.
    • Не работает, если у тебя NAT или несколько публичных IP без явного указания.

    Вариант 2 — Если диапазон не очень большой (до 1000–2000 портов): несколько proxy-устройств

    Incus proxy поддерживает диапазоны в формате start-end (но не очень большие — производительность падает, и есть лимит на количество устройств).

    Пример:

    incus config device add incus-openvidu rtp-range proxy \
    listen=udp:0.0.0.0:50000-60000 \
    connect=udp:127.0.0.1:50000-60000

    Важно:

    • Это работает, но для 10k портов может быть медленно (каждый порт — отдельный процесс/сокет в прокси).
    • Рекомендуется только для небольших диапазонов (до 1000–2000).
    • Если диапазон слишком большой — Incus может отказать или контейнер упадёт.

    Вариант 3 — Полный проброс сети (macvlan или routed) — если нужно всё сразу

    Если диапазон огромный и часто меняется — лучше дать контейнеру свой публичный IP (или bridged-сеть без NAT):

    # Создай macvlan-интерфейс на хосте
incus network create public-macvlan --type=macvlan parent=eth0  # eth0 — твой внешний интерфейс

# Прикрепи к контейнеру
incus config device add incus-openvidu eth1 nic network=public-macvlan name=eth1

# Дай контейнеру публичный IP (если провайдер позволяет)
incus config device set incus-openvidu eth1 ipv4.address=91.221.70.xx/xx

    Тогда контейнер будет виден напрямую в сети, и внешний Nginx на хосте сможет проксировать по этому IP.

    Но это требует, чтобы провайдер/сеть позволял несколько MAC/IP на одном порту.

    Рекомендация для тебя

    • Для 50000–60000 UDP — используй network forward (Вариант 1). Это оптимально для Kurento/WebRTC.
    • Если нужно только TCP 80/443 + UDP-диапазон — комбинируй proxy для TCP и forward для UDP.
    • После настройки перезапусти контейнер (incus restart incus-openvidu) и протестируй:
      • nc -u -l 50050 внутри контейнера
      • echo "test" | nc -u 10.155.64.99 50050 с хоста → должно дойти.

    Если застрянешь на командах или увидишь ошибки — пришли вывод incus network list, incus config show incus-openvidu и точный диапазон портов (KMS_MIN_PORT и KMS_MAX_PORT из compose.yml). Я подскажу точные команды под твою конфигурацию.

    0
  • A
    1,168
    0
    A

    А какой порт используется для API? Вообще какой порт использует Nginx в Докере для Openvidu?

    0
  • A
    1,168
    0
    A

    В OpenVidu CE (в твоей версии 2.19) всё работает следующим образом:

    Компонент Порт внутри контейнера Порт, доступный снаружи (по умолчанию) Для чего используется Доступен ли для API
    openvidu-server 5443 (tcp) 4443 (tcp) Основной порт OpenVidu API и WebSocket Да, основной порт API
    nginx (openvidu-proxy) 80 (http) 80 (tcp) HTTP → HTTPS редирект + Let's Encrypt —
    nginx (openvidu-proxy) 443 (https) 443 (tcp) HTTPS + проксирование на openvidu-server Да (через /openvidu)
    coturn (TURN/STUN) 3478 (udp + tcp) 3478 (udp + tcp) WebRTC ICE / TURN relay Нет
    RTP/медиа-порты (Kurento) 40000–57000 (udp) 40000–57000 (udp) Видео/аудио-трафик WebRTC Нет

    Коротко и чётко по твоим вопросам

    1. Какой порт используется для API?
      4443 (https) — это прямой порт OpenVidu API и WebSocket (https://media2.nbics.net:4443/openvidu/api/...).

      Но в реальности большинство людей (и твой NBICS-сервис) используют 443 через nginx-прокси:
      https://media2.nbics.net/openvidu/api/...
      (nginx на 443 → проксирует на внутренний 5443).

      То есть реально используются два варианта:

      • Прямой: 4443
      • Через прокси (рекомендуемый и чаще всего используется): 443

    2. Какой порт использует Nginx в Docker для OpenVidu?
      Nginx внутри контейнера слушает:

      • 80 — для HTTP и Let's Encrypt-челленджа
      • 443 — для HTTPS и основного проксирования

      Эти порты пробрасываются наружу как есть (80 → 80, 443 → 443), потому что в docker-compose.yml используется network_mode: host.

      Поэтому внешне ты видишь:

      А порт 4443 — это уже не nginx, а сам openvidu-server (его обычно никто не открывает напрямую, если есть nginx).

    Что важно для твоего случая (NBICS)

    Твой сервис вебинаров, скорее всего, обращается к одному из этих адресов:

    Проверь в коде/конфиге NBICS, какой именно URL используется.
    Если там 443 — то на новом сервере тебе нужно сделать доступным именно 443 (через Incus proxy или внешний Nginx на хосте).
    Если там 4443 — то нужно пробросить 4443.

    Если скажешь, какой именно URL сейчас используется в NBICS (с :4443 или без), я подскажу точную команду для проброса.

    0