Publicar un flujo de cámara: RTSP y HLS no son el mismo punto de entrada

Usted expone un puerto de la cámara, apunta un reproductor hacia él y da por resuelto el problema de internet. Luego un teléfono no puede reproducirlo, un navegador no puede reproducirlo, y la página de administración de la cámara queda a una ruta mal escrita del borde público. El modelo de entrega que eligió, RTSP o HLS, decide la mayor parte de eso antes de que se escriba una sola regla de cortafuegos. La VPN solo aporta el tramo privado.

La VPN arregla la ruta de origen, no la del espectador

Un VPS unido a la LAN de la cámara mediante un túnel puede alcanzar la cámara en su dirección privada, y eso es realmente útil. Significa que la cámara no necesita ningún puerto entrante propio y que el router doméstico permanece cerrado. No le dice qué hablará un espectador. Un reproductor de escritorio, un navegador, un teléfono y un televisor inteligente admiten protocolos distintos, y cada uno tiene sus propias expectativas sobre TLS, autenticación y códecs.

Aquí está la suposición que conviene descartar: publicar significaría hacer que el origen sea alcanzable. Publicar significa en realidad dar a un público definido una forma admitida de consumir el medio. Un flujo publicado tiene un formato, un público y una credencial; una cámara alcanzable no tiene nada de eso. La alcanzabilidad es la parte que resuelve el túnel, y el punto de entrada del espectador es la parte que todavía tiene que diseñar.

RTSP es una negociación, no un solo puerto

RTSP transporta el control de sesión: un cliente pide una descripción, configura una o más pistas de medios y luego reproduce. El transporte de los medios en sí se negocia durante esa configuración, y por eso el protocolo no queda bien descrito por un solo puerto TCP reenviado. Esa negociación es la parte que la gente pasa por alto cuando compara reglas de cortafuegos.

Según los extremos, RTP puede llegar por puertos UDP separados o entrelazarse en la conexión de control. Un relé que solo reenvía 554 y supone que el resto funcionará suele producir una sesión que se conecta, informa una pista y luego no muestra nada. Compruebe el transporte que su cámara negocia realmente antes de escribir reglas para él. Una captura en el lado privado lo responde en un minuto, y adivinarlo cuesta una tarde.

Para un público pequeño y conocido con reproductores compatibles, un relé RTSP configurado deliberadamente puede ser la respuesta correcta. Limite qué origen puede extraer y exija autenticación en el relé. Anote los reproductores que probó, porque un flujo RTSP que funciona en VLC puede fallar igualmente en un navegador.

HLS es una lista de reproducción más recursos

Un espectador de HLS obtiene una lista de reproducción y luego obtiene los segmentos de medios que esa lista nombra. La especificación HLS define ese modelo de recursos, y el detalle operativo importante es que las listas hacen referencia a otras URL. Las referencias relativas se resuelven contra la ubicación de la lista, así que un proxy que reescribe rutas tiene que reescribirlas de forma coherente.

Si la cámara ya sirve HLS utilizable, un frontend público puede retransmitir esas solicitudes de lista y de segmentos a través del túnel. Vigile las claves, las redirecciones y las URL que genera la aplicación. Cualquier URL absoluta que apunte a un host privado se rompe en el momento en que un espectador fuera de la LAN la sigue. Las rutas relativas son las que sobreviven a una reescritura del proxy, así que prefiéralas siempre que controle la salida generada.

Si la cámara habla solo RTSP, algo tiene que convertir el origen al formato del espectador. El reempaquetado y la transcodificación son trabajos distintos: el reempaquetado conserva el códec, mientras que la transcodificación lo recodifica para compatibilidad, y solo la segunda cuesta CPU de verdad. Ninguno de los dos se vuelve necesario solo porque una VPN esté en la ruta.

Planifique el enlace ascendente según dónde ocurra la distribución. Una ingesta privada que alimenta un servicio de medios público se comporta de forma muy distinta a cada espectador que arrastra su propio flujo por el túnel. El segundo patrón suele terminar en una conexión doméstica saturada y una cámara que parece fallar al azar.

Ponga la autenticación en el borde que publica

TLS, la autenticación de espectadores y el registro de accesos pertenecen al punto de entrada público, no a la cámara. Eso mantiene las credenciales de la cámara separadas de las credenciales del flujo. También le da un único lugar donde revocar el acceso cuando un miembro del público se va. Poner esos controles en la cámara significa en cambio que cada cambio de público se convierte en un cambio administrativo en un dispositivo que nunca debería ser alcanzable públicamente.

Mantenga la VPN y los permisos de administración de la cámara separados de la ruta de publicación. Un VPS que puede alcanzar la interfaz web de la cámara para extraer un flujo no debería ser también la máquina que expone esa interfaz. El público nunca debería conocer la dirección de la cámara.

Luego verifique los dos extremos que realmente construyó en lugar de suponer que la cadena 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

Una sonda correcta del origen privado y una obtención correcta de la lista en el borde público demuestran mitades distintas del diseño. Pruébelas por separado. La reproducción desde el mismo tipo de cliente que usa su público es la única prueba que cubre toda la cadena.

Lo que termina teniendo es una cadena con un propósito en cada eslabón: origen privado, ingesta restringida, empaquetado elegido, entrada de espectador autorizada. Ninguno de esos eslabones es opcional, y ninguno se crea abriendo un puerto.