Den private HLS-straumen din lastar for deg, ikkje for sjåarane dine
Sida lastar fordi tenaren din når kameraet; nettlesaren hentar likevel spelelista. Avgjer kven som sender førespurnaden, og test deretter kjeda.
Du testar sida på den berbare datamaskinen, spelaren startar, og saka blir lukka. Sjåaren i den andre enden opnar same sida og får ein snurrande indikator som aldri blir løyst opp. Den vanlege forklaringa er at VPN-en ligg på tenaren, så avspelinga burde verke — men det er nettlesaren som ber om spelelista, og han har sin eigen nettverksveg. Ei side som er bygd inn på ein tenar med privat tilgang, låner ikkje den tilgangen til den som lastar ho.
Dette handlar om ei eksisterande ASP.NET-side som spelar av ei HLS-kjelde som http://10.5.5.9:8080/live/stream.m3u8, som er ei illustrerande privat adresse. To oppsett verkar; eitt av dei er truleg ikkje det du bygde.
Myte: ei side som lastar provar medievegen
HTML-en til den sida kjem frå nettenaren din, over den ruta nettenaren din har. Spelelista og segmenta kjem frå mediekjelda, over den ruta komponenten som sender førespurnaden har. Når spelaren køyrer i nettlesaren til sjåaren, er det to ulike klientar, to ulike kjeldeadresser og ofte to ulike feildomene. At den første lukkast, seier ingenting om den andre.
Det testen din faktisk prova, er smalare enn det såg ut: maskinen din når både den offentlege sida og den private medieverten samstundes. Maskinen til sjåaren var aldri del av eksperimentet.
Kva spelelista ber om neste gong
RFC 8216 skil mellom mediespelelister, som listar opp segment, og hovudspelelister, som listar opp andre spelelister, og løyser relative URI-ar mot URI-en til spelelista som inneheld dei. Den regelen er den delen folk hoppar over. Å hente éi .m3u8-fil med suksess er ikkje ein avspelingstest, fordi fila du henta er ein indeks, ikkje mediet.
Følg kjeda slik spelaren gjer: opne den valde spelelista, be deretter om ressursane ho nemner, og følg deretter kvar omdirigering. Ei speleliste som blir servert via ein tilgjengeleg nettenar kan framleis sende sjåaren til ei utilgjengeleg privat adresse. På same måte endrar flytting av ei relativ speleliste til ein annan URL den basen oppføringane blir løyste mot, og difor gir omskriving av den første synlege URL-en og stopping der vanlegvis ei speleliste som ser gyldig ut, men ikkje kan spelast av.
Direkte vising: sjåaren treng vegen
Viss sjåarane skal nå medieverten direkte, treng einingane deira den godkjende VPN-en eller ein annan privat veg, DNS som løyser namna du faktisk brukte, løyve til å nå desse destinasjonane, og all autentisering som medietenesta krev. Kontroller kvar av dei på eininga til sjåaren i staden for på tenaren. Ein nettlesar på ein telefon med VPN-profilen installert men ikkje tilkopla, er ein vanleg og fullstendig reproduserbar feil.
Dette oppsettet held kjelda privat og skyv tilgangskravet over på publikum. Det er ei politisk avgjerd like mykje som ei teknisk, så stadfest at kvar tiltenkt sjåar har løyve til å ha den vegen før du designar rundt han.
Levering frå tenaren: eitt kontrollert inngangspunkt
Alternativet er ein autorisert medie-frontend som hentar kjelda over sin private veg og publiserer på nytt berre ressursane som vender mot sjåaren. Hald spelelista, segmenta og eventuelle nøkkelressursar konsistente med det eine inngangspunktet, elles hentar spelaren ei omskriven speleliste gjennom frontend-en og segmenta direkte frå ei adresse sjåaren ikkje kan nå.
Avgrens kjelda og dei tillatne vegane i den frontend-en. Ein vilkårleg URL som brukaren gir, gjer ein nyttig proxy til ein ubegrensa hentar av det interne nettet ditt, noko som er eit mykje verre problem enn ein straum som ikkje vil spele av. Set kjelda og vegprefikset på ei tillaten liste i staden for å validere strengen i etterkant.
For ei eksisterande HLS-kjelde, kontroller først om kontrollert videresending er nok; ein VPN i midten betyr ikkje at transkoding er naudsynt. Valider deretter den faktiske kombinasjonen av nettlesar og kodek, fordi eit tilgjengeleg svar og eit støtta format er to separate vilkår. Hald TLS, autentisering og nettlesartryggleikskrav frå kjelda intakte — ein innebygd spelar er ikkje eit unntak frå dei.
Test kjeda, ikkje URL-en
Køyr kontrollane frå komponenten som faktisk vil sende kvar førespurnad, og handsam kvar steg som sitt eige resultat:
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.tsGjenta det deretter i nettlesaren til sjåaren sjølv med den tiltenkte straumen, ikkje med eit testmønster frå skrivebordet ditt. Sideinnlasting, innlasting av spelelista, henting av segmentet og ein autorisasjonsfeil er fire ulike utfall, og du vil ha alle fire observerte før du kallar det løyst. Ikkje installer ein utdatert nettlesarplugin fordi eit gammalt døme spelte av ein straum på den måten; den manglande biten er vanlegvis vegen til sjåaren eller den usignerte URL-en til segmentet.
Når oppsettet er medvite, skriv det ned på éi linje: kven hentar mediet, over kva veg, og kva sjåaren har løyve til å be om. Den setninga avgjer dei fleste framtidige diskusjonar om kven straumen eigentleg er for.