राउटर VPN सक्षम गरेपछि कास्टिङ किन रोकिन्छ
खोज लिङ्क-लोकल मल्टिकास्टमा चल्छ, तर टिभीले मिडिया आफैं झिक्छ। नीतिको पूर्वनिर्धारित नियमले LAN अनुरोध समातेर सुरुङमा पठाउन सक्छ।
राउटर VPN सक्षम गर्नुअघि कास्टिङ चल्थ्यो र सक्षम गरेपछि तुरुन्तै असफल हुन्छ, तर फोनमा सामान्य ब्राउजिङ अझै चल्छ। यी दुई तथ्य विरोधाभासी छैनन्, किनकि कास्टिङ एउटै जडान होइन। फोनले स्थानीय सञ्जालमा रिसिभर पत्ता लगाई नियन्त्रण गर्छ, अनि रिसिभरले आफ्नै जडानबाट मिडिया झिक्छ।
फरक फरक तरिकाले असफल हुने दुई मार्ग
नियन्त्रण मार्ग स्थानीय हुन्छ। फोनले स्थानीय सञ्जाललाई सोधेर रिसिभर भेट्टाउँछ, त्यसपछि थाहा पाएको ठेगानामा नियन्त्रण जडान खोल्छ। रिसिभर सूचीमा कहिल्यै नदेखिएमा कुनै पनि मिडिया माग्नुअघि नै खोज चरण असफल भएको हो।
मिडिया मार्ग अनिवार्य स्थानीय हुँदैन। धेरै रिसिभरले स्ट्रिम आफैं, आफ्नै जडान र आफ्नै प्रमाणहरूबाट झिक्छन्, त्यसैले फोनको मार्गले रिसिभरको मार्ग वर्णन गर्दैन। एउटै निकास प्रयोग गरेझैं देखिने फोनले टिभीको ट्राफिक कहाँ जान्छ भन्नेबारे केही भन्दैन।
यही विभाजनका कारण खराबी अनौठो देखिन्छ। सुरुङले फोनको राउटिङ तालिका बदल्यो र टिभीको बदलेन, त्यसैले जोडीको एक छेउमा देखिने लक्षण त्यही छेउमा खोज्नुपर्छ। गलत यन्त्र जाँच्नु नै समाधानले केही नगरेझैं देखिने सामान्य कारण हो।
खोज किन पहिले बिग्रन्छ
खोज सामान्यतया लिङ्क-लोकल मल्टिकास्टमा चल्छ। mDNS ले 224.0.0.251 मा UDP पोर्ट 5353 मा पठाउँछ, र SSDP ले 239.255.255.250 मा UDP पोर्ट 1900 मा पठाउँछ। दुवै रचनाअनुसार एउटै लिङ्कमा सीमित छन्, त्यसैले रिपिटर वा प्रोक्सीको सहयोगबिना राउटरले तिनलाई खण्डहरूबीच अगाडि पठाउँदैन। राउट गरिएको VPN ले मल्टिकास्ट समूह विस्तार गर्दैन, र नीति मार्गले लिङ्क कहिल्यै नछोडेको समूहलाई अर्को लिङ्कमा देखाउन सक्दैन।
त्यसैले पहिलो खराबीको इन्क्रिप्शनसँग कुनै सम्बन्ध छैन। फोनको मल्टिकास्ट जुन इन्टरफेसमा पठाइयो त्यसैलाई छोड्छ, रिसिभर त्यसलाई कहिल्यै नदेख्ने खण्डमा हुन्छ, र यन्त्र सूची खाली फर्किन्छ। खाली सूची टिभीले इन्टरनेट पहुँच गुमाएको प्रमाण होइन।
VPN बिना पनि अलगावले उही लक्षण बनाउँछ। अतिथि सञ्जाल र पहुँच बिन्दुको क्लाइन्ट अलगावले यन्त्रहरूलाई एकआपसमा बोल्नबाट जानाजान रोक्छ, र अलग गरिएको खण्डमाथि राउटर VPN सक्षम गर्दा त्यसमा केही बदलिँदैन। सुरुङ जाँच्नुअघि अलगावको सेटिङ जाँच्नुहोस्। त्यो सस्तो उत्तर र बढी सामान्य हो।
खण्डको मिलाइ अर्को आधा हो। दोस्रो राउटर, फरक मोडको मेस नोड, वा अर्को NAT पछिको तार भएको खण्डले रिसिभरलाई फोनको खोज ट्राफिक नपुग्ने ठाउँमा राख्छ।
नीतिको पूर्वनिर्धारितले स्थानीय अनुरोध किन निल्न सक्छ
सबै ट्राफिक सुरुङमा पठाउने राउटरले सुरुङ इन्टरफेसमा पूर्वनिर्धारित मार्ग राख्छ। LAN प्रिफिक्स त्यो नीतिबाट बाहिर नराखिएमा दुई मिटर परको यन्त्रतर्फ पठाइएको प्याकेट अब पूर्वनिर्धारितसँग मिल्छ, र राउटरले नियन्त्रण अनुरोध स्विचतर्फ नभई सुरुङभित्र पठाउँछ।
| Stage | What carries it | How a router VPN interferes |
|---|---|---|
| Discovery | Link-local multicast on a single segment | Not extended across segments, and not repaired by a route |
| Control connection | Unicast to the receiver address on the LAN | A policy default can capture the LAN destination and tunnel it |
| Media fetch | The receiver's own connection | Unaffected by the phone's route, but affected by the TV's own policy |
| Account authorization | Tokens held by the application | Can fail for reasons unrelated to any route |
नियमको क्रमले नतिजा तय गर्छ। नीति राउटिङले नियमहरू प्राथमिकताक्रममा मूल्याङ्कन गर्छ, त्यसैले स्थानीय प्रिफिक्सको अपवाद सुरुङ तालिका छान्ने नियमभन्दा अघि हुनुपर्छ। सुरुङ नियमपछि अपवाद थप्दा कुनै प्रभाव पर्दैन, त्यसैले सही देखिने कन्फिगरेसनले पनि LAN ट्राफिक टाढाको निकासमा पठाउन सक्छ।
समाधान साँघुरो छ: कास्टिङ प्रवाहलाई चाहिने विशेष स्थानीय गन्तव्यहरूलाई अनुमति दिनुहोस्, र बाँकी अलगाव जस्ताको तस्तै राख्नुहोस्। पहिलो कदमका रूपमा क्लाइन्ट अलगाव हटाउँदा लक्षण निको हुन्छ, तर सञ्जालको रचनामा भएको नियन्त्रण फालिन्छ।
फोनमा एक छिटो जाँचले तपाईंसँग कुन खराबी छ भनी टुंगो लगाउँछ। रिसिभरतर्फको मार्गले सुरुङ देखाउँछ भने समस्या नीतिमा छ। LAN देखाउँछ र खोज अझै असफल हुन्छ भने समस्या मल्टिकास्ट वा अलगावमा छ, र मार्ग बदल्दा सहयोग हुँदैन।
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpदेश होइन, बदलिएको चरण परीक्षण गर्नुहोस्
अभिलेख गरिएका अवलोकन दोहोरिएका प्रयोगभन्दा राम्रा हुन्छन्। रिसिभर यन्त्र सूचीमा देखिन्छ कि, नियन्त्रण अनुरोध त्यहाँ पुग्छ कि, र स्ट्रिम छानेपछि प्लेब्याक सुरु हुन्छ कि लेख्नुहोस्। हरेक उत्तरले एउटा चरणलाई शंकाबाट हटाउँछ।
त्यसपछि निकास स्थान बदल्नुको सट्टा हरेक चरण सिधै परीक्षण गर्नुहोस्। VPN देश बदल्दा मिडिया मार्ग परीक्षण हुन्छ र खोज तथा नियन्त्रण चरण अछुत रहन्छ, त्यसैले संयोगले सहयोग गरेझैं देखिन सक्छ, केही सिकाउँदैन।
रिसिभरको छेउमा त्यसको आफ्नै मार्ग र आफ्नै खाताको अवस्था जाँच्नुहोस्। टिभीले फोनभन्दा फरक निकासबाट मिडिया झिक्छ भने त्यो सामान्य रचना हो, र त्यहाँको खराबी फोनको सुरुङबारे होइन, रिसिभरको सञ्जाल नीतिबारे प्रश्न हो।
कुन चरण बिग्रियो र केले त्यसलाई बदल्यो भन्ने एउटा वाक्यमा नतिजा लेख्नुहोस्। त्यो वाक्य एक हप्ताको देश बदल्नेभन्दा बढी मूल्यवान छ, र अर्को फर्मवेयर अद्यावधिक पनि पार गर्छ।
सुरुङबारे सामान्य नियमका लागि कास्टिङ राम्रो परीक्षण केस हो। सञ्जालमा सुरुङ थप्दा पहिलो प्रश्न कुन गन्तव्यहरू कहिल्यै त्यसमा पस्नु हुँदैन थियो हो, र दोस्रो प्रश्न तीमध्ये कुनलाई नीतिले चुपचाप स्वीकार्यो भन्ने हो।