റൗട്ടർ VPN പ്രവർത്തനക്ഷമമാക്കിയതിന് ശേഷം കാസ്റ്റിംഗ് നിലയ്ക്കുന്നത് എന്തുകൊണ്ട്
കണ്ടെത്തൽ link-local multicast വഴി നടക്കുന്നു, എന്നാൽ ടിവി മീഡിയ സ്വയം ഡൗൺലോഡ് ചെയ്യുന്നു. പോളിസിയുടെ ഡിഫോൾട്ട് LAN അഭ്യർത്ഥന പിടിച്ചെടുത്ത് ടണലിലേക്ക് അയച്ചേക്കാം.
റൗട്ടർ VPN സജീവമാക്കുന്നതിന് മുമ്പ് കാസ്റ്റിംഗ് പ്രവർത്തിച്ചു, സജീവമാക്കിയ ഉടൻ പരാജയപ്പെടുന്നു, എന്നാൽ ഫോണിൽ സാധാരണ ബ്രൗസിംഗ് ഇപ്പോഴും പ്രവർത്തിക്കുന്നു. ഈ രണ്ട് വസ്തുതകളും പരസ്പരവിരുദ്ധമല്ല, കാരണം കാസ്റ്റിംഗ് ഒരു ബന്ധമല്ല. ഫോൺ പ്രാദേശിക നെറ്റ്വർക്കിലൂടെ റിസീവർ കണ്ടെത്തി നിയന്ത്രിക്കുന്നു, തുടർന്ന് റിസീവർ സ്വന്തം ബന്ധത്തിലൂടെ മീഡിയ ഡൗൺലോഡ് ചെയ്യുന്നു.
വ്യത്യസ്തമായി പരാജയപ്പെടുന്ന രണ്ട് പാതകൾ
നിയന്ത്രണ പാത പ്രാദേശികമാണ്. ഫോൺ പ്രാദേശിക നെറ്റ്വർക്കിനോട് ചോദിച്ച് റിസീവർ കണ്ടെത്തി, പിന്നീട് അറിഞ്ഞ വിലാസത്തിലേക്ക് നിയന്ത്രണ ബന്ധം തുറക്കുന്നു. റിസീവർ പട്ടികയിൽ ഒരിക്കലും പ്രത്യക്ഷപ്പെടുന്നില്ലെങ്കിൽ, മീഡിയ ആവശ്യപ്പെടുന്നതിന് മുമ്പുതന്നെ കണ്ടെത്തൽ ഘട്ടം പരാജയപ്പെട്ടു.
മീഡിയ പാത നിർബന്ധമായും പ്രാദേശികമല്ല. പല റിസീവറുകളും സ്ട്രീം സ്വയം, സ്വന്തം ബന്ധത്തിലും സ്വന്തം ക്രെഡൻഷ്യലുകളിലും ഡൗൺലോഡ് ചെയ്യുന്നു, അതിനാൽ ഫോണിന്റെ റൂട്ട് റിസീവറിന്റെ റൂട്ട് വിവരിക്കുന്നില്ല. ഒരു എക്സിറ്റ് ഉപയോഗിക്കുന്നതായി തോന്നുന്ന ഫോൺ, ടിവിയുടെ ട്രാഫിക് എവിടേക്ക് പോകുന്നു എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.
ഈ വിഭജനം കൊണ്ടാണ് പരാജയം വിചിത്രമായി തോന്നുന്നത്. ടണൽ ഫോണിന്റെ റൂട്ടിംഗ് പട്ടിക മാറ്റി, ടിവിയുടേത് മാറ്റിയില്ല, അതിനാൽ ജോടിയുടെ ഒരു വശത്ത് കാണുന്ന ലക്ഷണം ആ വശത്തുതന്നെ കണ്ടെത്തണം. തെറ്റായ ഉപകരണം പരിശോധിക്കുന്നതാണ് പരിഹാരം ഒന്നും ചെയ്യുന്നില്ല എന്ന് തോന്നാനുള്ള സാധാരണ കാരണം.
കണ്ടെത്തൽ ആദ്യം തകരുന്നത് എന്തുകൊണ്ട്
കണ്ടെത്തൽ സാധാരണയായി link-local multicast വഴി നടക്കുന്നു. mDNS 224.0.0.251 ലേക്ക് UDP പോർട്ട് 5353 ൽ അയക്കുന്നു, SSDP 239.255.255.250 ലേക്ക് UDP പോർട്ട് 1900 ൽ അയക്കുന്നു. രണ്ടും രൂപകൽപ്പനപ്രകാരം ഒരു ലിങ്കിൽ പരിമിതമാണ്, അതിനാൽ റിപ്പീറ്റർ അല്ലെങ്കിൽ പ്രോക്സിയുടെ സഹായമില്ലാതെ റൗട്ടർ അവ സെഗ്മെന്റുകൾക്കിടയിൽ കൈമാറുന്നില്ല. റൂട്ട് ചെയ്ത VPN multicast ഗ്രൂപ്പ് വിപുലീകരിക്കുന്നില്ല, ലിങ്ക് വിട്ടിട്ടില്ലാത്ത ഗ്രൂപ്പിനെ മറ്റൊരു ലിങ്കിൽ കാണിക്കാൻ പോളിസി റൂട്ടിന് കഴിയില്ല.
അതിനാൽ ആദ്യ പരാജയത്തിന് എൻക്രിപ്ഷനുമായി ബന്ധമില്ല. ഫോണിന്റെ multicast അയച്ച ഇന്റർഫേസ് വിടുന്നു, റിസീവർ അത് ഒരിക്കലും കാണാത്ത സെഗ്മെന്റിലാണ്, ഉപകരണ പട്ടിക ശൂന്യമായി മടങ്ങുന്നു. ശൂന്യമായ പട്ടിക ടിവിക്ക് ഇന്റർനെറ്റ് ആക്സസ് നഷ്ടപ്പെട്ടു എന്നതിന്റെ തെളിവല്ല.
VPN ഇല്ലാതെയും ഐസൊലേഷൻ അതേ ലക്ഷണം ഉണ്ടാക്കുന്നു. ഗസ്റ്റ് നെറ്റ്വർക്കുകളും ആക്സസ് പോയിന്റിലെ ക്ലയന്റ് ഐസൊലേഷനും ഉപകരണങ്ങൾ പരസ്പരം സംസാരിക്കാതിരിക്കാൻ ബോധപൂർവം തടയുന്നു, ഒറ്റപ്പെട്ട സെഗ്മെന്റിന് മുകളിൽ റൗട്ടർ VPN സജീവമാക്കിയാലും അതിൽ ഒന്നും മാറുന്നില്ല. ടണൽ പരിശോധിക്കുന്നതിന് മുമ്പ് ഐസൊലേഷൻ ക്രമീകരണം പരിശോധിക്കുക. അതാണ് വിലകുറഞ്ഞ ഉത്തരവും കൂടുതൽ സാധാരണമായതും.
സെഗ്മെന്റ് ക്രമീകരണമാണ് മറ്റേ പകുതി. രണ്ടാമത്തെ റൗട്ടർ, മറ്റൊരു മോഡിലുള്ള മെഷ് നോഡ്, അല്ലെങ്കിൽ മറ്റൊരു NAT ന് പിന്നിലെ വയർ സെഗ്മെന്റ് — എല്ലാം റിസീവറെ ഫോണിന്റെ കണ്ടെത്തൽ ട്രാഫിക് എത്താത്ത സ്ഥലത്ത് നിർത്തുന്നു.
പോളിസിയുടെ ഡിഫോൾട്ടിന് പ്രാദേശിക അഭ്യർത്ഥന വിഴുങ്ങാൻ കഴിയുന്നത് എന്തുകൊണ്ട്
എല്ലാ ട്രാഫിക്കും ടണലിലേക്ക് അയക്കുന്ന റൗട്ടർ ടണൽ ഇന്റർഫേസിൽ ഡിഫോൾട്ട് റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്യുന്നു. LAN പ്രിഫിക്സ് ആ പോളിസിയിൽ നിന്ന് ഒഴിവാക്കിയിട്ടില്ലെങ്കിൽ, രണ്ട് മീറ്റർ അകലെയുള്ള ഉപകരണത്തിലേക്കുള്ള പാക്കറ്റ് ഇപ്പോൾ ഡിഫോൾട്ടുമായി പൊരുത്തപ്പെടുന്നു, റൗട്ടർ നിയന്ത്രണ അഭ്യർത്ഥന സ്വിച്ചിലേക്കല്ല, ടണലിലേക്ക് അയക്കുന്നു.
| Stage | What carries it | How a router VPN interferes |
|---|---|---|
| Discovery | Link-local multicast on a single segment | Not extended across segments, and not repaired by a route |
| Control connection | Unicast to the receiver address on the LAN | A policy default can capture the LAN destination and tunnel it |
| Media fetch | The receiver's own connection | Unaffected by the phone's route, but affected by the TV's own policy |
| Account authorization | Tokens held by the application | Can fail for reasons unrelated to any route |
നിയമങ്ങളുടെ ക്രമമാണ് ഫലം തീരുമാനിക്കുന്നത്. പോളിസി റൂട്ടിംഗ് നിയമങ്ങൾ മുൻഗണനാ ക്രമത്തിൽ വിലയിരുത്തുന്നു, അതിനാൽ പ്രാദേശിക പ്രിഫിക്സിന്റെ ഒഴിവാക്കൽ ടണൽ പട്ടിക തിരഞ്ഞെടുക്കുന്ന നിയമത്തിന് മുമ്പ് വേണം. ടണൽ നിയമത്തിന് ശേഷം ഒഴിവാക്കൽ ചേർത്താൽ ഫലമില്ല, അതിനാൽ ശരിയായി തോന്നുന്ന കോൺഫിഗറേഷനും LAN ട്രാഫിക് വിദൂര എക്സിറ്റിലേക്ക് അയച്ചേക്കാം.
പരിഹാരം ഇടുങ്ങിയതാണ്: കാസ്റ്റിംഗ് ഫ്ലോയ്ക്ക് ആവശ്യമായ നിർദ്ദിഷ്ട പ്രാദേശിക ലക്ഷ്യസ്ഥാനങ്ങൾ അനുവദിക്കുക, ബാക്കി ഐസൊലേഷൻ അതേപടി വിടുക. ആദ്യ ഘട്ടമായി ക്ലയന്റ് ഐസൊലേഷൻ നീക്കുന്നത് ലക്ഷണം ശമിപ്പിക്കും, പക്ഷേ നെറ്റ്വർക്കിന് രൂപകൽപ്പനയിൽ ഉണ്ടായിരുന്ന നിയന്ത്രണം വലിച്ചെറിയുന്നു.
ഫോണിൽ ഒരു പെട്ടെന്നുള്ള പരിശോധന ഏത് പരാജയമാണെന്ന് തീരുമാനിക്കും. റിസീവറിലേക്കുള്ള റൂട്ട് ടണലിലേക്ക് കാണിക്കുന്നുവെങ്കിൽ പ്രശ്നം പോളിസിയിലാണ്. LAN ലേക്ക് കാണിക്കുകയും കണ്ടെത്തൽ പരാജയപ്പെടുകയും ചെയ്താൽ പ്രശ്നം multicast അല്ലെങ്കിൽ ഐസൊലേഷനാണ്, റൂട്ട് മാറ്റം സഹായിക്കില്ല.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpരാജ്യമല്ല, മാറിയ ഘട്ടം പരിശോധിക്കുക
രേഖപ്പെടുത്തിയ നിരീക്ഷണങ്ങൾ ആവർത്തിച്ച പരീക്ഷണങ്ങളെക്കാൾ മികച്ചതാണ്. റിസീവർ ഉപകരണ പട്ടികയിൽ പ്രത്യക്ഷപ്പെടുന്നുണ്ടോ, നിയന്ത്രണ അഭ്യർത്ഥന അതിലെത്തുന്നുണ്ടോ, സ്ട്രീം തിരഞ്ഞെടുത്താൽ പ്ലേബാക്ക് തുടങ്ങുന്നുണ്ടോ എന്ന് എഴുതുക. ഓരോ ഉത്തരവും ഒരു ഘട്ടത്തെ സംശയത്തിൽ നിന്ന് ഒഴിവാക്കുന്നു.
തുടർന്ന് എക്സിറ്റ് സ്ഥലങ്ങൾ മാറ്റുന്നതിന് പകരം ഓരോ ഘട്ടവും നേരിട്ട് പരിശോധിക്കുക. VPN രാജ്യം മാറ്റുന്നത് മീഡിയ പാത പരിശോധിക്കുകയും കണ്ടെത്തൽ, നിയന്ത്രണ ഘട്ടങ്ങളെ തൊടാതിരിക്കുകയും ചെയ്യുന്നു, അതിനാൽ യാദൃച്ഛികമായി സഹായിച്ചതായി തോന്നാം, ഒന്നും പഠിപ്പിക്കാതെ.
റിസീവർ വശത്ത് അതിന്റെ സ്വന്തം റൂട്ടും സ്വന്തം അക്കൗണ്ട് അവസ്ഥയും പരിശോധിക്കുക. ടിവി ഫോണിൽ നിന്ന് വ്യത്യസ്ത എക്സിറ്റിലൂടെ മീഡിയ ഡൗൺലോഡ് ചെയ്യുന്നത് സാധാരണ രൂപകൽപ്പനയാണ്, അവിടത്തെ പരാജയം ഫോണിന്റെ ടണലിനെക്കുറിച്ചല്ല, റിസീവറിന്റെ നെറ്റ്വർക്ക് പോളിസിയെക്കുറിച്ചുള്ള ചോദ്യമാണ്.
ഏത് ഘട്ടം തകർന്നു, എന്താണ് അതിനെ മാറ്റിയത് എന്ന് ഒരു വാക്യത്തിൽ എഴുതുക. ആ വാക്യം ഒരാഴ്ച രാജ്യം മാറ്റുന്നതിനെക്കാൾ മൂല്യമുള്ളതാണ്, അടുത്ത ഫേംവെയർ അപ്ഡേറ്റിനെയും അതിജീവിക്കും.
ടണലുകളെക്കുറിച്ചുള്ള പൊതു നിയമത്തിന് കാസ്റ്റിംഗ് നല്ല പരീക്ഷണ കേസാണ്. നെറ്റ്വർക്കിലേക്ക് ടണൽ ചേർക്കുമ്പോൾ ആദ്യ ചോദ്യം ഏത് ലക്ഷ്യസ്ഥാനങ്ങൾ ഒരിക്കലും അതിലേക്ക് കടക്കരുതായിരുന്നു എന്നതാണ്, രണ്ടാമത്തേത് അവയിൽ ഏതൊക്കെ പോളിസി നിശ്ശബ്ദമായി സ്വീകരിച്ചു എന്നതുമാണ്.