Публікація потоку з камери: 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

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

У підсумку ви маєте ланцюг із призначенням у кожній ланці: приватне джерело, обмежений прийом, обране пакування, авторизований вхід глядача. Жодна з цих ланок не є необов'язковою, і жодна не створюється відкриттям порту.