Ваш прыватны HLS-паток грузіцца для вас, а не для вашых гледачоў

Вы правяраеце старонку на ноўтбуку, прайгравальнік запускаецца, і заяўка закрываецца. Глядач на іншым канцы адкрывае тую ж старонку і атрымлівае круцёлку, якая ніколі не развязаўваецца. Звычайнае тлумачэнне такое: VPN стаіць на серверы, таму прайграванне павінна працаваць — але менавіта браўзер запытвае спіс прайгравання, і ў яго ўласны сеткавы шлях. Старонка, убудаваная на серверы з прыватным доступам, не пазычае гэты доступ таму, хто яе загружае.

Гаворка ідзе пра існуючую старонку ASP.NET, якая прайграе крыніцу HLS, напрыклад http://10.5.5.9:8080/live/stream.m3u8, што з’яўляецца ілюстрацыйным прыватным адрасам. Працуюць дзве схемы; адна з іх, хутчэй за ўсё, не тая, якую вы пабудавалі.

Міф: загрузка старонкі даказвае шлях да медыя

HTML гэтай старонкі прыходзіць з вашага вэб-сервера, па тым маршруце, які мае ваш вэб-сервер. Спіс прайгравання і сегменты прыходзяць з медыя-крыніцы, па тым маршруце, які мае кампанент, што робіць запыт. Калі прайгравальнік працуе ў браўзеры гледача, гэта два розныя кліенты, два розныя адрасы крыніцы і часта два розныя дамены адмоваў. Убачыць поспех першага не кажа нічога пра другі.

Тое, што ваш тэст насамрэч даказаў, вузкае, чым здавалася: ваша машына можа дасягаць публічнай старонкі і прыватнага медыя-хоста адначасова. Машына гледача ніколі не была часткай эксперыменту.

Што спіс прайгравання запытвае далей

RFC 8216 аддзяляе медыя-спісы прайгравання, якія пералічваюць сегменты, ад галоўных спісаў прайгравання, якія пералічваюць іншыя спісы, і вырашае адносныя URI адносна URI спісу, што іх змяшчае. Менавіта гэтае правіла людзі і прапускаюць. Паспяховае атрыманне аднаго файла .m3u8 не з’яўляецца тэстам прайгравання, бо атрыманы файл — гэта індэкс, а не медыя.

Ідзіце па ланцугу так, як гэта робіць прайгравальнік: адкрыйце выбраны спіс прайгравання, запытайце рэсурсы, якія ён называе, потым выканайце любое перанакіраванне. Спіс прайгравання, які выдаецца праз дасяжны вэб-сервер, можа ўсё роўна накіраваць гледача на недасяжны прыватны адрас. Гэтак жа перанос адноснага спісу на іншы URL змяняе базу, адносна якой вырашаюцца яго запісы, і таму перапісванне першага бачнага URL з прыпынкам на гэтым месцы звычайна дае спіс, які выглядае слушным, але не можа прайграцца.

Простае бачанне: гледачу патрэбен шлях

Калі гледачы павінны дасягаць медыя-хоста напрамую, іх прылады маюць патрэбу ў адабраным VPN або іншым прыватным шляху, у DNS, які вырашае менавіта тыя імёны, што вы выкарыстоўвалі, у дазволе дасягаць гэтых пунктаў прызначэння, і ў любой аўтэнтыфікацыі, якой патрабуе медыя-сэрвіс. Правярайце кожнае на прыладзе гледача, а не на серверы. Браўзер на тэлефоне з усталяваным, але не падключаным профілем VPN — частая і цалкам узнаўляльная адмова.

Гэтая схема пакідае крыніцу прыватнай і перакладвае патрабаванне доступу на аўдыторыю. Гэта рашэнне палітыкі не менш, чым тэхнічнае, таму перад праектаваннем пацвердзіце, што кожнаму меркаванаму гледачу дазволена трымаць гэты шлях.

Падача з боку сервера: адна кіраваная кропка ўваходу

Альтэрнатыва — аўтарызаваны медыя-фронтэнд, які забірае крыніцу праз свой прыватны шлях і публікуе паўторна толькі тыя рэсурсы, што бачыць глядач. Трымайце спіс прайгравання, сегменты і любыя ключавыя рэсурсы ўзгодненымі з гэтай адзінай кропкай уваходу, інакш прайгравальнік забярэ перапісаны спіс праз фронтэнд, а сегменты — напрамую з адрасу, які глядач не можа дасягнуць.

Абмяжуйце крыніцу і дазволеныя шляхі ў гэтым фронтэндзе. Адвольны URL, які падае карыстальнік, ператварае карысны проксі ў неабмежаваны сродак вычытвання вашай унутранай сеткі, а гэта значна горшая праблема, чым паток, які не прайграецца. Унясіце крыніцу і прэфікс шляху ў белы спіс замест праверкі радка пасля факту.

Для існуючай крыніцы HLS спачатку праверце, ці дастаткова кіраванага пракідання; наяўнасць VPN пасярэдзіне не азначае, што патрэбна перакадзіраванне. Затым праверце фактычнае спалучэнне браўзера і кодека, бо дасяжны адказ і падтрыманы фармат — розныя ўмовы. Захоўвайце TLS, аўтэнтыфікацыю і патрабаванні бяспекі браўзера нязменнымі — убудаваны прайгравальнік не вызваляе ад іх.

Правярайце ланцуг, а не URL

Выконвайце праверкі з таго кампанента, які сапраўды зробіць кожны запыт, і разглядайце кожны крок як асобны вынік:

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

Потым паўтарыце гэта ў браўзеры самога гледача з мэтавым патокам, а не з тэставым узорам са свайго стала. Загрузка старонкі, загрузка спісу прайгравання, атрыманне сегмента і адмова аўтарызацыі — чатыры асобныя вынікі, і вы жадаеце ўбачыць усе чатыры, перш чым назваць гэта выпраўленым. Не ўсталёўвайце састарэлы плагін браўзера толькі таму, што стары прыклад так прайграў адзін паток; звычайна не стае шляху гледача або непадпісанага URL сегмента.

Калі схема выбрана свядома, запішыце яе адным радком: хто забірае медыя, па якім шляху і што гледачу дазволена запытваць. Гэтае сказ вырашае большасць будучых спрэчак пра тое, для каго насамрэч прызначаны паток.