Kamera yayını yayınlamak: RTSP ve HLS aynı kenar değildir
RTSP oturum denetimi ve HLS teslimi farklı genel kenarlar gerektirir, ikisi de aynı kameraya VPN üzerinden ulaşsa bile. Önce izleyici modelini seçin.
Bir kamera portunu açıyor, ona bir oynatıcı yönlendiriyor ve internet sorununun çözüldüğünü varsayıyorsunuz. Sonra bir telefon onu oynatamıyor, bir tarayıcı onu oynatamıyor ve kameranın yönetim sayfası genel kenardan yalnızca bir yanlış yazılmış yol uzakta duruyor. Seçtiğiniz teslim modeli, RTSP ya da HLS, herhangi bir güvenlik duvarı kuralı yazılmadan önce bunun çoğuna karar verir. VPN yalnızca özel bacağı sağlar.
VPN kaynak yolunu onarır, izleyici yolunu değil
Bir tünelle kameranın yerel ağına bağlanan bir VPS, kameraya özel adresinden ulaşabilir ve bu gerçekten yararlıdır. Bu, kameranın kendi gelen portuna ihtiyacı olmadığı ve ev yönlendiricisinin kapalı kaldığı anlamına gelir. Bu size bir izleyicinin hangi dili konuşacağını söylemez. Masaüstü oynatıcı, tarayıcı, telefon ve akıllı televizyon farklı protokolleri destekler ve her birinin TLS, kimlik doğrulama ve kodekler konusunda kendi beklentileri vardır.
İşte bırakmaya değer varsayım: yayınlamak kaynağı erişilebilir kılmak anlamına gelir. Yayınlamak aslında tanımlı bir kitleye medyayı tüketmenin desteklenen bir yolunu vermek demektir. Yayınlanmış bir akışın formatı, kitlesi ve kimlik bilgisi vardır; erişilebilir bir kamerada bunların hiçbiri yoktur. Erişilebilirlik tünelin çözdüğü kısımdır, izleyicinin giriş noktası ise hâlâ tasarlamanız gereken kısımdır.
RTSP bir pazarlıktır, tek bir port değil
RTSP oturum denetimini taşır: bir istemci açıklama ister, bir veya daha fazla medya izi kurar ve sonra oynatır. Medyanın kendisinin taşınması bu kurulum sırasında pazarlık edilir, bu yüzden protokol tek bir yönlendirilmiş TCP portuyla iyi tanımlanmaz. Bu pazarlık, insanların güvenlik duvarı kurallarını karşılaştırırken gözden kaçırdığı kısımdır.
Uç noktalara bağlı olarak RTP ayrı UDP portlarına gelebilir veya denetim bağlantısına serpiştirilebilir. Yalnızca 554 numaralı portu yönlendiren ve geri kalanın çalışacağını varsayan bir aktarıcı, genellikle bağlanan, bir iz bildiren ve sonra hiçbir şey göstermeyen bir oturum üretir. Kurallarını yazmadan önce kameranızın gerçekte hangi taşımayı pazarlık ettiğini kontrol edin. Özel taraftaki bir yakalama bunu bir dakikada yanıtlar ve tahmin etmek bir akşama mal olur.
Uyumlu oynatıcılara sahip küçük ve bilinen bir kitle için bilerek yapılandırılmış bir RTSP aktarıcısı doğru yanıt olabilir. Hangi kaynaktan çekebileceğini sınırlayın ve aktarıcıda kimlik doğrulama isteyin. Test ettiğiniz oynatıcıları yazın, çünkü VLC'de çalışan bir RTSP akışı bir tarayıcıda yine de başarısız olabilir.
HLS bir çalma listesi artı kaynaklardır
Bir HLS izleyicisi bir çalma listesi alır, sonra o listenin adlandırdığı medya bölümlerini alır. HLS belirtimi bu kaynak modelini tanımlar ve önemli operasyonel ayrıntı, çalma listelerinin başka URL'lere başvurmasıdır. Göreli başvurular listenin konumuna göre çözülür, bu yüzden yolları yeniden yazan bir proxy'nin onları tutarlı biçimde yeniden yazması gerekir.
Kamera zaten kullanılabilir HLS sunuyorsa, genel bir önyüz bu liste ve bölüm isteklerini tünel üzerinden aktarabilir. Uygulamanın ürettiği anahtarlara, yönlendirmelere ve URL'lere dikkat edin. Özel bir ana bilgisayara işaret eden her mutlak URL, yerel ağ dışındaki bir izleyici onu izlediği anda bozulur. Göreli yollar proxy yeniden yazımından sağ çıkan yollardır, bu nedenle üretilen çıktıyı kontrol ettiğiniz her yerde onları tercih edin.
Kamera yalnızca RTSP konuşuyorsa, bir şeyin kaynağı izleyici formatına dönüştürmesi gerekir. Yeniden paketleme ve kod dönüştürme farklı işlerdir: yeniden paketleme kodeği korur, kod dönüştürme ise uyumluluk için yeniden kodlar ve yalnızca ikincisi ciddi CPU harcar. İkisi de yalnızca yolda bir VPN olduğu için gerekli hâle gelmez.
Yükleme bağlantısını dağıtımın gerçekleştiği yere göre planlayın. Genel bir medya hizmetini besleyen tek bir özel alım, kendi akışını tünelden çeken her izleyiciden çok farklı davranır. İkinci desen genellikle tıkanmış bir ev bağlantısı ve rastgele başarısız görünen bir kamerayla sonuçlanır.
Kimlik doğrulamayı yayınladığınız kenara koyun
TLS, izleyici kimlik doğrulaması ve erişim günlüğü genel giriş noktasına aittir, kameraya değil. Bu, kameranın kimlik bilgilerini akışın kimlik bilgilerinden ayrı tutar. Ayrıca bir kitle üyesi ayrıldığında erişimi iptal etmek için tek bir yer verir. Bu kontrolleri bunun yerine kameraya koymak, her kitle değişikliğinin asla genel olarak erişilebilir olmaması gereken bir cihazda yönetici değişikliğine dönüşmesi anlamına gelir.
VPN'i ve kameranın yönetim izinlerini yayın yolundan ayrı tutun. Bir akış çekmek için kameranın web arayüzüne ulaşabilen bir VPS, o arayüzü dışa açan makine de olmamalıdır. Kitle kameranın adresini asla öğrenmemelidir.
Ardından zincirin çalıştığını varsaymak yerine gerçekten inşa ettiğiniz iki ucu doğrulayın:
$ 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
Özel kaynağın başarılı bir şekilde yoklanması ve genel kenarda çalma listesinin başarılı şekilde alınması tasarımın farklı yarılarını kanıtlar. Bunları ayrı ayrı test edin. Kitlenizin kullandığı aynı tür istemciden oynatma, tüm zinciri kapsayan tek testtir.
Sonunda her halkasında bir amaç olan bir zincir elde edersiniz: özel kaynak, kısıtlı alım, seçilmiş paketleme, yetkili izleyici girişi. Bu halkaların hiçbiri isteğe bağlı değildir ve hiçbiri bir port açılarak oluşturulmaz.