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'తర్వాత మూడు దశలను విడివిడిగా ధృవీకరించండి, ఎందుకంటే ఒకదాని విజయం మిగతావాటి గురించి ఏమీ చెప్పదు. ఆపై సంబంధం లేని ఫోన్ యాప్‌లు ఇప్పటికీ ఉద్దేశించిన మార్గాన్ని అనుసరిస్తున్నాయా చూడండి, ఎందుకంటే నిశ్శబ్దంగా పూర్తి బైపాస్ అయిన స్థానిక మినహాయింపు, ఒక అదనపు తట్టడం అవసరమయ్యే కాస్ట్ కంటే అధ్వాన్నమైన ఫలితం.