Publicar un fluxo de cámara: RTSP e HLS non son o mesmo bordo

Vostede abre un porto da cámara, apunta un reprodutor cara a el e supón que o problema de internet está resolto. Despois un teléfono non pode reproducilo, un navegador non pode reproducilo, e a páxina de administración da cámara está a un só camiño mal escrito do bordo público. O modelo de entrega que elixiu, RTSP ou HLS, decide a maior parte diso antes de que se escriba calquera regra de firewall. A VPN só achega o treito privado.

A VPN arranxa a ruta da orixe, non a do espectador

Un VPS conectado á LAN da cámara mediante un túnel pode chegar á cámara no seu enderezo privado, e iso é realmente útil. Significa que a cámara non precisa ningún porto de entrada propio e que o router da casa permanece pechado. Non lle di que lingua falará un espectador. Un reprodutor de escritorio, un navegador, un teléfono e un televisor intelixente admiten protocolos distintos, e cada un ten as súas propias expectativas sobre TLS, autenticación e códecs.

Velaquí a suposición que paga a pena descartar: publicar significaría facer a orixe accesible. Publicar significa en realidade darlle a un público definido unha forma admitida de consumir o medio. Un fluxo publicado ten formato, público e credencial; unha cámara accesible non ten nada diso. A accesibilidade é a parte que resolve o túnel, e o punto de entrada do espectador é a parte que aínda ten que deseñar.

RTSP é unha negociación, non un só porto

RTSP leva o control de sesión: un cliente pide unha descrición, configura unha ou máis pistas de medios e despois reproduce. O transporte dos propios medios negóciase durante esa configuración, por iso o protocolo non queda ben descrito por un único porto TCP reenviado. Esa negociación é a parte que a xente pasa por alto cando compara regras de firewall.

Segundo os extremos, RTP pode chegar por portos UDP separados ou entrelazarse na conexión de control. Un relé que só reenvía 554 e supón que o resto funcionará adoita producir unha sesión que se conecta, informa dunha pista e despois non mostra nada. Comprobe o transporte que a súa cámara negocia realmente antes de escribir regras para el. Unha captura no lado privado respóndelle nun minuto, e adiviñalo custa unha tarde.

Para un público pequeno e coñecido con reprodutores compatibles, un relé RTSP configurado deliberadamente pode ser a resposta correcta. Limite de que orixe pode tirar e esixa autenticación no relé. Anote os reprodutores que probou, porque un fluxo RTSP que funciona en VLC pode fallar igualmente nun navegador.

HLS é unha lista de reprodución máis recursos

Un espectador de HLS obtén unha lista de reprodución e despois obtén os segmentos de medios que esa lista nomea. A especificación HLS define ese modelo de recursos, e o detalle operativo importante é que as listas fan referencia a outros URL. As referencias relativas resólvense respecto da localización da lista, así que un proxy que reescriba rutas ten que reescribilas de xeito coherente.

Se a cámara xa serve HLS utilizábel, un frontend público pode retransmitir esas solicitudes de lista e de segmentos a través do túnel. Vixie as chaves, as redireccións e os URL que xera a aplicación. Calquera URL absoluto que apunte a un host privado rompe no momento en que un espectador fóra da LAN o segue. As rutas relativas son as que sobreviven a unha reescritura do proxy, así que prefíraas alí onde controle a saída xerada.

Se a cámara fala só RTSP, algo ten que converter a orixe no formato do espectador. O reempaquetado e a transcodificación son traballos distintos: o reempaquetado conserva o códec, mentres que a transcodificación recodifica para a compatibilidade, e só a segunda custa CPU de verdade. Ningún dos dous se volve necesario só porque haxa unha VPN na ruta.

Planifique o enlace ascendente segundo onde ocorra a distribución. Unha única inxestión privada que alimenta un servizo de medios público compórtase de forma moi distinta a cada espectador que tira do seu propio fluxo polo túnel. O segundo patrón adoita rematar nunha conexión doméstica saturada e nunha cámara que parece fallar ao azar.

Pon a autenticación no bordo que publicas

TLS, a autenticación de espectadores e o rexistro de accesos pertencen ao punto de entrada público, non á cámara. Iso mantén as credenciais da cámara separadas das credenciais do fluxo. Tamén lle dá un único lugar onde revogar o acceso cando un membro do público marcha. Pór eses controis na cámara significa, en cambio, que cada cambio de público se converte nun cambio administrativo nun dispositivo que nunca debería ser accesible publicamente.

Manteña a VPN e os permisos de administración da cámara separados da ruta de publicación. Un VPS que pode chegar á interface web da cámara para tirar dun fluxo non debería ser tamén a máquina que expón esa interface. O público nunca debería coñecer o enderezo da cámara.

Despois verifique os dous extremos que construíu realmente en lugar de supor que a cadea funciona:

$ 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

Unha sonda correcta da orixe privada e unha obtención correcta da lista no bordo público demostran metades distintas do deseño. Probeas por separado. A reprodución desde o mesmo tipo de cliente que usa o seu público é a única proba que cobre toda a cadea.

O que acaba tendo é unha cadea cun propósito en cada elo: orixe privada, inxestión restrinxida, empaquetado escollido, entrada de espectador autorizada. Ningún deses elos é opcional, e ningún se crea abrindo un porto.