Порты и сеть

Какой слушатель за что отвечает, что открывать в межсетевом экране, как работать за обратным прокси и какие UDP-порты нужны WebRTC и RTSP.

Сервер открывает ровно те порты, которые перечислены в конфигурации. Отдельного порта у API, панели управления, метрик и плеера нет — всё это едет по HTTP-слушателю вместе с медиа.

Слушатели#

http    8080;
https   8443;
rtsp    8554;
rtsps   8555;
rtmp    1935;
rtmps   1936;
webrtc  40000 public_ip=203.0.113.10;

Правила проверки, все они срабатывают при разборе файла:

• http и rtsp обязательны и не могут быть нулевыми — http_port and rtsp_port must be non-zero;
• они должны различаться — http_port and rtsp_port must differ (both 8080);
• все ненулевые порты попарно различны — https and rtsps both use port 8443 — listener ports must be distinct;
• значение больше 65535 не проходит разбор.

0 означает «слушатель выключен» для всех портов, кроме http и rtsp.

Что открывать в межсетевом экране#

Минимум — просмотр в браузере#

Этого достаточно: HLS, LL-HLS, DASH, MSE-WS, превью и панель живут на одном TCP-порту.

Добавления по мере включения возможностей#

Порт 80 и выпуск сертификатов#

Ответчик ACME HTTP-01 обслуживается слушателем http, но удостоверяющий центр всегда обращается на порт 80. Это несовпадение — самая частая причина, по которой сертификат не выпускается.

Работают оба варианта:

# Вариант А: сервер сам слушает 80.
http  80;
https 443;

# Вариант Б: сервер на 8080, а внешний 80 пробрасывается на него
# правилом DNAT межсетевого экрана.
http  8080;
https 443;

# Проброс внешнего 80 на 8080. Первые две строки создают таблицу и цепочку,
# поэтому набор выполняется на чистой системе целиком.
sudo nft add table ip hastreamer
sudo nft add chain ip hastreamer prerouting '{ type nat hook prerouting priority dstnat; }'
sudo nft add rule  ip hastreamer prerouting tcp dport 80 redirect to :8080

# Проверка: правило появилось в списке.
sudo nft list chain ip hastreamer prerouting

table ip hastreamer {
	chain prerouting {
		type nat hook prerouting priority dstnat; policy accept;
		tcp dport 80 redirect to :8080
	}
}

Предпосылки выпуска, все обязательны:

1. настроен хотя бы один TLS-слушатель (https, rtsps или rtmps ненулевой) — иначе задача выпуска не запускается вовсе;
2. есть блок certificate <имя> { hosts …; acme; } с конкретным именем узла — подстановочные имена по HTTP-01 невозможны;
3. удостоверяющий центр достаёт http://<имя>/.well-known/acme-challenge/<токен> на порту 80;
4. разрешён исходящий HTTPS до адреса из acme_directory.

Подробности выпуска и обновления — TLS и сертификаты.

Работа за обратным прокси#

Типовая схема: прокси терминирует TLS на 443 и проксирует на http сервера. Тогда https в конфигурации сервера остаётся нулевым, и перенаправление на HTTPS сервер не делает — этим занимается прокси.

Проброс адреса клиента — обязателен#

Сервер верит заголовкам Forwarded, X-Forwarded-For и X-Real-IP только если непосредственный TCP-собеседник перечислен в trusted_proxies. По умолчанию список пуст, то есть заголовки пересылки не принимаются никогда — прямой клиент не может подделать свой адрес.

trusted_proxies 10.0.0.0/8 192.168.0.0/16 ::1;

Порядок разбора при доверенном собеседнике: Forwarded: for= → X-Forwarded-For → X-Real-IP; доверенные узлы срезаются справа по цепочке.

curl -sS "https://media.example.com/api/v1/sessions" \
  -H "Authorization: Bearer $TOKEN"

Что должен уметь прокси#

CORS#

Если панель или плеер открываются с другого домена, ограничьте список источников:

allow_origins https://console.example.com https://ops.example.com;

Совпадение точное, без подстановок и суффиксов. Источник не из списка не получает заголовка CORS вообще. Предварительный запрос OPTIONS сервер отвечает сам: 204, Allow-Methods: GET, HEAD, OPTIONS, POST, DELETE, Allow-Headers: Range, Content-Type, Authorization, Max-Age: 86400.

Ответ /metrics и ответчик ACME заголовков CORS не отдают намеренно.

UDP для WebRTC#

webrtc 40000 public_ip=203.0.113.10;

Нужен ровно один UDP-порт. Сервер работает в режиме ICE-lite и объявляет один-единственный кандидат — свой адрес и этот порт. Диапазона портов нет, каждое рабочее ядро открывает тот же самый порт через SO_REUSEPORT. Медиа идёт по нему в обе стороны.

Правило межсетевого экрана — одно:

# Разрешить входящий UDP на порт WebRTC. Цепочка `inet filter input` есть в
# стандартном наборе правил; если её нет — создайте её так же, как выше.
sudo nft add rule inet filter input udp dport 40000 accept

UDP для RTSP#

RTSP умеет два транспорта, и настраиваются они разными директивами — их часто путают.

Раздача по RTSP через UDP#

Когда клиент запрашивает RTP/AVP;unicast;client_port=…, сервер занимает пару соседних UDP-портов из эфемерного диапазона ядра: RTP на P, RTCP на P+1. Настраиваемого диапазона нет — директивы для него не существует.

Практические следствия:

• при строгих правилах для входящего UDP откройте эфемерный диапазон (sysctl net.ipv4.ip_local_port_range), либо запретите UDP-раздачу;
• если свободной пары не нашлось (сервер делает 8 попыток), клиент получает честный ответ 461 Unsupported Transport, а счётчик отказов виден в /api/v1/system;
• межсетевые экраны с отслеживанием состояния обычно пропускают эти пакеты сами, так как сессия открывается по управляющему TCP-соединению.

Самое простое решение для закрытых сетей — оставить только чередующийся TCP:

stream cam1 {
  input rtsp://admin:пароль@10.0.0.10:554/Streaming/Channels/101;
  rtsp_transports tcp;      # клиенту доступен только TCP, UDP отклоняется
}

1200 подобрано так, чтобы пакет проходил через VPN без фрагментации. Внутри одной сети с MTU 1500 значение можно поднять примерно до 1460.

rtsp_transports — параметр потока: его изменение пересоздаёт этот один поток, зрители остальных не затрагиваются. rtp_max_payload — глобальный и требует перезапуска службы. Разбор классов изменений — Применение изменений.

Приём с камеры через UDP#

source_transport udp-then-tcp;

При udp и udp-then-tcp сервер тоже занимает соседние пары портов из эфемерного диапазона и сообщает их камере в client_port=. Соединение инициирует сервер, поэтому межсетевой экран с отслеживанием состояния пропускает ответный поток без отдельного правила.

UDP для приёма MPEG-TS и multicast#

Порт задаётся не директивой, а самим URL источника:

stream headend {
  input udp://@239.1.1.1:1234?iface=10.0.0.5;
}

• адрес должен быть литералом IPv4 — ни DNS-имени, ни IPv6;
• ?iface=<IPv4> закрепляет интерфейс присоединения к группе;
• ?source=<IPv4> выполняет присоединение к конкретному источнику (IGMPv3, только Linux); значение обязано быть одноадресным, иначе конфигурация отвергается;
• на межсетевом экране нужен входящий UDP на этом порту, а на маршрутизаторе — разрешённый IGMP.

Подробности — RTSP, HLS, DASH, MPEG-TS.

Порты кластера#

cluster {
  key "общий-секрет-кластера";
  peer alpha 10.0.0.10:9000 { public https://alpha.example.com; zone dc1; }
  peer beta  10.0.0.11:9000 { public https://beta.example.com;  zone dc2; }
}

Один порт на узел (9000 в примере) обслуживает и UDP — обмен сведениями о живости, и TCP — канал между узлами. Открывайте оба протокола между узлами кластера.

Зрителей между узлами сервер перенаправляет, а не проксирует: клиент получает 302 (для WHIP и WHEP — 307) на адрес из public. Поэтому адреса из public должны быть доступны зрителям, а не только узлам кластера.

Итоговая карта портов типовой установки#

Зрители  ── TCP 443 ─────────► обратный прокси ── TCP 8080 ──► сервер
Зрители  ── UDP 40000 ────────────────────────────────────────► сервер   (WebRTC)
Зрители  ── TCP 8554 ─────────────────────────────────────────► сервер   (RTSP)
Сервер   ── TCP 554 ──────────────────────────────────────────► камеры
Сервер   ── TCP 443 ──────────────────────────────────────────► S3, ACME
Наблюдение ── TCP 8080 /metrics ──────────────────────────────► сервер

sudo ss -tulnp | grep hastreamer

tcp   LISTEN 0 4096 0.0.0.0:8080  0.0.0.0:*  users:(("hastreamer",pid=1234,fd=12))
tcp   LISTEN 0 4096 0.0.0.0:8554  0.0.0.0:*  users:(("hastreamer",pid=1234,fd=13))
udp   UNCONN 0 0    0.0.0.0:40000 0.0.0.0:*  users:(("hastreamer",pid=1234,fd=14))

Что дальше#

• hastreamer.conf — все директивы — полное описание каждой директивы.
• Применение изменений — смена порта требует restart, а не reload.
• TLS и сертификаты — выпуск и обновление сертификатов.
• Модель доступа — чем ограничение по сети отличается от авторизации.