Din private HLS-strøm lastes for deg, ikke for seerne dine

Du tester siden på laptop, spilleren starter, og saken lukkes. Seeren i den andre enden åpner samme side og får en spinner som aldri løses opp. Den vanlige forklaringen er at VPN ligger på serveren, så avspillingen burde virke — men det er nettleseren som ber om spillelisten, og den har sin egen nettverksvei. En side som er bygget inn på en server med privat tilgang, låner ikke den tilgangen til den som laster den.

Dette handler om en eksisterende ASP.NET-side som spiller av en HLS-kilde som http://10.5.5.9:8080/live/stream.m3u8, som er en illustrerende privat adresse. To oppsett virker; ett av dem er sannsynligvis ikke det du bygde.

Myte: en side som lastes beviser mediebanen

HTML-en til den siden kommer fra nettserveren din, over den ruten nettserveren din har. Spillelisten og segmentene kommer fra mediekilden, over den ruten komponenten som sender forespørselen har. Når spilleren kjører i seerens nettleser, er det to forskjellige klienter, to forskjellige kildeadresser og ofte to forskjellige feildomener. At den første lykkes, sier ikke noe om den andre.

Det testen din faktisk beviste, er smalere enn det så ut: maskinen din når både den offentlige siden og den private medieverten samtidig. Seerens maskin var aldri en del av eksperimentet.

Hva spillelisten ber om neste gang

RFC 8216 skiller mellom mediespillelister, som lister opp segmenter, og hovedspillelister, som lister opp andre spillelister, og løser relative URI-er mot URI-en til spillelisten som inneholder dem. Den regelen er den delen folk hopper over. Å hente én .m3u8-fil med suksess er ikke en avspillingstest, fordi filen du hentet er en indeks, ikke mediet.

Følg kjeden slik spilleren gjør: åpne den valgte spillelisten, be deretter om ressursene den navngir, og følg deretter enhver omdirigering. En spilleliste som serveres via en tilgjengelig nettserver kan fortsatt sende seeren til en utilgjengelig privat adresse. På samme måte endrer flytting av en relativ spilleliste til en annen URL den basen oppføringene løses mot, og derfor gir omskriving av den første synlige URL-en og stopping der vanligvis en spilleliste som ser gyldig ut, men ikke kan spilles av.

Direkte visning: seeren trenger banen

Hvis seerne skal nå medieverten direkte, trenger enhetene deres den godkjente VPN-en eller en annen privat bane, DNS som løser navnene du faktisk brukte, tillatelse til å nå disse destinasjonene, og all autentisering medietjenesten krever. Kontroller hver av dem på seerens enhet i stedet for på serveren. En nettleser på en telefon med VPN-profilen installert men ikke tilkoblet, er en vanlig og fullstendig reproduserbar feil.

Dette oppsettet holder kilden privat og skyver tilgangskravet over på publikum. Det er en politisk beslutning like mye som en teknisk, så bekreft at hver tiltenkt seer har lov til å ha den banen før du designer rundt den.

Levering fra serveren: ett kontrollert inngangspunkt

Alternativet er en autorisert medie-frontend som henter kilden over sin private bane og publiserer på nytt bare ressursene som vender mot seeren. Hold spillelisten, segmentene og eventuelle nøkkelressurser konsistente med det ene inngangspunktet, ellers vil spilleren hente en omskrevet spilleliste gjennom frontend-en og segmentene direkte fra en adresse seeren ikke kan nå.

Begrens kilden og de tillatte banene i den frontend-en. En vilkårlig URL oppgitt av brukeren gjør en nyttig proxy til en ubegrenset henter av ditt interne nettverk, noe som er et mye verre problem enn en strøm som ikke vil spille av. Sett kilden og baneprefikset på en tillatt-liste i stedet for å validere strengen i etterkant.

For en eksisterende HLS-kilde, kontroller først om kontrollert videresending er nok; en VPN i midten betyr ikke at transkoding er nødvendig. Valider deretter den faktiske kombinasjonen av nettleser og kodek, fordi et tilgjengelig svar og et støttet format er to separate betingelser. Hold kildens TLS, autentisering og nettlesersikkerhetskrav intakte — en innebygd spiller er ikke et unntak fra dem.

Test kjeden, ikke URL-en

Kjør kontrollene fra komponenten som faktisk vil sende hver forespørsel, og behandle hvert trinn som sitt eget 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.ts

Gjenta det deretter i seerens egen nettleser med den tiltenkte strømmen, ikke med et testmønster fra skrivebordet ditt. Sideinnlasting, innlasting av spillelisten, henting av segmentet og en autorisasjonsfeil er fire forskjellige utfall, og du vil ha alle fire observert før du kaller det løst. Ikke installer en utdatert nettleserplugin fordi et gammelt eksempel spilte av én strøm på den måten; den manglende brikken er vanligvis seerens bane eller segmentets usignerte URL.

Når oppsettet er bevisst, skriv det ned på én linje: hvem henter mediet, over hvilken bane, og hva seeren har lov til å be om. Den setningen avgjør de fleste fremtidige diskusjoner om hvem strømmen egentlig er for.