Je privé-HLS-stream laadt voor jou, niet voor je kijkers

Je test de pagina op je laptop, de speler start en het ticket wordt gesloten. De kijker aan de andere kant opent dezelfde pagina en krijgt een spinner die nooit oplost. De gebruikelijke uitleg is dat de VPN op de server staat, dus het afspelen zou moeten werken — maar juist de browser is het onderdeel dat de playlist opvraagt, en die heeft zijn eigen netwerkpad. Een pagina die is ingebed op een server met privétoegang leent die toegang niet uit aan wie hem laadt.

Dit gaat over een bestaande ASP.NET-pagina die een HLS-bron afspeelt zoals http://10.5.5.9:8080/live/stream.m3u8, een illustratief privéadres. Twee opstellingen werken; een ervan is waarschijnlijk niet degene die je hebt gebouwd.

Mythe: een ladende pagina bewijst het mediapad

De HTML van die pagina komt van je webserver, via welke route je webserver ook heeft. De playlist en de segmenten komen van de mediaoorsprong, via welke route het aanvragende onderdeel ook heeft. Wanneer de speler in de browser van de kijker draait, zijn dat twee verschillende clients, twee verschillende bronadressen en vaak twee verschillende storingsdomeinen. Dat de eerste slaagt, zegt niets over de tweede.

Wat je test werkelijk bewees, is smaller dan het leek: jouw machine bereikt tegelijk de openbare pagina en de privé-mediaserver. De machine van de kijker maakte nooit deel uit van het experiment.

Wat de playlist hierna vraagt

RFC 8216 scheidt media-playlists, die segmenten opsommen, van master-playlists, die andere playlists opsommen, en lost relatieve URI’s op ten opzichte van de URI van de playlist die ze bevat. Precies die regel slaan mensen over. Eén .m3u8-bestand met succes ophalen is geen afspeltest, want het bestand dat je ophaalde is een index, niet de media.

Volg de keten zoals de speler dat doet: open de gekozen playlist, vraag dan de bronnen op die hij noemt en volg daarna elke omleiding. Een playlist die via een bereikbare webserver wordt aangeboden, kan de kijker alsnog naar een onbereikbaar privéadres sturen. Evenzo verandert het verplaatsen van een relatieve playlist naar een andere URL de basis waartegen de vermeldingen worden opgelost, en daarom levert het herschrijven van de eerste zichtbare URL en daar stoppen meestal een geldig uitziende playlist op die niet kan afspelen.

Direct kijken: de kijker heeft het pad nodig

Als kijkers de mediaserver rechtstreeks moeten bereiken, hebben hun apparaten de goedgekeurde VPN of een ander privépad nodig, DNS dat de namen oplost die je werkelijk gebruikte, toestemming om die bestemmingen te bereiken en alle authenticatie die de mediadienst vereist. Controleer elk daarvan op het apparaat van de kijker en niet op de server. Een browser op een telefoon met een geïnstalleerd maar niet verbonden VPN-profiel is een veelvoorkomende en volledig reproduceerbare fout.

Deze opstelling houdt de bron privé en schuift de toegangseis naar het publiek. Het is een beleidsbeslissing evenzeer als een technische, dus bevestig dat elke bedoelde kijker dat pad mag hebben voordat je eromheen ontwerpt.

Levering vanaf de server: één gecontroleerd toegangspunt

Het alternatief is een gemachtigde media-frontend die de bron via zijn privépad ophaalt en alleen de bronnen die de kijker ziet opnieuw publiceert. Houd de playlist, de segmenten en eventuele sleutelbronnen consistent met dat ene toegangspunt, anders haalt de speler een herschreven playlist via de frontend en de segmenten rechtstreeks van een adres dat de kijker niet kan bereiken.

Beperk de bron en de toegestane paden in die frontend. Een willekeurige URL die de gebruiker aanlevert verandert een nuttige proxy in een onbeperkte ophaler van je interne netwerk, wat een veel erger probleem is dan een stream die niet afspeelt. Zet de oorsprong en het padprefix op een toegestane lijst in plaats van de tekenreeks achteraf te valideren.

Controleer voor een bestaande HLS-bron eerst of gecontroleerd doorsturen voldoende is; een VPN ertussen betekent niet dat transcodering nodig is. Valideer daarna de werkelijke combinatie van browser en codec, want een bereikbaar antwoord en een ondersteund formaat zijn twee afzonderlijke voorwaarden. Houd TLS, authenticatie en browserbeveiligingseisen van de oorsprong intact — een ingebedde speler is daarop geen uitzondering.

Test de keten, niet de URL

Voer de controles uit vanuit het onderdeel dat werkelijk elk verzoek doet, en behandel elke stap als zijn eigen resultaat:

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

Herhaal het daarna in de browser van de kijker zelf met de bedoelde stream, niet met een testpatroon van je bureau. Paginaladen, playlist laden, segment ophalen en een autorisatiefout zijn vier verschillende uitkomsten, en je wilt ze alle vier hebben gezien voordat je het opgelost noemt. Installeer geen verouderde browserplug-in omdat een oud voorbeeld zo één stream afspeelde; het ontbrekende stuk is meestal het pad van de kijker of de niet-ondertekende segment-URL.

Als de opstelling eenmaal bewust is, schrijf hem dan in één regel op: wie haalt de media op, via welk pad, en wat mag de kijker opvragen. Die zin beslecht de meeste toekomstige discussies over voor wie de stream echt bedoeld is.