גילוי Chromecast ו-DLNA לעולם אינו חוצה VPN מנותב

כפתור השידור אינו מציג דבר, VLC DLNA נשאר ריק, והמכונה בצד השני עונה ל-ping בלי להתלונן. השילוב הזה אינו בעיית רוחב פס ולא תעלומת חומת אש. הגילוי בפרוטוקולים האלה הוא חילופי קבוצה בקטע המקומי, ומנהרה מנותבת אינה נושאת תעבורה בעלת כתובת קבוצה. ההפעלה שאתם מנסים להתחיל לעולם אינה מוצעת.

הנגישות בסדר. הגילוי חסר.

המיתוס: המנהרה זקוקה להגדרה או ליותר קיבולת

ההצעות הרגילות הן להפעיל תעבורת עמית-לעמית, להעלות את ה-MTU או לשנות את סוג התקן המנהרה. אף אחת מהן אינה מוסיפה תחום שידור. Multicast נמסר על ידי מתגים ועל ידי מחסנית הרשת המקומית, ולממשק TUN מנקודה לנקודה אין כתובת קבוצה להציף.

שינוי הגדרות יכול להפוך את הכשל לרועש יותר. הוא לא יכול לגרום להכרזה להופיע במקום שהפרוטוקול מעולם לא שלח אחת.

מהו למעשה חילופי הגילוי

שלושה דפוסים מכסים כמעט כל מה שתפגשו. mDNS שולח אל 224.0.0.251 عبر UDP 5353, SSDP שולח אל 239.255.255.250 عبر UDP 1900, ורשימות העיון הישנות של SMB הלכו אל כתובת השידור של תת-הרשת. כל אחת מופנית לקבוצה ולא למארח, וכל אחת מצפה למאזין באותו קטע. מקלט מעבר למנהרה מנותבת אינו בקטע הזה, ולכן שום דבר לא מגיע.

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

קראו לכידה לפני שתשנו את המנהרה

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

שתי דקות של לכידה מחליפות שעה של ניחושים על פורטים: tcpdump -ni tun0 udp port 5353 or udp port 1900.

שלושה תיקונים, הזול קודם

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

העבירו את הפרוטוקול בשער. משקף mDNS חוזר על הכרזות בין המנהרה ל-LAN, ו-Avahi מגיע עם קטע משקף שלוקח רשימת ממשקים מפורשת. שמרו על העברה צרה, וודאו שהכתובת המוכרזת נגישה משני הצדדים, אחרת התשובה עדיין מצביעה על תת-רשת שהצופה אינו יכול לנתב אליה.

גשרו במקום לנתב. קטע TAP שבו השרת מגשר את התקן ה-tap אל ה-LAN מציב את שני הקצוות בתחום שידור אחד, כך שההכרזות עוברות ללא שינוי. זו גם האפשרות היקרה ביותר, כי תת-רשת אחת פירושה תחום כשל אחד וכל שירות multicast ב-LAN מגיע כעת לכל עמית.

מה לא עוזר, בכל תדירות שזה יוצע

החלפת dev tun ב-dev tap בלי גשר מותירה התקן TAP שעדיין מנותב, ולכן ההתנהגות אינה משתנה. client-to-client מתיר unicast בין עמיתים ואינו מציף שידורים. העברת פורט גילוי למארח אחד אינה מספקת תעבורה בעלת כתובת קבוצה. שרת מדיה הקשור לכתובת אחת ממשיך לענות בכתובת הזו עד שתצורתו שלו תפרט את ממשק ה-VPN.

בדקו בקשה ישירה אחת ב-unicast, ואז בקשה מוכרזת אחת. אם הראשונה עובדת והשנייה לא, המנהרה בריאה והגילוי הוא כל הבעיה.