Streaming HLS privat Anda dimuat untuk Anda, bukan untuk penonton Anda

Anda menguji halaman di laptop, pemutar mulai, dan tiket ditutup. Penonton di sisi lain membuka halaman yang sama dan mendapat indikator berputar yang tidak pernah selesai. Penjelasan yang biasa diberikan adalah bahwa VPN ada di server, jadi pemutaran seharusnya berhasil — tetapi perambanlah komponen yang meminta daftar putar, dan ia punya jalur jaringannya sendiri. Halaman yang disematkan di server dengan akses privat tidak meminjamkan akses itu kepada siapa pun yang memuatnya.

Ini tentang halaman ASP.NET yang sudah ada dan memutar sumber HLS seperti http://10.5.5.9:8080/live/stream.m3u8, yang merupakan alamat privat ilustratif. Dua susunan berhasil; salah satunya mungkin bukan yang Anda bangun.

Mitos: halaman yang termuat membuktikan jalur media

HTML halaman itu datang dari server web Anda, melalui rute apa pun yang dimiliki server web Anda. Daftar putar dan segmen datang dari asal media, melalui rute apa pun yang dimiliki komponen yang meminta. Saat pemutar berjalan di peramban penonton, keduanya adalah dua klien berbeda, dua alamat sumber berbeda, dan sering dua domain kegagalan berbeda. Melihat yang pertama berhasil tidak mengatakan apa pun tentang yang kedua.

Yang sebenarnya dibuktikan pengujian Anda lebih sempit daripada kelihatannya: mesin Anda dapat menjangkau halaman publik dan host media privat pada saat yang sama. Mesin penonton tidak pernah menjadi bagian dari percobaan.

Apa yang diminta daftar putar selanjutnya

RFC 8216 memisahkan daftar putar media, yang mencantumkan segmen, dari daftar putar induk, yang mencantumkan daftar putar lain, dan menyelesaikan URI relatif terhadap URI daftar putar yang memuatnya. Aturan itulah bagian yang dilewatkan orang. Mengambil satu berkas .m3u8 dengan berhasil bukan uji pemutaran, karena berkas yang Anda ambil adalah indeks, bukan medianya.

Ikuti rantainya seperti yang dilakukan pemutar: buka daftar putar yang dipilih, lalu minta sumber daya yang disebutnya, lalu ikuti pengalihan apa pun. Daftar putar yang disajikan melalui server web yang terjangkau tetap dapat mengarahkan penonton ke alamat privat yang tidak terjangkau. Demikian pula, memindahkan daftar putar relatif ke URL lain mengubah basis tempat entrinya diselesaikan, dan itulah sebabnya menulis ulang URL pertama yang terlihat lalu berhenti di situ biasanya menghasilkan daftar putar yang tampak sah tetapi tidak dapat diputar.

Penonton langsung: penonton butuh jalurnya

Jika penonton seharusnya mencapai host media secara langsung, perangkat mereka memerlukan VPN yang disetujui atau jalur privat lain, DNS yang menyelesaikan nama yang benar-benar Anda gunakan, izin untuk mencapai tujuan tersebut, dan autentikasi apa pun yang diminta layanan media. Periksa masing-masing di perangkat penonton, bukan di server. Peramban di ponsel dengan profil VPN terpasang tetapi tidak tersambung adalah kegagalan yang umum dan sepenuhnya dapat direproduksi.

Susunan ini menjaga sumber tetap privat dan mendorong syarat akses kepada audiens. Ini keputusan kebijakan sama seperti keputusan teknis, jadi pastikan setiap penonton yang dimaksud diizinkan memegang jalur itu sebelum Anda merancang di sekitarnya.

Pengiriman dari sisi server: satu titik masuk terkendali

Alternatifnya adalah frontend media resmi yang mengambil sumber melalui jalur privatnya dan menerbitkan ulang hanya sumber daya yang menghadap penonton. Jaga daftar putar, segmen, dan sumber daya kunci apa pun tetap konsisten dengan titik masuk tunggal itu, atau pemutar akan mengambil daftar putar yang ditulis ulang melalui frontend dan segmennya langsung dari alamat yang tidak dapat dijangkau penonton.

Batasi sumber dan jalur yang diizinkan di frontend itu. URL sembarangan yang diberikan pengguna mengubah proxy yang berguna menjadi pengambil tanpa batas atas jaringan internal Anda, yang merupakan masalah jauh lebih buruk daripada stream yang tidak dapat diputar. Masukkan sumber dan prefiks jalur ke daftar izin alih-alih memvalidasi string setelah kejadian.

Untuk sumber HLS yang sudah ada, periksa dulu apakah penerusan terkendali sudah cukup; VPN di tengah tidak berarti transkode diperlukan. Lalu validasi kombinasi peramban dan codec yang sebenarnya, karena respons yang terjangkau dan format yang didukung adalah dua syarat terpisah. Jaga TLS, autentikasi, dan persyaratan keamanan peramban dari asal tetap utuh — pemutar yang disematkan bukan pengecualian darinya.

Uji rantainya, bukan URL-nya

Jalankan pemeriksaan dari komponen yang benar-benar akan membuat setiap permintaan, dan perlakukan setiap langkah sebagai hasilnya sendiri:

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

Lalu ulangi di peramban penonton sendiri dengan stream yang dimaksud, bukan dengan pola uji dari meja Anda. Pemuatan halaman, pemuatan daftar putar, pengambilan segmen, dan kegagalan otorisasi adalah empat hasil berbeda, dan Anda ingin keempatnya teramati sebelum menyebutnya beres. Jangan memasang pengaya peramban lama karena contoh lama memutar satu stream dengan cara itu; bagian yang hilang biasanya jalur penonton atau URL segmen yang tidak ditandatangani.

Setelah susunannya disengaja, tuliskan dalam satu baris: siapa yang mengambil media, melalui jalur apa, dan apa yang boleh diminta penonton. Kalimat itu menyelesaikan sebagian besar perdebatan di masa depan tentang untuk siapa stream ini sebenarnya.