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 उपकरण LAN वर ब्रिज करणारा TAP सेगमेंट दोन्ही टोके एका प्रसार क्षेत्रात ठेवतो, त्यामुळे जाहिराती अपरिवर्तित पार होतात. हा सर्वात महाग पर्यायही आहे, कारण एक सबनेट म्हणजे एक अपयश क्षेत्र आणि LAN वरील प्रत्येक मल्टिकास्ट सेवा आता प्रत्येक पीअरपर्यंत पोहोचते.

काय मदत करत नाही, कितीही वेळा सुचवले तरी

ब्रिजशिवाय dev tun ला dev tap मध्ये बदलल्यास अजूनही राउटेड TAP उपकरण राहते, त्यामुळे वर्तन बदलत नाही. client-to-client पीअर-टू-पीअर युनिकास्टला परवानगी देते आणि प्रसार भरत नाही. शोध पोर्ट एका होस्टवर फॉरवर्ड केल्याने गट-पत्त्याची वाहतूक पोहोचत नाही. एका पत्त्याला बांधलेला मीडिया सर्व्हर त्याच्या स्वतःच्या कॉन्फिगरेशनमध्ये VPN इंटरफेस सूचीबद्ध होईपर्यंत त्या पत्त्यावर उत्तर देत राहतो.

एक थेट युनिकास्ट विनंती करून पहा, नंतर एक जाहीर केलेली विनंती. पहिली काम करत असेल आणि दुसरी नाही, तर बोगदा निरोगी आहे आणि शोध हीच संपूर्ण समस्या आहे.