Publicēt kameras straumi: RTSP un HLS nav viena mala
RTSP sesijas vadība un HLS piegāde prasa dažādas publiskās malas, pat ja abas sasniedz vienu un to pašu kameru VPN ietvaros. Vispirms izvēlies skatītāja modeli.
Tu atver vienu kameras portu, vērš pret to atskaņotāju un pieņem, ka interneta problēma ir atrisināta. Tad tālrunis to nevar atskaņot, pārlūks to nevar atskaņot, un kameras administrēšanas lapa atrodas tikai viena nepareizi ierakstīta ceļa attālumā no publiskās malas. Izvēlētais piegādes modelis, RTSP vai HLS, nosaka lielāko daļu no tā, pirms ir uzrakstīts kaut viens ugunsmūra noteikums. VPN nodrošina tikai privāto posmu.
VPN salabo avota ceļu, nevis skatītāja ceļu
VPS, kas ar tuneli ir pievienots kameras LAN tīklam, var sasniegt kameru tās privātajā adresē, un tas patiešām ir noderīgi. Tas nozīmē, ka kamerai nav vajadzīgs savs ienākošais ports un mājas maršrutētājs paliek aizvērts. Tas nepasaka, ko runās skatītājs. Darbvirsmas atskaņotājs, pārlūks, tālrunis un viedtelevizors atbalsta dažādus protokolus, un katram ir savas cerības attiecībā uz TLS, autentifikāciju un kodekiem.
Lūk, pieņēmums, ko ir vērts atmest: publicēšana nozīmētu padarīt avotu sasniedzamu. Publicēšana patiesībā nozīmē dot noteiktai auditorijai atbalstītu veidu, kā patērēt mediju. Publicētai straumei ir formāts, auditorija un akreditācijas dati; sasniedzamai kamerai nav neviena no tiem. Sasniedzamība ir tā daļa, ko atrisina tunelis, un skatītāja ieejas punkts ir tā daļa, kas tev vēl jāizstrādā.
RTSP ir sarunas, nevis viens ports
RTSP nes sesijas vadību: klients pieprasa aprakstu, iestata vienu vai vairākas mediju sliedes un pēc tam atskaņo. Pašas mediju transportēšana tiek saskaņota šīs iestatīšanas laikā, tāpēc protokolu nav labi raksturot ar vienu pāradresētu TCP portu. Šīs sarunas ir tā daļa, ko cilvēki palaiž garām, salīdzinot ugunsmūra noteikumus.
Atkarībā no galapunktiem RTP var ierasties atsevišķos UDP portos vai būt savīts vadības savienojumā. Relejs, kas pāradresē tikai 554 un pieņem, ka pārējais strādās, parasti rada sesiju, kas izveido savienojumu, ziņo par sliedi un pēc tam neko neparāda. Pirms rakstīt tam noteikumus, pārbaudi transportu, par kuru tava kamera patiešām vienojas. Ieraksts privātajā pusē to atbild vienas minūtes laikā, un minēšana maksā vakaru.
Mazai, zināmai auditorijai ar saderīgiem atskaņotājiem apzināti konfigurēts RTSP relejs var būt pareizā atbilde. Ierobežo, no kāda avota tas drīkst ievilkt, un pieprasi autentifikāciju relejā. Pieraksti atskaņotājus, kurus pārbaudīji, jo RTSP straume, kas darbojas VLC, pārlūkā joprojām var neizdoties.
HLS ir atskaņošanas saraksts un resursi
HLS skatītājs iegūst atskaņošanas sarakstu un pēc tam iegūst mediju segmentus, ko šis saraksts nosauc. HLS specifikācija definē šo resursu modeli, un svarīgā ekspluatācijas detaļa ir tā, ka atskaņošanas saraksti atsaucas uz citiem URL. Relatīvās atsauces tiek atrisinātas attiecībā pret saraksta atrašanās vietu, tāpēc starpniekserverim, kas pārraksta ceļus, tie ir konsekventi jāpārraksta.
Ja kamera jau nodrošina lietojamu HLS, publisks priekšgals var pārsūtīt šos saraksta un segmentu pieprasījumus caur tuneli. Seko līdzi atslēgām, pāradresācijām un URL, ko ģenerē lietojumprogramma. Jebkurš absolūtais URL, kas norāda uz privātu resursdatoru, salūzt tajā brīdī, kad skatītājs ārpus LAN tam seko. Relatīvie ceļi ir tie, kas pārdzīvo starpniekservera pārrakstīšanu, tāpēc dod tiem priekšroku visur, kur kontrolē ģenerēto izvadi.
Ja kamera runā tikai RTSP, kaut kam ir jāpārvērš avots skatītāja formātā. Pārpakotņošana un pārkodēšana ir dažādi darbi: pārpakotņošana saglabā kodeku, bet pārkodēšana to pārkodē saderības dēļ, un tikai otrais maksā nopietnu CPU jaudu. Neviens no tiem nekļūst vajadzīgs tikai tāpēc, ka ceļā ir VPN.
Plāno augšuplādes plūsmu atkarībā no tā, kur notiek izplatīšana. Viens privāts ievads, kas baro publisku mediju pakalpojumu, uzvedas ļoti atšķirīgi no katra skatītāja, kas velk savu straumi caur tuneli. Otrais modelis parasti beidzas ar pārslogotu mājas savienojumu un kameru, kas šķietami sabojājas nejauši.
Novieto autentifikāciju tajā malā, ko publicē
TLS, skatītāju autentifikācija un piekļuves reģistrēšana pieder publiskajam ieejas punktam, nevis kamerai. Tas notur kameras akreditācijas datus atsevišķi no straumes akreditācijas datiem. Tas arī dod vienu vietu, kur atsaukt piekļuvi, kad kāds auditorijas dalībnieks aiziet. Šo kontroļu novietošana kamerā nozīmē, ka katra auditorijas izmaiņa kļūst par administratīvu izmaiņu ierīcē, kurai nekad nevajadzētu būt publiski sasniedzamai.
Turē VPN un kameras administrēšanas atļaujas atsevišķi no publicēšanas ceļa. VPS, kas var sasniegt kameras tīmekļa saskarni, lai ievilktu straumi, nedrīkstētu būt arī mašīna, kas atver šo saskarni. Auditorijai nekad nevajadzētu uzzināt kameras adresi.
Pēc tam pārbaudi abus galus, kurus tu tiešām uzbūvēji, nevis pieņem, ka ķēde darbojas:
$ 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
Veiksmīga privātā avota zondēšana un veiksmīga atskaņošanas saraksta iegūšana publiskajā malā pierāda dažādas dizaina puses. Pārbaudi tos atsevišķi. Atskaņošana no tāda paša veida klienta, kādu izmanto tava auditorija, ir vienīgais tests, kas aptver visu ķēdi.
Rezultātā tev ir ķēde ar mērķi katrā posmā: privāts avots, ierobežots ievads, izvēlēta pakošana, autorizēta skatītāja ieeja. Neviens no šiem posmiem nav neobligāts, un neviens no tiem nerodas, atverot portu.