Publikování streamu z kamery: RTSP a HLS nejsou stejná hrana

Otevřete jeden port kamery, namíříte na něj přehrávač a předpokládáte, že problém s internetem je vyřešen. Pak ho telefon nedokáže přehrát, prohlížeč ho nedokáže přehrát a administrační stránka kamery je od veřejné hrany vzdálena jen jednu špatně napsanou cestu. Zvolený model doručování, RTSP nebo HLS, rozhoduje o většině toho dřív, než je napsáno jediné pravidlo firewallu. VPN dodává jen soukromý úsek.

VPN opravuje cestu zdroje, ne cestu diváka

VPS připojený k síti LAN kamery tunelem dokáže kameru dosáhnout na její soukromé adrese, a to je opravdu užitečné. Znamená to, že kamera nepotřebuje vlastní příchozí port a domácí router zůstává zavřený. Neříká vám to, jakou řečí bude divák mluvit. Přehrávač na počítači, prohlížeč, telefon a chytrá televize podporují různé protokoly a každý má svá očekávání ohledně TLS, ověřování a kodeků.

Tady je předpoklad, který stojí za to zahodit: publikování by prý znamenalo zpřístupnit zdroj. Publikování ve skutečnosti znamená dát definovanému publiku podporovaný způsob konzumace média. Publikovaný proud má formát, publikum a přihlašovací údaj; dostupná kamera nemá nic z toho. Dostupnost je ta část, kterou tunel řeší, a vstupní bod diváka je ta část, kterou ještě musíte navrhnout.

RTSP je vyjednávání, ne jediný port

RTSP nese řízení relace: klient požádá o popis, nastaví jednu nebo více mediálních stop a poté přehrává. Přeprava samotného média se vyjednává během tohoto nastavení, a proto protokol není dobře popsán jediným předávaným portem TCP. To vyjednávání je část, kterou lidé přehlížejí, když porovnávají pravidla firewallu.

V závislosti na koncových bodech může RTP přicházet na samostatných portech UDP nebo být prokládáno v řídicím spojení. Relay, který předává jen 554 a předpokládá, že zbytek bude fungovat, obvykle vytvoří relaci, která se připojí, ohlásí stopu a pak nic nezobrazí. Zkontrolujte přepravu, kterou vaše kamera skutečně vyjednává, než pro ni napíšete pravidla. Zachycení na soukromé straně to zodpoví během minuty a hádání stojí večer.

Pro malé, známé publikum s kompatibilními přehrávači může být záměrně nakonfigurovaný relay RTSP správnou odpovědí. Omezte, ze kterého zdroje smí tahat, a vyžadujte ověřování na relayi. Zapište si přehrávače, které jste testovali, protože proud RTSP, který funguje ve VLC, může v prohlížeči stále selhat.

HLS je seznam skladeb plus zdroje

Divák HLS stáhne seznam skladeb a poté stáhne mediální segmenty, které tento seznam pojmenovává. Specifikace HLS definuje tento model zdrojů a důležitý provozní detail je, že seznamy skladeb odkazují na jiné URL. Relativní odkazy se vyhodnocují vůči umístění seznamu, takže proxy, která přepisuje cesty, je musí přepisovat konzistentně.

Pokud kamera již poskytuje použitelný HLS, veřejný frontend může tyto požadavky na seznam a segmenty předávat tunelem. Sledujte klíče, přesměrování a URL, které aplikace generuje. Jakákoli absolutní URL ukazující na soukromý hostitel se rozbije ve chvíli, kdy ji divák mimo síť LAN následuje. Relativní cesty jsou ty, které přežijí přepis proxy, proto jim dávejte přednost všude, kde řídíte generovaný výstup.

Pokud kamera mluví jen RTSP, něco musí převést zdroj do formátu diváka. Přebalování a transkódování jsou různé úlohy: přebalování zachovává kodek, zatímco transkódování ho znovu kóduje kvůli kompatibilitě, a jen to druhé stojí vážně procesorový čas. Ani jedno se nestane nutným jen proto, že je v cestě VPN.

Naplánujte odchozí linku podle toho, kde dochází k distribuci. Jeden soukromý příjem napájející veřejnou mediální službu se chová velmi odlišně od každého diváka, který si táhne vlastní proud tunelem. Druhý vzor obvykle končí na zahlceném domácím připojení a kameře, která vypadá, že náhodně selhává.

Umístěte ověřování na hranu, kterou publikujete

TLS, ověřování diváků a protokolování přístupu patří na veřejný vstupní bod, ne na kameru. To drží přihlašovací údaje kamery oddělené od údajů proudu. Dává vám to také jedno místo pro odvolání přístupu, když člen publika odejde. Umístění těchto kontrol na kameru místo toho znamená, že každá změna publika se stane administrativní změnou u zařízení, které by nikdy nemělo být veřejně dostupné.

Držte VPN a administrační oprávnění kamery oddělené od publikační cesty. VPS, který dokáže dosáhnout webového rozhraní kamery, aby stáhl proud, by neměl být také strojem vystavujícím toto rozhraní. Publikum by se nikdy nemělo dozvědět adresu kamery.

Poté ověřte oba konce, které jste skutečně postavili, místo abyste předpokládali, že řetěz funguje:

$ 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

Úspěšné otestování soukromého zdroje a úspěšné stažení seznamu na veřejné hraně dokazují různé poloviny návrhu. Testujte je odděleně. Přehrávání ze stejného typu klienta, který používá vaše publikum, je jediný test pokrývající celý řetěz.

Co nakonec máte, je řetěz s účelem v každém článku: soukromý zdroj, omezený příjem, zvolené balení, autorizovaný vstup diváka. Žádný z těch článků není volitelný a žádný nevzniká otevřením portu.