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 रिफ़्लेक्टर टनल और LAN के बीच घोषणाएँ दोहराता है, और Avahi एक रिफ़्लेक्टर अनुभाग देता है जो स्पष्ट इंटरफ़ेस सूची लेता है। रिले को संकीर्ण रखें, और पुष्टि करें कि घोषित पता दोनों ओर से पहुँच योग्य है, वरना जवाब अभी भी ऐसे सबनेट की ओर इशारा करता है जहाँ दर्शक राउट नहीं कर सकता।

राउटिंग के बजाय ब्रिज करें। एक TAP सेगमेंट जिसमें सर्वर tap डिवाइस को LAN पर ब्रिज करता है, दोनों सिरों को एक ब्रॉडकास्ट डोमेन में रखता है, इसलिए घोषणाएँ अपरिवर्तित पार होती हैं। यह सबसे महँगा विकल्प भी है, क्योंकि एक सबनेट का अर्थ एक विफलता डोमेन है और LAN की हर मल्टीकास्ट सेवा अब हर पीयर तक पहुँचती है।

क्या मदद नहीं करता, चाहे कितनी भी बार सुझाया जाए

ब्रिज के बिना dev tun को dev tap से बदलने पर एक TAP डिवाइस रह जाता है जो अभी भी राउटेड है, इसलिए व्यवहार नहीं बदलता। client-to-client पीयर-टू-पीयर यूनिकास्ट की अनुमति देता है और ब्रॉडकास्ट नहीं बहाता। खोज पोर्ट को एक होस्ट पर फ़ॉरवर्ड करने से समूह-पते वाला ट्रैफ़िक नहीं पहुँचता। एक पते से बँधा मीडिया सर्वर उसी पते पर जवाब देता रहता है जब तक उसका अपना कॉन्फ़िगरेशन VPN इंटरफ़ेस सूचीबद्ध न करे।

एक सीधा यूनिकास्ट अनुरोध आज़माएँ, फिर एक घोषित अनुरोध। यदि पहला काम करे और दूसरा नहीं, तो टनल स्वस्थ है और खोज ही पूरी समस्या है।