Pubblicare un flusso di telecamera: RTSP e HLS non sono lo stesso punto d’ingresso

Si espone una porta della telecamera, punta un lettore verso di essa e presume che il problema di internet sia risolto. Poi un telefono non riesce a riprodurla, un browser non riesce a riprodurla, e la pagina di amministrazione della telecamera si trova a un percorso digitato male dal bordo pubblico. Il modello di distribuzione che hai scelto, RTSP o HLS, decide gran parte di questo prima che venga scritta una qualsiasi regola del firewall. La VPN fornisce solo il tratto privato.

La VPN sistema il percorso della sorgente, non quello dello spettatore

Un VPS collegato alla LAN della telecamera tramite un tunnel può raggiungere la telecamera al suo indirizzo privato, e questo è davvero utile. Significa che la telecamera non ha bisogno di una propria porta in ingresso e che il router di casa resta chiuso. Non ti dice che cosa parlerà uno spettatore. Un lettore desktop, un browser, un telefono e una smart TV supportano protocolli diversi, e ciascuno ha le proprie aspettative su TLS, autenticazione e codec.

Ecco l’ipotesi da scartare: pubblicare significherebbe rendere raggiungibile la sorgente. Pubblicare in realtà significa dare a un pubblico definito un modo supportato di consumare il media. Un flusso pubblicato ha un formato, un pubblico e una credenziale; una telecamera raggiungibile non ha nulla di tutto ciò. La raggiungibilità è la parte che il tunnel risolve, e il punto di ingresso dello spettatore è la parte che devi ancora progettare.

RTSP è una negoziazione, non una singola porta

RTSP trasporta il controllo di sessione: un client chiede una descrizione, imposta una o più tracce media, poi riproduce. Il trasporto dei media stessi viene negoziato durante quell’impostazione, ed è per questo che il protocollo non è ben descritto da una singola porta TCP inoltrata. Quella negoziazione è la parte che le persone trascurano quando confrontano le regole del firewall.

A seconda degli endpoint, RTP può arrivare su porte UDP separate o essere interlacciato sulla connessione di controllo. Un relay che inoltra solo 554 e presume che il resto funzionerà tende a produrre una sessione che si connette, segnala una traccia e poi non mostra nulla. Verifica il trasporto che la tua telecamera negozia davvero prima di scrivere regole per esso. Una cattura sul lato privato risponde in un minuto, e indovinare costa una serata.

Per un pubblico piccolo e noto con lettori compatibili, un relay RTSP configurato con cura può essere la risposta giusta. Limita quale sorgente può prelevare e richiedi l’autenticazione al relay. Annota i lettori che hai testato, perché un flusso RTSP che funziona in VLC può comunque fallire in un browser.

HLS è una playlist più risorse

Uno spettatore HLS recupera una playlist, poi recupera i segmenti media che quella playlist nomina. La specifica HLS definisce quel modello di risorse, e il dettaglio operativo importante è che le playlist fanno riferimento ad altri URL. I riferimenti relativi vengono risolti rispetto alla posizione della playlist, quindi un proxy che riscrive i percorsi deve riscriverli in modo coerente.

Se la telecamera serve già HLS utilizzabile, un frontend pubblico può inoltrare quelle richieste di playlist e segmenti attraverso il tunnel. Fai attenzione a chiavi, reindirizzamenti e URL generati dall’applicazione. Qualsiasi URL assoluto che punta a un host privato si rompe nel momento in cui uno spettatore fuori dalla LAN lo segue. I percorsi relativi sono quelli che sopravvivono a una riscrittura del proxy, quindi preferiscili ovunque tu controlli l’output generato.

Se la telecamera parla solo RTSP, qualcosa deve convertire la sorgente nel formato dello spettatore. Il reimpacchettamento e la transcodifica sono lavori diversi: il reimpacchettamento conserva il codec, mentre la transcodifica lo ricodifica per compatibilità, e solo la seconda costa CPU seria. Nessuno dei due diventa necessario solo perché una VPN è sul percorso.

Pianifica l’uplink in base a dove avviene la distribuzione. Un’unica acquisizione privata che alimenta un servizio media pubblico si comporta molto diversamente da ogni spettatore che tira il proprio flusso attraverso il tunnel. Il secondo schema di solito finisce in una connessione domestica satura e in una telecamera che sembra guastarsi a caso.

Metti l’autenticazione sul bordo che pubblichi

TLS, l’autenticazione degli spettatori e la registrazione degli accessi appartengono al punto di ingresso pubblico, non alla telecamera. Questo tiene le credenziali della telecamera separate dalle credenziali del flusso. Ti dà anche un unico posto dove revocare l’accesso quando un membro del pubblico se ne va. Mettere quei controlli sulla telecamera significa invece che ogni cambio di pubblico diventa un cambio amministrativo su un dispositivo che non dovrebbe mai essere raggiungibile pubblicamente.

Tieni la VPN e i permessi di gestione della telecamera separati dal percorso di pubblicazione. Un VPS che può raggiungere l’interfaccia web della telecamera per prelevare un flusso non dovrebbe essere anche la macchina che espone quell’interfaccia. Il pubblico non dovrebbe mai conoscere l’indirizzo della telecamera.

Poi verifica le due estremità che hai davvero costruito invece di dare per scontato che la catena funzioni:

$ 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

Un probe riuscito della sorgente privata e un recupero riuscito della playlist sul bordo pubblico dimostrano metà diverse del progetto. Testali separatamente. La riproduzione dallo stesso tipo di client che usa il tuo pubblico è l’unico test che copre l’intera catena.

Quello che ottieni è una catena con uno scopo a ogni anello: sorgente privata, acquisizione limitata, confezionamento scelto, ingresso spettatore autorizzato. Nessuno di quegli anelli è facoltativo, e nessuno viene creato aprendo una porta.