השידור נעצר ב-VPN: גילוי, שליטה או זרימה?
מקלט חסר, הפעלה שנדחתה וזרימה שנתקעת נכשלים במקומות שונים. תנו שם לשלב לפני שאתם משנים את מדיניות ה-VPN בטלפון או את הרשת.
השידור נשבר בשלושה מקומות שנראים זהים מהספה. ייתכן שהטלפון לא יראה את המקלט כלל, המקלט עשוי להופיע ואז לדחות את ההפעלה, או שההפעלה תתחיל ותיתקע דקה לאחר מכן. מנהרה בטלפון משנה כל אחד מהנתיבים האלה אחרת, ובאחד מהם היא לא משנה דבר. תנו שם לשלב שנכשל קודם, ואז החליטו אם שינוי מדיניות הוא בכלל המנוף הנכון.
תנו שם לשלב שנכשל לפני שאתם משנים מדיניות
שימו לב מה הטלפון עושה מיד לאחר שאתם מקישים על סמל השידור. רשימה ריקה היא תוצאת גילוי, הקשה שמדווחת על כשל היא תוצאת שליטה, והפעלה שמתחילה לפני שהיא נתקעת היא תוצאת הפעלה. לשלושה האלה יש בעלים שונים, ורק השניים הראשונים נוגעים בדרך כלל בהגדרות המנהרה של הטלפון.
| Stage | What the phone shows | Evidence that separates it |
|---|---|---|
| Discovery | No receiver in the list | Another device on the same segment sees the receiver |
| Control | Receiver listed, session refused | Port answer versus permission prompt |
| Playback | Session starts, then stalls | The receiver's own link, not the phone's |
רשמו את השלב לפני שאתם משנים משהו. תיקון שמוחל על השלב הלא נכון הופך את הבדיקה הבאה לבלתי קריאה, ורוב הפולקלור על שידור מגיע בדיוק מהבלבול הזה.
גילוי הוא תעבורה מקומית, ומנהרה מסתירה אותו
מקלטים מכריזים על עצמם באמצעות הכרזות מקומיות והטלפון מוצא אותם בשאילתות על אותו קישור, ולכן כל דבר שמסיר את הטלפון מהקישור הזה מסיר גם את המקלט מהרשימה. מנהרה שמנתבת את כל התעבורה הרחק מה-LAN יכולה להסתיר את ההחלפות האלה, והרשאת רשת מקומית ברמת האפליקציה יכולה לחסום אותן גם כשהנתיב קיים. Wi-Fi לאורחים עם בידוד לקוחות יוצר את אותה רשימה ריקה בלי שום VPN. הוכיחו ששני המכשירים חולקים מקטע לפני שאתם מאשימים את המנהרה.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRהפקודה הראשונה מפרטת מה מכריז על עצמו במקטע של מחשב העזר, והשנייה שואלת ישירות את קבוצת ה-DNS הרב-שידורית. מקלט שלא מופיע בשתיהן גם לא יופיע באפליקציה בטלפון, יהיה מצב המנהרה אשר יהיה. אם המקלט נראה ממכשיר שהמנהרה שלו כבויה ואינו נראה ממכשיר שהמנהרה שלו דלוקה, מצאתם את השלב ואת הסיבה יחד.
חריג LAN משאיר את המנהרה פעילה
לקוחות רבים מציעים חריג רשת מקומית שמשאיר את המנהרה פעילה ומתיר כתובות מקומיות. השתמשו בהגדרה המתועדת הזו במקום לכבות את ה-kill switch או את חומת האש כולה, מפני שאלה משנים הרבה יותר ממה שהשידור צריך. אם הרשת מפרידה מכשירים חכמים בכוונה, בקשו מבעל הרשת את תעבורת הגילוי, השליטה והחזרה הספציפית במקום גישה שטוחה.
nc -vz 192.168.1.50 8009בדיקת שליטה מול המקלט מפרידה בין הרשאה לנגישות: פורט שעונה משמעו שהנתיב קיים, ואילו סירוב משמעו שלטלפון הותר לגלות את המכשיר והוא עדיין לא יכול לדבר איתו. פורטים 8008 ו-8009 הם פורטי השידור הרגילים, ואפליקציה עשויה להשתמש באחרים, ולכן התייחסו לפורט אחד שנדחה כרמז ולא כפסק דין. החריג והרשאת האפליקציה נשארים בלתי תלויים, משום שהענקת גישה מקומית אינה יוצרת נתיב והוספת נתיב אינה מעניקה הרשאה. ה-kill switch יכול גם להפיל תעבורה מקומית לאחר חיבור מחדש, ולכן יש לבדוק את הגילוי שוב ברגע שהמנהרה חוזרת.
ייתכן שההפעלה לא משתמשת בחיבור של הטלפון
בהפעלה שמכוונת על ידי האפליקציה הטלפון מוסר למקלט כתובת מדיה והמקלט מוריד אותה דרך החיבור שלו, כך ששינוי הכתובת הציבורית של הטלפון לא עושה דבר לזרימה. כותרת המוגבלת בחשבון עדיין עלולה להיכשל מסיבותיה שלה, ודרישות השידור של Google מכסות תאימות אפליקציה ומכשיר ולא את נתיב הרשת. העברת הטלוויזיה עצמה דרך מנהרה היא תצורה נפרדת עם שאלות מדיניות משלה.
שני סימנים מבדילים בין המצבים. שידור ששורד נעילת מסך של הטלפון מכוון על ידי האפליקציה, מפני שהמקלט מוריד בעצמו; שיקוף שנעצר כשמסך השולח ננעל הוא זרימה רציפה מהטלפון. כשהגילוי והשליטה מצליחים אבל ההפעלה נתקעת, הסתכלו במקום זאת על קישור ה-Wi-Fi של המקלט ועל נתיב האינטרנט שלו, מפני שבדיקת מהירות בטלפון מתארת את הטלפון ולא את הטלוויזיה.
בטלו את החריג ובדקו שוב
כל שינוי זמני צריך דרך חזרה, והסדר חשוב. הסירו את חריג ה-LAN, חברו את המנהרה מחדש כדי שהלקוח יישם שוב את המדיניות שלו, ואז חזרו על שלב הגילוי ורשמו אם המקלט נעלם שוב. הרצף הזה אומר לכם אם החריג עשה את העבודה או שמשהו אחר השתנה בינתיים.
# after removing the LAN exception, reconnect and confirm the tunnel is up
resolvectl status | grep -E 'DNS Servers|Default Route|Protocols'
avahi-browse -at | grep -i -E 'chromecast|googlecast'אמתו את שלושת השלבים בנפרד לאחר מכן, מפני שהצלחה באחד לא אומרת דבר על האחרים. אחר כך בדקו שאפליקציות אחרות בטלפון עדיין הולכות בנתיב המיועד, מפני שחריג מקומי שהפך בשקט לעקיפה מלאה הוא תוצאה גרועה יותר משידור שדורש הקשה נוספת אחת.