VPN पर कास्टिंग रुकती है: डिस्कवरी, नियंत्रण या स्ट्रीम?
गायब रिसीवर, अस्वीकृत सत्र और अटकती स्ट्रीम अलग-अलग जगहों पर विफल होते हैं। फ़ोन की VPN नीति या नेटवर्क बदलने से पहले चरण को नाम दें।
कास्टिंग तीन जगहों पर टूटती है जो सोफ़े से एक जैसी दिखती हैं। हो सकता है फ़ोन रिसीवर को कभी न देखे, रिसीवर दिखे और फिर सत्र अस्वीकार कर दे, या सत्र शुरू हो और एक मिनट बाद अटक जाए। फ़ोन पर टनल इनमें से हर रास्ते को अलग तरह से बदलता है, और एक के लिए वह कुछ भी नहीं बदलता। पहले विफल चरण को नाम दें, फिर तय करें कि नीति बदलना ही सही उपाय है या नहीं।
नीति बदलने से पहले विफल चरण को नाम दें
कास्ट आइकन दबाने के तुरंत बाद फ़ोन क्या करता है, यह देखें। खाली सूची डिस्कवरी का नतीजा है, विफलता बताने वाला टैप नियंत्रण का नतीजा है, और अटकने से पहले शुरू होने वाला सत्र प्लेबैक का नतीजा है। इन तीनों के मालिक अलग हैं, और आम तौर पर सिर्फ़ पहले दो ही फ़ोन की टनल सेटिंग से जुड़े होते हैं।
| Stage | What the phone shows | Evidence that separates it |
|---|---|---|
| Discovery | No receiver in the list | Another device on the same segment sees the receiver |
| Control | Receiver listed, session refused | Port answer versus permission prompt |
| Playback | Session starts, then stalls | The receiver's own link, not the phone's |
कुछ भी बदलने से पहले चरण लिख लें। गलत चरण पर लगाया गया सुधार अगली जाँच को अपठनीय बना देता है, और कास्टिंग के ज़्यादातर किस्से ठीक इसी उलझन से आते हैं।
डिस्कवरी स्थानीय ट्रैफ़िक है, और टनल उसे छिपा देती है
रिसीवर स्थानीय घोषणाओं से खुद को ज़ाहिर करते हैं और फ़ोन उन्हें उसी लिंक पर क्वेरी से ढूँढता है, इसलिए जो भी चीज़ फ़ोन को उस लिंक से हटाती है वह रिसीवर को भी सूची से हटा देती है। जो टनल सारा ट्रैफ़िक LAN से दूर भेजती है वह इन अदल-बदल को छिपा सकती है, और ऐप-स्तर की स्थानीय-नेटवर्क अनुमति रास्ता होने पर भी उन्हें रोक सकती है। क्लाइंट आइसोलेशन वाला गेस्ट Wi-Fi बिना किसी VPN के वही खाली सूची बनाता है। टनल को दोष देने से पहले साबित करें कि दोनों डिवाइस एक ही सेगमेंट साझा करते हैं।
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRपहला कमांड बताता है कि सहायक मशीन के सेगमेंट में कौन खुद को घोषित कर रहा है, और दूसरा मल्टीकास्ट DNS समूह से सीधे पूछता है। दोनों में मौजूद न रहने वाला रिसीवर फ़ोन के ऐप में भी नहीं दिखेगा, फ़ोन की टनल स्थिति जो भी हो। अगर रिसीवर ऐसे डिवाइस से दिखता है जिसकी टनल बंद है और ऐसे डिवाइस से नहीं दिखता जिसकी टनल चालू है, तो आपने चरण और कारण दोनों एक साथ ढूँढ लिए हैं।
LAN अपवाद टनल को चालू रखता है
कई क्लाइंट स्थानीय-नेटवर्क अपवाद देते हैं जो स्थानीय पते की अनुमति देते हुए टनल सक्रिय रखता है। किल स्विच या पूरा फ़ायरवॉल बंद करने के बजाय वही प्रलेखित सेटिंग इस्तेमाल करें, क्योंकि वे कास्टिंग की ज़रूरत से कहीं ज़्यादा बदल डालते हैं। अगर नेटवर्क जानबूझकर स्मार्ट डिवाइस अलग रखता है, तो सपाट पहुँच के बजाय मालिक से विशिष्ट डिस्कवरी, नियंत्रण और वापसी ट्रैफ़िक माँगें।
nc -vz 192.168.1.50 8009रिसीवर के खिलाफ़ नियंत्रण जाँच अनुमति को पहुँच से अलग करती है: जवाब देने वाला पोर्ट मतलब रास्ता मौजूद है, जबकि इनकार मतलब फ़ोन को डिवाइस खोजने की अनुमति थी और फिर भी वह उससे बात नहीं कर सकता। पोर्ट 8008 और 8009 सामान्य कास्ट पोर्ट हैं, और ऐप दूसरे इस्तेमाल कर सकता है, इसलिए एक इनकार किए गए पोर्ट को संकेत मानें, फ़ैसला नहीं। अपवाद और ऐप अनुमति स्वतंत्र रहते हैं, क्योंकि स्थानीय पहुँच रास्ता नहीं बनाती और रास्ता जोड़ने से अनुमति नहीं मिलती। किल स्विच फिर से कनेक्ट होने के बाद स्थानीय ट्रैफ़िक भी गिरा सकता है, इसलिए टनल लौटते ही डिस्कवरी फिर जाँचनी पड़ती है।
प्लेबैक फ़ोन के कनेक्शन का इस्तेमाल न भी करे
ऐप-निर्देशित सत्र में फ़ोन रिसीवर को मीडिया पता देता है और रिसीवर उसे अपने कनेक्शन से लाता है, इसलिए फ़ोन का सार्वजनिक पता बदलने से स्ट्रीम के लिए कुछ नहीं होता। खाते से सीमित शीर्षक अपने कारणों से फिर भी विफल हो सकता है, और Google की कास्टिंग आवश्यकताएँ ऐप और डिवाइस की संगतता बताती हैं, नेटवर्क रास्ता नहीं। टेलीविज़न को ही टनल से गुज़ारना अलग कॉन्फ़िगरेशन है, जिसके अपने नीति-प्रश्न हैं।
दो संकेत इन मोड को अलग करते हैं। फ़ोन की स्क्रीन लॉक करने पर भी टिकने वाली कास्ट ऐप-निर्देशित है, क्योंकि रिसीवर खुद ला रहा है; भेजने वाले की स्क्रीन लॉक होने पर रुकने वाला मिरर फ़ोन से आने वाली लगातार स्ट्रीम है। जब डिस्कवरी और नियंत्रण सफल हों पर प्लेबैक अटके, तो इसके बजाय रिसीवर की Wi-Fi लिंक और उसका इंटरनेट रास्ता देखें, क्योंकि फ़ोन पर किया स्पीड टेस्ट फ़ोन का वर्णन करता है, टेलीविज़न का नहीं।
अपवाद हटाएँ और फिर जाँचें
हर अस्थायी बदलाव के लिए वापसी का रास्ता चाहिए, और क्रम मायने रखता है। LAN अपवाद हटाएँ, टनल फिर से जोड़ें ताकि क्लाइंट अपनी नीति दोबारा लागू करे, फिर डिस्कवरी का चरण दोहराएँ और देखें कि रिसीवर फिर गायब होता है या नहीं। यही क्रम बताता है कि काम अपवाद कर रहा था या बीच में कुछ और बदला।
# after removing the LAN exception, reconnect and confirm the tunnel is up
resolvectl status | grep -E 'DNS Servers|Default Route|Protocols'
avahi-browse -at | grep -i -E 'chromecast|googlecast'बाद में तीनों चरण अलग-अलग जाँचें, क्योंकि एक में सफलता बाकी के बारे में कुछ नहीं बताती। फिर देखें कि फ़ोन के असंबंधित ऐप अब भी इच्छित रास्ते पर चलते हैं, क्योंकि चुपचाप पूरा बायपास बन गया स्थानीय अपवाद उस कास्ट से बुरा नतीजा है जिसे एक अतिरिक्त टैप चाहिए।