Publikowanie strumienia z kamery: RTSP i HLS to nie ta sama krawędź

Otwierasz jeden port kamery, kierujesz na niego odtwarzacz i zakładasz, że problem z internetem jest rozwiązany. Potem telefon nie może tego odtworzyć, przeglądarka nie może tego odtworzyć, a strona administracyjna kamery dzieli od publicznej krawędzi tylko jedna błędnie wpisana ścieżka. Wybrany model dostarczania, RTSP albo HLS, rozstrzyga większość tego, zanim zostanie zapisana choć jedna reguła zapory. VPN dostarcza tylko odcinek prywatny.

VPN naprawia ścieżkę źródła, a nie ścieżkę widza

VPS połączony z siecią LAN kamery przez tunel może dotrzeć do kamery pod jej prywatnym adresem, i to jest naprawdę przydatne. Oznacza to, że kamera nie potrzebuje własnego portu wejściowego, a router domowy pozostaje zamknięty. To nie mówi, jakim językiem będzie mówił widz. Odtwarzacz komputerowy, przeglądarka, telefon i inteligentny telewizor obsługują różne protokoły, a każdy ma własne oczekiwania co do TLS, uwierzytelniania i kodeków.

Oto założenie, które warto odrzucić: publikowanie miałoby oznaczać udostępnienie źródła. Publikowanie w rzeczywistości oznacza danie określonej publiczności wspieranego sposobu konsumowania mediów. Opublikowany strumień ma format, publiczność i poświadczenie; osiągalna kamera nie ma żadnego z tych elementów. Osiągalność to ta część, którą rozwiązuje tunel, a punkt wejścia widza to ta część, którą wciąż musisz zaprojektować.

RTSP to negocjacja, a nie jeden port

RTSP przenosi sterowanie sesją: klient prosi o opis, konfiguruje jedną lub więcej ścieżek mediów, a następnie odtwarza. Transport samych mediów jest negocjowany podczas tej konfiguracji, dlatego protokołu nie opisuje dobrze jeden przekierowany port TCP. Ta negocjacja to część, którą ludzie pomijają, porównując reguły zapory.

W zależności od punktów końcowych RTP może przychodzić osobnymi portami UDP albo być przeplatane w połączeniu sterującym. Przekaźnik, który przekazuje tylko 554 i zakłada, że reszta zadziała, zwykle daje sesję, która się łączy, zgłasza ścieżkę, a potem nic nie pokazuje. Sprawdź transport, który twoja kamera rzeczywiście negocjuje, zanim napiszesz dla niego reguły. Przechwycenie po stronie prywatnej odpowiada na to w minutę, a zgadywanie kosztuje wieczór.

Dla małej, znanej publiczności z zgodnymi odtwarzaczami celowo skonfigurowany przekaźnik RTSP może być właściwą odpowiedzią. Ogranicz, z jakiego źródła może pobierać, i wymagaj uwierzytelniania w przekaźniku. Zapisz odtwarzacze, które testowałeś, ponieważ strumień RTSP działający w VLC może nadal zawodzić w przeglądarce.

HLS to lista odtwarzania plus zasoby

Widz HLS pobiera listę odtwarzania, a następnie pobiera segmenty mediów, które ta lista nazywa. Specyfikacja HLS definiuje ten model zasobów, a ważny szczegół operacyjny polega na tym, że listy odtwarzania odwołują się do innych adresów URL. Odwołania względne są rozwiązywane względem lokalizacji listy, więc proxy przepisujące ścieżki musi przepisywać je spójnie.

Jeśli kamera już udostępnia użyteczne HLS, publiczny frontend może przekazywać te żądania listy i segmentów przez tunel. Uważaj na klucze, przekierowania i adresy URL generowane przez aplikację. Każdy bezwzględny adres URL wskazujący prywatny host psuje się w chwili, gdy widz spoza sieci LAN za nim podąży. Ścieżki względne to te, które przetrwają przepisanie przez proxy, więc preferuj je wszędzie tam, gdzie kontrolujesz generowane wyjście.

Jeśli kamera mówi tylko RTSP, coś musi przekonwertować źródło na format widza. Przepakowywanie i transkodowanie to różne zadania: przepakowywanie zachowuje kodek, natomiast transkodowanie koduje go ponownie dla zgodności, i tylko to drugie kosztuje poważnie procesor. Żadne z nich nie staje się konieczne tylko dlatego, że na ścieżce jest VPN.

Zaplanuj łącze wysyłające według tego, gdzie odbywa się dystrybucja. Jeden prywatny strumień zasilający publiczną usługę multimedialną zachowuje się zupełnie inaczej niż każdy widz ciągnący własny strumień przez tunel. Drugi wzorzec zwykle kończy się przeciążonym łączem domowym i kamerą, która wydaje się zawodzić losowo.

Umieść uwierzytelnianie na krawędzi, którą publikujesz

TLS, uwierzytelnianie widzów i rejestrowanie dostępu należą do publicznego punktu wejścia, a nie do kamery. To oddziela poświadczenia kamery od poświadczeń strumienia. Daje też jedno miejsce do odebrania dostępu, gdy członek publiczności odchodzi. Umieszczenie tych kontroli w kamerze oznacza zamiast tego, że każda zmiana publiczności staje się zmianą administracyjną w urządzeniu, które nigdy nie powinno być publicznie osiągalne.

Trzymaj VPN i uprawnienia administracyjne kamery oddzielnie od ścieżki publikowania. VPS, który może dotrzeć do interfejsu webowego kamery, aby pobrać strumień, nie powinien być także maszyną wystawiającą ten interfejs. Publiczność nigdy nie powinna poznać adresu kamery.

Następnie zweryfikuj te dwa końce, które naprawdę zbudowałeś, zamiast zakładać, że łańcuch działa:

$ 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

Udane sondowanie prywatnego źródła i udane pobranie listy odtwarzania na publicznej krawędzi dowodzą różnych połówek projektu. Testuj je osobno. Odtwarzanie z tego samego rodzaju klienta, którego używa twoja publiczność, to jedyny test obejmujący cały łańcuch.

To, co ostatecznie otrzymujesz, to łańcuch z celem w każdym ogniwie: prywatne źródło, ograniczone wejście, wybrane pakowanie, autoryzowane wejście widza. Żadne z tych ogniw nie jest opcjonalne i żadne nie powstaje przez otwarcie portu.