اكتشاف Chromecast وDLNA لا يعبر أبدًا نفق VPN موجَّهًا

زر البث لا يعرض شيئًا، وVLC DLNA يبقى فارغًا، والجهاز في الطرف الآخر يستجيب لـ ping دون شكوى. هذه التركيبة ليست مشكلة نطاق ترددي ولا لغز جدار حماية. الاكتشاف في هذه البروتوكولات تبادل جماعي على المقطع المحلي، والنفق الموجَّه لا ينقل حركة المرور الموجهة إلى مجموعات. الجلسة التي تحاول بدءها لا تُعرض أبدًا.

إمكانية الوصول بخير. الاكتشاف مفقود.

الخرافة: يحتاج النفق إلى إعداد أو سعة أكبر

الاقتراحات المعتادة هي تمكين حركة النِّد للنِّد، أو رفع MTU، أو تغيير نوع جهاز النفق. لا يضيف أي منها نطاق بث. يُسلَّم البث المتعدد عبر المحوِّلات وعبر مكدس الشبكة المحلية، وواجهة 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 بث الإعلانات بين النفق والشبكة المحلية، ويأتي Avahi بقسم عاكس يأخذ قائمة واجهات صريحة. أبقِ التمرير ضيقًا، وتأكد أن العنوان المُعلن قابل للوصول من الجانبين، وإلا فما زال الرد يشير إلى شبكة فرعية لا يستطيع المشاهد التوجيه إليها.

استخدم الجسر بدل التوجيه. مقطع TAP مع جسر الخادم لجهاز tap على الشبكة المحلية يضع الطرفين في نطاق بث واحد، فتعبر الإعلانات دون تغيير. وهو أيضًا الخيار الأغلى، لأن شبكة فرعية واحدة تعني نطاق فشل واحدًا وكل خدمة بث متعدد على الشبكة المحلية تصل الآن إلى كل نِد.

ما لا يساعد، مهما تكرر اقتراحه

تغيير dev tun إلى dev tap دون جسر يترك جهاز TAP ما زال موجَّهًا، فلا يتغير السلوك. client-to-client يسمح بالبث الأحادي بين النِّدين ولا يغمر البث الجماعي. تمرير منفذ اكتشاف إلى مضيف واحد لا يوصّل حركة موجهة إلى مجموعات. خادم الوسائط المرتبط بعنوان واحد يستمر في الرد على ذلك العنوان حتى تُدرج تهيئته الخاصة واجهة VPN.

اختبر طلبًا مباشرًا واحدًا ببث أحادي، ثم طلبًا واحدًا مُعلنًا. إذا نجح الأول وفشل الثاني، فالنفق سليم والاكتشاف هو المشكلة كلها.