Jūsu privātais HLS strauts ielādējas jums, ne jūsu skatītājiem

Jūs pārbaudāt lapu klēpjdatorā, atskaņotājs sāk darboties, un biļete tiek aizvērta. Skatītājs otrā pusē atver to pašu lapu un iegūst rotējošu indikatoru, kas nekad nebeidzas. Ierastais skaidrojums ir tāds, ka VPN atrodas serverī, tāpēc atskaņošanai būtu jādarbojas — bet tieši pārlūks ir komponente, kas pieprasa atskaņošanas sarakstu, un tam ir savs tīkla ceļš. Lapa, kas iegulta serverī ar privātu piekļuvi, neaizdod šo piekļuvi tam, kas to ielādē.

Runā ir par esošu ASP.NET lapu, kas atskaņo HLS avotu, piemēram, http://10.5.5.9:8080/live/stream.m3u8, kas ir ilustratīva privāta adrese. Darbojas divi izkārtojumi; viens no tiem, visticamāk, nav tas, ko jūs uzbūvējāt.

Mīts: ielādēta lapa pierāda mediju ceļu

Tās lapas HTML nāk no jūsu tīmekļa servera, pa to maršrutu, kāds jūsu tīmekļa serverim ir. Atskaņošanas saraksts un segmenti nāk no mediju avota, pa to maršrutu, kāds ir pieprasījumu veicošajai komponentei. Kad atskaņotājs darbojas skatītāja pārlūkā, tie ir divi dažādi klienti, divas dažādas avota adreses un bieži divas dažādas kļūmju jomas. Tas, ka pirmais izdodas, neko nepasaka par otro.

Tas, ko jūsu tests patiešām pierādīja, ir šaurāks, nekā izskatījās: jūsu mašīna vienlaikus sasniedz gan publisko lapu, gan privāto mediju resursdatoru. Skatītāja mašīna nekad nebija eksperimenta daļa.

Ko atskaņošanas saraksts pieprasa tālāk

RFC 8216 atdala mediju atskaņošanas sarakstus, kuros uzskaitīti segmenti, no galvenajiem sarakstiem, kuros uzskaitīti citi saraksti, un atrisina relatīvos URI attiecībā pret tā saraksta URI, kurā tie atrodas. Tieši šo noteikumu cilvēki izlaiž. Vienas .m3u8 datnes veiksmīga iegūšana nav atskaņošanas tests, jo iegūtā datne ir indekss, nevis mediji.

Sekojiet ķēdei tā, kā to dara atskaņotājs: atveriet izvēlēto sarakstu, pēc tam pieprasiet resursus, ko tas nosauc, un pēc tam sekojiet jebkuram pāradresējumam. Saraksts, kas tiek pasniegts caur sasniedzamu tīmekļa serveri, joprojām var nosūtīt skatītāju uz nesasniedzamu privātu adresi. Tāpat relatīva saraksta pārvietošana uz citu URL maina bāzi, pret kuru tiek atrisināti tā ieraksti, un tāpēc pirmā redzamā URL pārrakstīšana un apstāšanās tur parasti rada derīgu izskatu sarakstu, kuru nevar atskaņot.

Tieša skatīšanās: skatītājam vajadzīgs ceļš

Ja skatītājiem mediju resursdators jāsasniedz tieši, viņu ierīcēm vajadzīgs apstiprinātais VPN vai cits privāts ceļš, DNS, kas atrisina tos vārdus, kurus jūs faktiski izmantojāt, atļauja sasniegt šos galamērķus un jebkura autentifikācija, ko pieprasa mediju pakalpojums. Pārbaudiet katru no tiem skatītāja ierīcē, nevis serverī. Pārlūks tālrunī ar instalētu, bet nepievienotu VPN profilu ir bieža un pilnībā atkārtojama kļūme.

Šis izkārtojums saglabā avotu privātu un novirza piekļuves prasību uz auditoriju. Tas ir politisks lēmums ne mazāk kā tehnisks, tāpēc pirms projektēšanas ap to apstipriniet, ka katram paredzētajam skatītājam ir atļauts turēt šo ceļu.

Piegāde no servera: viens kontrolēts ieejas punkts

Alternatīva ir autorizēts mediju frontends, kas iegūst avotu pa savu privāto ceļu un publicē no jauna tikai skatītājam vērstos resursus. Turiet sarakstu, segmentus un visus atslēgu resursus saskaņotus ar šo vienīgo ieejas punktu, citādi atskaņotājs iegūs pārrakstītu sarakstu caur frontendu un segmentus tieši no adreses, kuru skatītājs nevar sasniegt.

Ierobežojiet avotu un atļautos ceļus šajā frontendā. Lietotāja sniegts patvaļīgs URL pārvērš noderīgu starpniekserveri par neierobežotu jūsu iekšējā tīkla ieguvēju, kas ir daudz sliktāka problēma nekā strauts, kas neatskaņojas. Ievietojiet avotu un ceļa prefiksu atļauto sarakstā, tā vietā lai validētu virkni pēc fakta.

Esošam HLS avotam vispirms pārbaudiet, vai pietiek ar kontrolētu pārsūtīšanu; VPN pa vidu nenozīmē, ka nepieciešama pārkodēšana. Pēc tam validējiet faktisko pārlūka un kodeka kombināciju, jo sasniedzama atbilde un atbalstīts formāts ir divi atsevišķi nosacījumi. Saglabājiet avota TLS, autentifikāciju un pārlūka drošības prasības neskartas — iegults atskaņotājs nav no tām atbrīvots.

Pārbaudiet ķēdi, nevis URL

Veiciet pārbaudes no komponentes, kas patiešām veiks katru pieprasījumu, un uzskatiet katru soli par atsevišķu rezultātu:

curl -s http://10.5.5.9:8080/live/stream.m3u8
curl -s -o /dev/null -w '%{http_code}\n' http://10.5.5.9:8080/live/segment-000123.ts

Pēc tam atkārtojiet to paša skatītāja pārlūkā ar paredzēto strautu, nevis ar testa paraugu no jūsu galda. Lapas ielāde, saraksta ielāde, segmenta iegūšana un autorizācijas kļūme ir četri atšķirīgi rezultāti, un jūs vēlaties redzēt visus četrus, pirms to nosaukt par salabotu. Neinstalējiet novecojušu pārlūka spraudni tāpēc, ka vecs piemērs tā atskaņoja vienu strautu; trūkstošā daļa parasti ir skatītāja ceļš vai neparakstīts segmenta URL.

Kad izkārtojums ir apzināts, pierakstiet to vienā rindā: kas iegūst medijus, pa kuru ceļu un ko skatītājam ir atļauts pieprasīt. Šis teikums atrisina lielāko daļu turpmāko strīdu par to, kam strauts patiešām ir paredzēts.