Publicar um fluxo de câmera: RTSP e HLS não são a mesma borda

Você expõe uma porta da câmera, aponta um player para ela e assume que o problema de internet está resolvido. Depois um telefone não consegue reproduzir, um navegador não consegue reproduzir, e a página de administração da câmera fica a um caminho digitado errado da borda pública. O modelo de entrega que você escolheu, RTSP ou HLS, decide a maior parte disso antes de qualquer regra de firewall ser escrita. A VPN fornece apenas o trecho privado.

A VPN corrige o caminho da origem, não o do espectador

Um VPS conectado à LAN da câmera por um túnel consegue alcançar a câmera no endereço privado dela, e isso é genuinamente útil. Significa que a câmera não precisa de nenhuma porta de entrada própria e que o roteador de casa permanece fechado. Isso não diz o que um espectador vai falar. Um player de desktop, um navegador, um telefone e uma smart TV suportam protocolos diferentes, e cada um tem as suas próprias expectativas sobre TLS, autenticação e codecs.

Aqui está a suposição que vale a pena descartar: publicar significaria tornar a origem alcançável. Publicar na verdade significa dar a um público definido uma forma suportada de consumir a mídia. Um fluxo publicado tem formato, público e credencial; uma câmera alcançável não tem nada disso. A alcançabilidade é a parte que o túnel resolve, e o ponto de entrada do espectador é a parte que você ainda precisa projetar.

RTSP é uma negociação, não uma porta única

O RTSP carrega o controle de sessão: um cliente pede uma descrição, configura uma ou mais faixas de mídia e depois reproduz. O transporte da própria mídia é negociado durante essa configuração, e é por isso que o protocolo não é bem descrito por uma única porta TCP encaminhada. Essa negociação é a parte que as pessoas esquecem quando comparam regras de firewall.

Dependendo dos endpoints, o RTP pode chegar em portas UDP separadas ou ser intercalado na conexão de controle. Um relay que encaminha apenas 554 e assume que o resto vai funcionar tende a produzir uma sessão que conecta, informa uma faixa e depois não mostra nada. Verifique o transporte que a sua câmera realmente negocia antes de escrever regras para ele. Uma captura no lado privado responde isso em um minuto, e adivinhar custa uma noite.

Para um público pequeno e conhecido com players compatíveis, um relay RTSP configurado deliberadamente pode ser a resposta certa. Restrinja de qual origem ele pode puxar e exija autenticação no relay. Anote os players que você testou, porque um fluxo RTSP que funciona no VLC ainda pode falhar num navegador.

HLS é uma playlist mais recursos

Um espectador de HLS busca uma playlist e depois busca os segmentos de mídia que essa playlist nomeia. A especificação HLS define esse modelo de recursos, e o detalhe operacional importante é que as playlists referenciam outras URLs. Referências relativas são resolvidas em relação à localização da playlist, então um proxy que reescreve caminhos precisa reescrevê-los de forma consistente.

Se a câmera já serve HLS utilizável, um frontend público pode retransmitir esses pedidos de playlist e de segmentos através do túnel. Fique atento a chaves, redirecionamentos e URLs geradas pela aplicação. Qualquer URL absoluta apontando para um host privado quebra no momento em que um espectador fora da LAN a segue. Caminhos relativos são os que sobrevivem a uma reescrita do proxy, então prefira-os onde quer que você controle a saída gerada.

Se a câmera fala apenas RTSP, algo precisa converter a origem no formato do espectador. Reempacotamento e transcodificação são trabalhos diferentes: o reempacotamento preserva o codec, enquanto a transcodificação o recodifica para compatibilidade, e apenas a segunda custa CPU de verdade. Nenhum dos dois passa a ser necessário só porque uma VPN está no caminho.

Planeje o uplink em torno de onde acontece a distribuição. Uma ingestão privada alimentando um serviço de mídia público comporta-se de forma muito diferente de cada espectador puxando o seu próprio fluxo pelo túnel. O segundo padrão costuma terminar numa conexão doméstica saturada e numa câmera que parece falhar ao acaso.

Coloque a autenticação na borda que você publica

TLS, autenticação de espectadores e registro de acessos pertencem ao ponto de entrada público, não à câmera. Isso mantém as credenciais da câmera separadas das credenciais do fluxo. Também lhe dá um único lugar para revogar o acesso quando um membro do público sai. Colocar esses controles na câmera significa, em vez disso, que cada mudança de público se torna uma mudança administrativa num dispositivo que nunca deveria ser alcançável publicamente.

Mantenha a VPN e as permissões de administração da câmera separadas do caminho de publicação. Um VPS que consegue alcançar a interface web da câmera para puxar um fluxo não deveria ser também a máquina que expõe essa interface. O público nunca deveria saber o endereço da câmera.

Depois verifique as duas pontas que você realmente construiu, em vez de assumir que a cadeia 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

Uma sondagem bem-sucedida da origem privada e uma busca bem-sucedida da playlist na borda pública provam metades diferentes do projeto. Teste-as separadamente. A reprodução a partir do mesmo tipo de cliente que o seu público usa é o único teste que cobre toda a cadeia.

O que você acaba por ter é uma cadeia com um propósito em cada elo: origem privada, ingestão restrita, empacotamento escolhido, entrada de espectador autorizada. Nenhum desses elos é opcional, e nenhum é criado abrindo uma porta.