Публикация потока с камеры: RTSP и HLS — не один и тот же край

Вы открываете один порт камеры, направляете на него плеер и предполагаете, что проблема с интернетом решена. Потом телефон не может его воспроизвести, браузер не может его воспроизвести, а страница администрирования камеры отделена от публичного края одной неверно набранной путём. Выбранная модель доставки, RTSP или HLS, определяет большую часть этого ещё до того, как написано хоть одно правило межсетевого экрана. VPN даёт только приватный участок.

VPN исправляет путь источника, а не путь зрителя

VPS, подключённый к локальной сети камеры через туннель, может достичь камеры по её приватному адресу, и это действительно полезно. Это значит, что камере не нужен собственный входящий порт, а домашний маршрутизатор остаётся закрытым. Это не говорит вам, на каком языке будет говорить зритель. Настольный плеер, браузер, телефон и умный телевизор поддерживают разные протоколы, и у каждого свои ожидания насчёт TLS, аутентификации и кодеков.

Вот допущение, которое стоит отбросить: публикация якобы означает, что источник становится доступным. Публикация на самом деле означает, что определённой аудитории даётся поддерживаемый способ потреблять медиа. У опубликованного потока есть формат, аудитория и учётные данные; у доступной камеры нет ничего из этого. Доступность — это та часть, которую решает туннель, а точка входа зрителя — та часть, которую вам ещё предстоит спроектировать.

RTSP — это переговоры, а не один порт

RTSP несёт управление сеансом: клиент запрашивает описание, настраивает одну или несколько медиа-дорожек, а затем воспроизводит. Транспорт самих медиа согласуется во время этой настройки, поэтому протокол плохо описывается одним переадресованным портом TCP. Эти переговоры — та часть, которую люди упускают, сравнивая правила межсетевого экрана.

В зависимости от конечных точек RTP может приходить на отдельных портах UDP или быть встроен в управляющее соединение. Релей, который пересылает только 554 и предполагает, что остальное заработает, обычно создаёт сеанс, который подключается, сообщает о дорожке и затем ничего не показывает. Проверьте транспорт, о котором ваша камера действительно договаривается, прежде чем писать для него правила. Захват на приватной стороне отвечает на это за минуту, а угадывание стоит вечера.

Для небольшой, известной аудитории с совместимыми плеерами намеренно настроенный RTSP-релей может быть правильным ответом. Ограничьте, из какого источника он может тянуть, и требуйте аутентификацию на релее. Запишите плееры, которые вы тестировали, потому что поток RTSP, работающий в VLC, всё равно может не работать в браузере.

HLS — это плейлист плюс ресурсы

Зритель HLS получает плейлист, а затем получает медиасегменты, которые этот плейлист называет. Спецификация HLS определяет эту модель ресурсов, и важная операционная деталь в том, что плейлисты ссылаются на другие URL. Относительные ссылки разрешаются относительно расположения плейлиста, поэтому прокси, переписывающий пути, должен переписывать их согласованно.

Если камера уже отдаёт пригодный HLS, публичный фронтенд может передавать эти запросы плейлиста и сегментов через туннель. Следите за ключами, перенаправлениями и URL, которые генерирует приложение. Любой абсолютный URL, указывающий на приватный хост, ломается в тот момент, когда зритель вне локальной сети следует по нему. Относительные пути — те, что переживают переписывание прокси, поэтому предпочитайте их везде, где вы контролируете генерируемый вывод.

Если камера говорит только по RTSP, что-то должно преобразовать источник в формат зрителя. Перепаковка и транскодирование — разные задачи: перепаковка сохраняет кодек, тогда как транскодирование перекодирует его для совместимости, и только второе стоит серьёзной нагрузки на процессор. Ни то, ни другое не становится нужным лишь потому, что на пути есть VPN.

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

Ставьте аутентификацию на тот край, который вы публикуете

TLS, аутентификация зрителей и журналирование доступа относятся к публичной точке входа, а не к камере. Это держит учётные данные камеры отдельно от учётных данных потока. Это также даёт одно место для отзыва доступа, когда участник аудитории уходит. Размещение этих средств контроля на камере вместо этого означает, что каждое изменение аудитории становится административным изменением на устройстве, которое вообще никогда не должно быть публично доступным.

Держите VPN и административные права камеры отдельно от пути публикации. VPS, который может достичь веб-интерфейса камеры, чтобы тянуть поток, не должен также быть машиной, выставляющей этот интерфейс. Аудитория никогда не должна узнавать адрес камеры.

Затем проверьте те два конца, которые вы действительно построили, вместо того чтобы предполагать, что цепочка работает:

$ ffprobe -v error -rtsp_transport tcp rtsp://10.50.0.9:554/stream1
$ curl -sI https://stream.example.net/live/index.m3u8
HTTP/2 200
content-type: application/vnd.apple.mpegurl

Успешная проверка приватного источника и успешное получение плейлиста на публичном краю доказывают разные половины проекта. Проверяйте их по отдельности. Воспроизведение с того же типа клиента, который использует ваша аудитория, — единственная проверка, охватывающая всю цепочку.

В итоге у вас есть цепочка с назначением в каждом звене: приватный источник, ограниченный приём, выбранная упаковка, авторизованный вход зрителя. Ни одно из этих звеньев не является необязательным, и ни одно не создаётся открытием порта.