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'नंतर तीनही टप्पे स्वतंत्रपणे तपासा, कारण एकाचे यश इतरांबद्दल काहीही सांगत नाही. मग संबंध नसलेली फोन ॲप्स अजूनही इच्छित मार्गाने जातात का ते पहा, कारण गुपचूप पूर्ण बायपास बनलेला स्थानिक अपवाद एका अतिरिक्त टॅपची गरज असलेल्या कास्टपेक्षा वाईट परिणाम आहे.