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'पछि तीनै चरण अलग-अलग जाँच्नुहोस्, किनकि एउटाको सफलताले अरूबारे केही भन्दैन। त्यसपछि सम्बन्ध नभएका फोन एपहरू अझै इच्छित बाटोमा छन् कि जाँच्नुहोस्, किनकि चुपचाप पूर्ण बाइपास बनेको स्थानीय अपवाद एउटा थप ट्याप चाहिने कास्टभन्दा नराम्रो परिणाम हो।