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'பிறகு மூன்று நிலைகளையும் தனித்தனியாகச் சரிபார்க்கவும், ஏனெனில் ஒன்றின் வெற்றி மற்றவற்றைப் பற்றி எதுவும் சொல்லாது. பின்னர் தொடர்பில்லாத ஃபோன் பயன்பாடுகள் இன்னும் நோக்கமிட்ட பாதையைப் பின்பற்றுகின்றனவா எனப் பாருங்கள், ஏனெனில் அமைதியாக முழு பைபாஸாக மாறிய உள்ளூர் விலக்கு, ஒரு கூடுதல் தட்டல் தேவைப்படும் காஸ்ட்டை விட மோசமான முடிவு.