Kamerafolyam közzététele: az RTSP és a HLS nem ugyanaz a perem

Megnyit egy kameraportot, egy lejátszót ráirányít, és azt feltételezi, hogy az internetes probléma megoldódott. Aztán egy telefon nem tudja lejátszani, egy böngésző nem tudja lejátszani, és a kamera adminisztrációs oldala egyetlen elgépelt útvonalra van a nyilvános peremtől. A választott továbbítási modell, az RTSP vagy a HLS, ennek nagy részét eldönti, mielőtt bármilyen tűzfal-szabály megíródna. A VPN csak a privát szakaszt adja.

A VPN a forrás útját javítja, nem a néző útját

Egy VPS, amelyet alagúton keresztül a kamera LAN-jához csatlakoztattak, eléri a kamerát a privát címén, és ez valóban hasznos. Ez azt jelenti, hogy a kamerának nincs szüksége saját bejövő portra, és az otthoni router zárva marad. Ez nem mondja meg, milyen nyelven fog beszélni egy néző. Egy asztali lejátszó, egy böngésző, egy telefon és egy okostévé különböző protokollokat támogat, és mindegyiknek megvannak a maga elvárásai a TLS, a hitelesítés és a kodekek terén.

Íme a feltevés, amelyet érdemes elvetni: a közzététel állítólag azt jelentené, hogy a forrás elérhetővé válik. A közzététel valójában azt jelenti, hogy egy meghatározott közönségnek támogatott módot adunk a média fogyasztására. Egy közzétett adatfolyamnak van formátuma, közönsége és hitelesítő adata; egy elérhető kamerának egyik sincs. Az elérhetőség az a rész, amelyet az alagút megold, a néző belépési pontja pedig az a rész, amelyet még meg kell terveznie.

Az RTSP tárgyalás, nem egyetlen port

Az RTSP viszi a munkamenet-vezérlést: az ügyfél leírást kér, beállít egy vagy több médiasávot, majd lejátszik. Magának a médiának a szállítását a beállítás során tárgyalják, ezért a protokollt nem írja le jól egyetlen átirányított TCP-port. Ez a tárgyalás az a rész, amelyet az emberek kihagynak, amikor tűzfalszabályokat hasonlítanak össze.

A végpontoktól függően az RTP külön UDP-portokon érkezhet, vagy a vezérlőkapcsolatba ágyazva lehet. Egy relay, amely csak az 554-es portot továbbítja, és feltételezi, hogy a többi majd működik, általában olyan munkamenetet hoz létre, amely csatlakozik, jelent egy sávot, majd semmit sem mutat. Ellenőrizze, milyen szállítást tárgyal valójában a kamerája, mielőtt szabályokat írna rá. Egy rögzítés a privát oldalon ezt egy perc alatt megválaszolja, a találgatás pedig egy estébe kerül.

Egy kicsi, ismert közönség számára kompatibilis lejátszókkal egy szándékosan beállított RTSP-relay lehet a helyes válasz. Korlátozza, hogy melyik forrásból húzhat, és követeljen hitelesítést a relaynél. Jegyezze fel a tesztelt lejátszókat, mert egy VLC-ben működő RTSP-adatfolyam egy böngészőben még mindig elbukhat.

A HLS egy lejátszási lista plusz erőforrások

Egy HLS-néző letölt egy lejátszási listát, majd letölti azokat a médiaszegmenseket, amelyeket ez a lista megnevez. A HLS specifikáció határozza meg ezt az erőforrásmodellt, és a fontos üzemeltetési részlet az, hogy a lejátszási listák más URL-ekre hivatkoznak. A relatív hivatkozások a lista helyéhez képest oldódnak fel, ezért az útvonalakat átíró proxy-nak következetesen kell átírnia őket.

Ha a kamera már használható HLS-t szolgál, egy nyilvános frontend továbbíthatja ezeket a lista- és szegmenskérelmeket az alagúton keresztül. Figyelje a kulcsokat, az átirányításokat és az alkalmazás által generált URL-eket. Minden abszolút URL, amely privát hosztra mutat, abban a pillanatban eltörik, amikor egy LAN-on kívüli néző követi. A relatív útvonalak azok, amelyek túlélik a proxy átírását, ezért részesítse előnyben őket mindenhol, ahol Ön irányítja a generált kimenetet.

Ha a kamera csak RTSP-t beszél, valaminek át kell alakítania a forrást a néző formátumára. Az újracsomagolás és az átkódolás különböző feladatok: az újracsomagolás megőrzi a kodeket, míg az átkódolás a kompatibilitás érdekében újrakódolja, és csak a második kerül komoly processzorterhelésbe. Egyik sem válik szükségessé pusztán azért, mert egy VPN van az útvonalon.

Tervezze meg a feltöltési kapcsolatot aszerint, hol történik a terjesztés. Egyetlen privát bemenet, amely egy nyilvános médiaszolgáltatást táplál, egészen másképp viselkedik, mint az a néző, aki a saját adatfolyamát húzza át az alagúton. A második minta általában telített otthoni kapcsolattal és véletlenszerűen meghibásodni látszó kamerával végződik.

Tegye a hitelesítést arra a peremre, amelyet közzétesz

A TLS, a nézők hitelesítése és a hozzáférés naplózása a nyilvános belépési pontra tartozik, nem a kamerára. Ez elkülöníti a kamera hitelesítő adatait az adatfolyam hitelesítő adataitól. Ez egyetlen helyet is ad a hozzáférés visszavonására, amikor egy közönségtag távozik. Ha ezeket a vezérlőket a kamerára teszi, az azt jelenti, hogy minden közönségváltozás adminisztratív változás lesz egy olyan eszközön, amelynek soha nem szabadna nyilvánosan elérhetőnek lennie.

Tartsa a VPN-t és a kamera adminisztrációs jogosultságait külön a közzétételi útvonaltól. Egy VPS, amely eléri a kamera webes felületét, hogy adatfolyamot húzzon, ne legyen egyben az a gép is, amely ezt a felületet kitárja. A közönség soha ne tudja meg a kamera címét.

Ezután ellenőrizze a két végét annak, amit valóban megépített, ahelyett hogy feltételezné, hogy a lánc működik:

$ 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

A privát forrás sikeres vizsgálata és a lejátszási lista sikeres letöltése a nyilvános peremen a tervezés különböző felét bizonyítja. Külön tesztelje őket. A lejátszás ugyanabból a kliensfajtából, amelyet a közönsége használ, az egyetlen teszt, amely a teljes láncot lefedi.

Amit végül kap, az egy lánc, amelynek minden szemében van cél: privát forrás, korlátozott bemenet, kiválasztott csomagolás, engedélyezett nézői belépés. E szemek egyike sem opcionális, és egyik sem jön létre egy port megnyitásától.