Publier un flux de caméra : RTSP et HLS n’ont pas le même point d’entrée public

Vous ouvrez un port de caméra, pointez un lecteur dessus et supposez que le problème d’internet est réglé. Puis un téléphone ne peut pas le lire, un navigateur ne peut pas le lire, et la page d’administration de la caméra se trouve à un chemin mal saisi du bord public. Le modèle de diffusion que vous avez choisi, RTSP ou HLS, décide de la majeure partie de cela avant qu’une seule règle de pare-feu soit écrite. Le VPN ne fournit que le tronçon privé.

Le VPN corrige le chemin de la source, pas celui du spectateur

Un VPS relié au LAN de la caméra par un tunnel peut atteindre la caméra à son adresse privée, et c’est réellement utile. Cela signifie que la caméra n’a besoin d’aucun port entrant propre et que le routeur domestique reste fermé. Cela ne vous dit pas quelle langue parlera un spectateur. Un lecteur de bureau, un navigateur, un téléphone et un téléviseur intelligent prennent en charge des protocoles différents, et chacun a ses propres attentes en matière de TLS, d’authentification et de codecs.

Voici l’hypothèse qu’il vaut la peine d’écarter : publier signifierait rendre la source joignable. Publier signifie en réalité donner à un public défini un moyen pris en charge de consommer le média. Un flux publié a un format, un public et un identifiant ; une caméra joignable n’a rien de tout cela. La joignabilité est la partie que le tunnel résout, et le point d’entrée du spectateur est la partie qu’il vous reste à concevoir.

RTSP est une négociation, pas un port unique

RTSP porte le contrôle de session : un client demande une description, met en place une ou plusieurs pistes média, puis lit. Le transport du média lui-même est négocié pendant cette mise en place, ce qui explique pourquoi un seul port TCP redirigé décrit mal le protocole. Cette négociation est la partie que les gens manquent lorsqu’ils comparent des règles de pare-feu.

Selon les extrémités, RTP peut arriver sur des ports UDP séparés ou être entrelacé sur la connexion de contrôle. Un relais qui ne redirige que 554 et suppose que le reste fonctionnera produit souvent une session qui se connecte, signale une piste, puis n’affiche rien. Vérifiez le transport que votre caméra négocie réellement avant d’écrire des règles pour lui. Une capture du côté privé répond à cela en une minute, et le deviner coûte une soirée.

Pour un public restreint et connu disposant de lecteurs compatibles, un relais RTSP délibérément configuré peut être la bonne réponse. Limitez la source qu’il peut tirer et exigez une authentification au niveau du relais. Notez les lecteurs que vous avez testés, car un flux RTSP qui fonctionne dans VLC peut encore échouer dans un navigateur.

HLS est une playlist plus des ressources

Un spectateur HLS récupère une playlist, puis récupère les segments média que cette playlist nomme. La spécification HLS définit ce modèle de ressources, et le détail opérationnel important est que les playlists référencent d’autres URL. Les références relatives se résolvent par rapport à l’emplacement de la playlist, donc un proxy qui réécrit les chemins doit les réécrire de façon cohérente.

Si la caméra sert déjà du HLS utilisable, un frontend public peut relayer ces requêtes de playlist et de segments à travers le tunnel. Surveillez les clés, les redirections et les URL générées par l’application. Toute URL absolue pointant vers un hôte privé casse dès qu’un spectateur hors du LAN la suit. Les chemins relatifs sont ceux qui survivent à une réécriture par le proxy, alors préférez-les partout où vous contrôlez la sortie générée.

Si la caméra ne parle que RTSP, quelque chose doit convertir la source dans le format du spectateur. Le rempaquetage et le transcodage sont des tâches différentes : le rempaquetage préserve le codec, tandis que le transcodage le réencode pour la compatibilité, et seul le second coûte un vrai CPU. Ni l’un ni l’autre ne devient nécessaire simplement parce qu’un VPN se trouve sur le chemin.

Planifiez la liaison montante en fonction de l’endroit où se produit la diffusion. Une ingestion privée qui alimente un service média public se comporte très différemment de chaque spectateur qui tire son propre flux à travers le tunnel. Le second schéma finit généralement par une connexion domestique saturée et une caméra qui semble échouer au hasard.

Placez l’authentification au bord que vous publiez

TLS, l’authentification des spectateurs et la journalisation des accès appartiennent au point d’entrée public, pas à la caméra. Cela garde les identifiants de la caméra séparés des identifiants du flux. Cela vous donne aussi un seul endroit pour révoquer l’accès lorsqu’un membre du public s’en va. Placer ces contrôles sur la caméra signifie à la place que chaque changement de public devient un changement administratif sur un appareil qui ne devrait jamais être joignable publiquement.

Gardez le VPN et les permissions d’administration de la caméra séparés du chemin de publication. Un VPS qui peut atteindre l’interface web de la caméra pour tirer un flux ne devrait pas être aussi la machine qui expose cette interface. Le public ne devrait jamais apprendre l’adresse de la caméra.

Vérifiez ensuite les deux extrémités que vous avez réellement construites plutôt que de supposer que la chaîne fonctionne :

$ 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

Une sonde réussie de la source privée et une récupération réussie de la playlist au bord public prouvent deux moitiés différentes de la conception. Testez-les séparément. La lecture depuis le même type de client que celui de votre public est le seul test qui couvre toute la chaîne.

Ce que vous obtenez est une chaîne ayant un rôle à chaque maillon : source privée, ingestion restreinte, conditionnement choisi, entrée de spectateur autorisée. Aucun de ces maillons n’est facultatif, et aucun n’est créé en ouvrant un port.