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'പിന്നീട് മൂന്ന് ഘട്ടങ്ങളും വെവ്വേറെ പരിശോധിക്കുക, കാരണം ഒന്നിലെ വിജയം മറ്റുള്ളവയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. തുടർന്ന് ബന്ധമില്ലാത്ത ഫോൺ ആപ്പുകൾ ഇപ്പോഴും ഉദ്ദേശിച്ച പാത പിന്തുടരുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക, കാരണം ശബ്ദമില്ലാതെ പൂർണ്ണ ഒഴിവാക്കലായി മാറിയ പ്രാദേശിക ഒഴിവാക്കൽ ഒരു അധിക സ്പർശനം ആവശ്യമുള്ള കാസ്റ്റിനെക്കാൾ മോശം ഫലമാണ്.