זרם ה-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 הלא חתום של המקטע.

כשהסידור מכוון, כתוב אותו בשורה אחת: מי מושך את המדיה, באיזה נתיב, ומה הצופה רשאי לבקש. המשפט הזה מכריע את רוב הוויכוחים העתידיים על למי הזרם באמת מיועד.