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 इन्टरफेस सूचीबद्ध नगरेसम्म त्यही ठेगानामा जवाफ दिइरहन्छ।

एउटा सिधा युनिकास्ट अनुरोध, त्यसपछि एउटा घोषित अनुरोध परीक्षण गर्नुहोस्। पहिलोले काम गरे र दोस्रोले नगरे, सुरुङ स्वस्थ छ र पत्ता लगाउनु नै सम्पूर्ण समस्या हो।