राउटर का VPN चालू करने के बाद कास्टिंग क्यों बंद हो जाती है
खोज स्थानीय मल्टीकास्ट से होती है जबकि टीवी खुद मीडिया लाता है। डिफ़ॉल्ट नीति लैन अनुरोध पकड़कर उसे टनल में भेज सकती है।
राउटर का VPN चालू करने से पहले कास्टिंग काम करती थी और ठीक उसके बाद विफल हो जाती है, जबकि फ़ोन पर सामान्य ब्राउज़िंग अब भी चलती रहती है। दोनों तथ्य परस्पर संगत हैं, क्योंकि कास्टिंग एक ही कनेक्शन नहीं है। फ़ोन स्थानीय नेटवर्क पर रिसीवर को खोजता और नियंत्रित करता है, और फिर रिसीवर अपने ही कनेक्शन से मीडिया लाता है।
दो रास्ते जो अलग तरह से विफल होते हैं
नियंत्रण का रास्ता स्थानीय है। फ़ोन स्थानीय नेटवर्क से पूछकर रिसीवर ढूँढता है और फिर उस पते पर नियंत्रण कनेक्शन खोलता है जो उसने सीखा था। अगर रिसीवर कभी सूची में न दिखे, तो कोई भी मीडिया माँगे जाने से पहले खोज का चरण विफल हो गया।
मीडिया का रास्ता ज़रूरी नहीं कि स्थानीय हो। कई रिसीवर स्ट्रीम खुद लाते हैं, अपने कनेक्शन और अपने क्रेडेंशियल से, इसलिए फ़ोन का रास्ता रिसीवर का रास्ता नहीं बताता। एक ही एग्ज़िट इस्तेमाल करता दिखने वाला फ़ोन टीवी का ट्रैफ़िक कहाँ जाता है, इसके बारे में कुछ नहीं कहता।
यही बँटवारा विफलता को अजीब बनाता है। टनल ने फ़ोन की रूटिंग तालिका बदली और टीवी की नहीं, इसलिए जोड़ी के एक तरफ दिखने वाला लक्षण उसी तरफ जाँचा जाना चाहिए। ग़लत डिवाइस पर नज़र रखना आम वजह है कि कोई सुधार कुछ न करता दिखे।
खोज सबसे पहले क्यों टूटती है
खोज आम तौर पर लिंक-लोकल मल्टीकास्ट से होती है। mDNS 224.0.0.251 पर UDP पोर्ट 5353 पर भेजता है, और SSDP 239.255.255.250 पर UDP पोर्ट 1900 पर भेजता है। दोनों डिज़ाइन से एक ही लिंक तक सीमित हैं, इसलिए राउटर बिना रिपीटर या प्रॉक्सी की मदद के उन्हें सेगमेंट के बीच आगे नहीं भेजता। रूटेड VPN मल्टीकास्ट समूह का विस्तार नहीं करता, और नीति मार्ग ऐसा नहीं कर सकता कि जो समूह कभी लिंक नहीं छोड़ा वह दूसरे पर दिखे।
इसलिए पहली विफलता का एन्क्रिप्शन से कोई लेना-देना नहीं है। फ़ोन का मल्टीकास्ट उस इंटरफ़ेस को छोड़ देता है जिस पर भेजा गया था, रिसीवर ऐसे सेगमेंट में है जो उसे कभी नहीं देखता, और डिवाइस सूची खाली लौटती है। खाली सूची इस बात का सबूत नहीं है कि टीवी ने इंटरनेट पहुँच खो दी है।
अलगाव बिना किसी VPN के भी वही लक्षण पैदा करता है। गेस्ट नेटवर्क और एक्सेस पॉइंट पर क्लाइंट अलगाव जानबूझकर डिवाइसों को आपस में बात करने से रोकते हैं, और अलग किए गए सेगमेंट पर राउटर VPN चालू करने से इसमें कुछ नहीं बदलता। टनल जाँचने से पहले अलगाव की सेटिंग जाँचें। यह सस्ता जवाब है और ज़्यादा आम भी।
सेगमेंट का फैलाव दूसरा आधा हिस्सा है। दूसरा राउटर, किसी और मोड में मेश नोड, या किसी दूसरे NAT के पीछे का वायर्ड सेगमेंट — ये सब रिसीवर को ऐसी जगह रखते हैं जहाँ फ़ोन का खोज ट्रैफ़िक नहीं पहुँचता।
डिफ़ॉल्ट नीति स्थानीय अनुरोध कैसे निगल सकती है
जो राउटर सारा ट्रैफ़िक टनल में भेजता है वह टनल इंटरफ़ेस पर डिफ़ॉल्ट रूट लगाता है। अगर लैन प्रीफ़िक्स उस नीति से बाहर नहीं रखा गया, तो दो मीटर दूर के डिवाइस को भेजा गया पैकेट अब डिफ़ॉल्ट से मेल खाता है, और राउटर नियंत्रण अनुरोध स्विच के बजाय टनल में भेज देता है।
| 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 |
नियमों का क्रम नतीजा तय करता है। नीति रूटिंग नियमों को प्राथमिकता क्रम में जाँचती है, इसलिए स्थानीय प्रीफ़िक्स के लिए अपवाद उस नियम से पहले आना चाहिए जो टनल तालिका चुनता है। टनल नियम के बाद अपवाद जोड़ने का कोई असर नहीं होता, इसलिए सही दिखने वाला कॉन्फ़िगरेशन फिर भी लैन ट्रैफ़िक दूर के एग्ज़िट पर भेज सकता है।
सुधार सीमित है: कास्टिंग प्रवाह को जिन ठोस स्थानीय गंतव्यों की ज़रूरत है उन्हें अनुमति दें, और बाकी अलगाव को वैसे ही रहने दें। पहले कदम के तौर पर क्लाइंट अलगाव हटाना लक्षण ठीक कर देता है पर उस नियंत्रण को फेंक देता है जो नेटवर्क में होने के लिए ही बनाया गया था।
फ़ोन पर एक तेज़ जाँच तय कर देती है कि आपके पास दोनों में से कौन-सी विफलता है। अगर रिसीवर तक का रास्ता टनल की ओर इशारा करता है, तो समस्या नीति में है। अगर वह लैन की ओर इशारा करता है और खोज फिर भी विफल होती है, तो समस्या मल्टीकास्ट या अलगाव में है, और कोई भी मार्ग बदलाव मदद नहीं करेगा।
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpउस चरण को जाँचें जो बदला, देश को नहीं
दर्ज किए गए अवलोकन दोहराए गए प्रयोगों से बेहतर हैं। लिखें कि रिसीवर डिवाइस सूची में दिखता है या नहीं, उस तक नियंत्रण अनुरोध पहुँचता है या नहीं, और स्ट्रीम चुनने पर प्लेबैक शुरू होता है या नहीं। हर जवाब एक चरण को संदेह से हटा देता है।
फिर एग्ज़िट की जगहें बदलने के बजाय हर चरण को सीधे जाँचें। VPN देश बदलना मीडिया के रास्ते को जाँचता है और खोज तथा नियंत्रण के चरणों को अछूता छोड़ देता है, इसलिए यह संयोग से मदद करता दिख सकता है बिना आपको कुछ सिखाए।
रिसीवर की तरफ़ उसका अपना मार्ग और उसके खाते की स्थिति जाँचें। जो टीवी फ़ोन से अलग एग्ज़िट से मीडिया लाता है वह सामान्य डिज़ाइन है, और वहाँ की विफलता रिसीवर की नेटवर्क नीति का सवाल है, फ़ोन की टनल का नहीं।
नतीजे को एक वाक्य में लिखें: कौन-सा चरण टूटा और उसे किसने बदला। वह वाक्य देश बदलने के एक हफ़्ते से ज़्यादा कीमती है, और अगले फ़र्मवेयर अपडेट तक टिकता है।
कास्टिंग टनल के बारे में एक सामान्य नियम के लिए अच्छा परीक्षण मामला है। जब नेटवर्क में एक टनल जोड़ा जाता है, तो पहला सवाल यह है कि कौन-से गंतव्य उसमें कभी नहीं जाने चाहिए थे. दूसरा सवाल यह है कि नीति ने उनमें से किन्हें फिर भी चुपचाप स्वीकार कर लिया।