Publicarea unui flux de la cameră: RTSP și HLS nu sunt aceeași margine

Deschideți un port al camerei, îndreptați un player spre el și presupuneți că problema de internet este rezolvată. Apoi un telefon nu îl poate reda, un browser nu îl poate reda, iar pagina de administrare a camerei se află la o cale tastată greșit de marginea publică. Modelul de livrare ales, RTSP sau HLS, decide cea mai mare parte din asta înainte de a fi scrisă vreo regulă de firewall. VPN-ul furnizează doar segmentul privat.

VPN-ul repară calea sursei, nu calea spectatorului

Un VPS conectat la rețeaua LAN a camerei printr-un tunel poate ajunge la cameră la adresa ei privată, și asta este cu adevărat util. Înseamnă că camera nu are nevoie de un port de intrare propriu, iar routerul de acasă rămâne închis. Nu vă spune ce limbă va vorbi un spectator. Un player de desktop, un browser, un telefon și un televizor inteligent acceptă protocoale diferite, iar fiecare are propriile așteptări despre TLS, autentificare și codecuri.

Iată presupunerea pe care merită să o abandonăm: publicarea ar însemna să facem sursa accesibilă. Publicarea înseamnă de fapt să oferim unui public definit o modalitate acceptată de a consuma media. Un flux publicat are un format, un public și o credențială; o cameră accesibilă nu are niciuna dintre acestea. Accesibilitatea este partea pe care o rezolvă tunelul, iar punctul de intrare al spectatorului este partea pe care încă trebuie să o proiectați.

RTSP este o negociere, nu un singur port

RTSP transportă controlul sesiunii: un client cere o descriere, configurează una sau mai multe piste media și apoi redă. Transportul media în sine este negociat în timpul acelei configurări, motiv pentru care protocolul nu este bine descris de un singur port TCP redirecționat. Acea negociere este partea pe care oamenii o ratează când compară reguli de firewall.

În funcție de punctele finale, RTP poate sosi pe porturi UDP separate sau poate fi intercalat pe conexiunea de control. Un releu care redirecționează doar 554 și presupune că restul va funcționa produce de obicei o sesiune care se conectează, raportează o pistă și apoi nu afișează nimic. Verificați transportul pe care camera dumneavoastră îl negociază efectiv înainte de a scrie reguli pentru el. O captură pe partea privată răspunde la asta într-un minut, iar ghicitul costă o seară.

Pentru un public mic și cunoscut, cu playere compatibile, un releu RTSP configurat intenționat poate fi răspunsul corect. Limitați din ce sursă poate trage și cereți autentificare la releu. Notați playerele pe care le-ați testat, pentru că un flux RTSP care funcționează în VLC poate eșua totuși într-un browser.

HLS este o listă de redare plus resurse

Un spectator HLS preia o listă de redare, apoi preia segmentele media pe care acea listă le numește. Specificația HLS definește acel model de resurse, iar detaliul operațional important este că listele de redare fac referire la alte URL-uri. Referințele relative se rezolvă față de locația listei, așa că un proxy care rescrie căi trebuie să le rescrie consecvent.

Dacă camera servește deja HLS utilizabil, un frontend public poate retransmite acele cereri de listă și de segmente prin tunel. Fiți atenți la chei, redirecționări și URL-uri generate de aplicație. Orice URL absolut care indică un host privat se rupe în momentul în care un spectator din afara rețelei LAN îl urmează. Căile relative sunt cele care supraviețuiesc unei rescrieri prin proxy, așa că preferați-le oriunde controlați ieșirea generată.

Dacă camera vorbește doar RTSP, ceva trebuie să convertească sursa în formatul spectatorului. Reîmpachetarea și transcodarea sunt sarcini diferite: reîmpachetarea păstrează codecul, în timp ce transcodarea îl recodează pentru compatibilitate, și doar a doua costă CPU serios. Niciuna nu devine necesară doar pentru că un VPN se află pe cale.

Planificați legătura ascendentă în funcție de locul unde are loc distribuția. O singură ingestie privată care alimentează un serviciu media public se comportă foarte diferit de fiecare spectator care își trage propriul flux prin tunel. Al doilea model se termină de obicei într-o conexiune de acasă saturată și o cameră care pare să eșueze aleatoriu.

Puneți autentificarea pe marginea pe care o publicați

TLS, autentificarea spectatorilor și jurnalizarea accesului aparțin punctului de intrare public, nu camerei. Asta ține credențialele camerei separate de credențialele fluxului. Vă oferă, de asemenea, un singur loc unde să revocați accesul când un membru al publicului pleacă. A pune aceste controale pe cameră înseamnă, în schimb, că fiecare schimbare de public devine o schimbare administrativă la un dispozitiv care nu ar trebui niciodată să fie accesibil public.

Țineți VPN-ul și permisiunile de administrare ale camerei separate de calea de publicare. Un VPS care poate ajunge la interfața web a camerei pentru a trage un flux nu ar trebui să fie și mașina care expune acea interfață. Publicul nu ar trebui să afle niciodată adresa camerei.

Apoi verificați cele două capete pe care le-ați construit efectiv, în loc să presupuneți că lanțul funcționează:

$ 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

O sondare reușită a sursei private și o preluare reușită a listei la marginea publică dovedesc jumătăți diferite ale proiectului. Testați-le separat. Redarea de pe același tip de client pe care îl folosește publicul dumneavoastră este singurul test care acoperă întregul lanț.

Ce obțineți în final este un lanț cu un scop la fiecare verigă: sursă privată, ingestie restricționată, ambalare aleasă, intrare autorizată a spectatorului. Niciuna dintre aceste verigi nu este opțională și niciuna nu este creată prin deschiderea unui port.