VPN വഴി Wake-on-LAN പ്രവർത്തിക്കുന്നില്ലേ? സംപ്രേഷണം ഒരിക്കലും കടക്കുന്നില്ല

ഓഫീസിലെ യന്ത്രത്തെ ഉറക്കത്തിലാക്കുന്നു, വീട്ടിൽ നിന്ന് VPN ബന്ധിപ്പിക്കുന്നു, അത് ഓഫായി തന്നെ ഇരിക്കുന്നു. ടണൽ പ്രവർത്തിക്കുന്നു, ഫയൽ ഷെയറുകൾ മറുപടി നൽകുന്നു, റൗട്ടറിന്റെ wake-on-LAN പേജ് അഭ്യർത്ഥന അയച്ചതായി അറിയിക്കുന്നു. കാണുന്ന ഓരോ സൂചനയും ശൃംഖല കുഴപ്പമില്ലെന്ന് പറയുന്നു, അതുകൊണ്ടാണ് ഈ കേസ് ആശയക്കുഴപ്പമാകുന്നത്: യന്ത്രത്തെ ഉണർത്തുന്ന ഫ്രെയിം അത് നിൽക്കുന്ന സെഗ്മെന്റിൽ ഒരിക്കലും എത്തുന്നില്ല.

ലക്ഷണങ്ങൾ സബ്നെറ്റിലേക്കാണ് ചൂണ്ടുന്നത്, ടണലിലേക്കല്ല

ഉറങ്ങുന്ന ഹോസ്റ്റിലേക്കുള്ള പിംഗ് പരാജയപ്പെടുന്നു, ആ ഭാഗം സാധാരണമാണ്. സ്റ്റാൻഡ്ബൈയിലുള്ള യന്ത്രത്തിന് പ്രവർത്തിക്കുന്ന IP സ്റ്റാക്ക് ഇല്ല, അതിനാൽ ARP അല്ലെങ്കിൽ ICMP യ്ക്ക് മറുപടി നൽകാനാകില്ല, ഒരു ടണൽ സംരചനയും അത് മാറ്റുന്നില്ല. ഉപയോഗപ്രദമായ പരിശോധന അതേ LAN ലെ രണ്ടാമത്തെ യന്ത്രം ഉണരുന്നുണ്ടോ, റൗട്ടറിന്റെ സ്വന്തം ഉണർത്തൽ പേജ് അതിൽ ബന്ധിപ്പിച്ച ഹോസ്റ്റിന് പ്രവർത്തിക്കുന്നുണ്ടോ എന്നതാണ്.

അതേ സെഗ്മെന്റിലെ പരിശോധന വിജയിച്ചാൽ, തകരാർ പരിധിയിലാണ്. നിങ്ങൾ ഉപയോഗിക്കുന്ന അയക്കുന്നയാൾ VPN ഇന്റർഫേസിൽ ജീവിക്കുന്നു, അത് നിർമ്മിക്കുന്ന പാക്കറ്റ് പ്രാദേശിക ലിങ്കിലേക്കുള്ള സംപ്രേഷണമാണ്, അതിനാൽ അത് തെറ്റായ ഇന്റർഫേസിലൂടെ പുറത്തുപോകുന്നു അല്ലെങ്കിൽ പുറത്തുപോകുന്നേയില്ല. ടണൽ കേടല്ല; അത് തെറ്റായ തരം ട്രാഫിക് വഹിക്കുന്നു. റൗട്ടറിന്റെ ഒരു ക്രമീകരണവും മാറ്റുന്നതിന് മുൻപ് അയക്കുന്നയാൾ ഏത് ഇന്റർഫേസ് തിരഞ്ഞെടുക്കുന്നു എന്ന് കണ്ടെത്തുക.

magic packet ഒരു ഫ്രെയിം ആണ്, സേവനമല്ല

പേലോഡ് ആറ് ബൈറ്റിന്റെ സ്ഥിരമായ ഹെഡർ 0xFF ൽ തുടങ്ങുന്നു, പിന്നെ ലക്ഷ്യ കാർഡിന്റെ ഹാർഡ്‌വെയർ വിലാസം പതിനാറ് തവണ ആവർത്തിക്കുന്നു, പിന്നെ നാല് ബൈറ്റിന്റെ ഓപ്ഷണൽ SecureOn പാസ്‌വേഡ് വരുന്നു. അയക്കുന്നവർ ഇത് സാധാരണയായി UDP യിൽ പൊതിഞ്ഞ് പോർട്ട് 7 അല്ലെങ്കിൽ പോർട്ട് 9 ലേക്ക് അയക്കുന്നു, പക്ഷേ പോർട്ട് നമ്പർ അയക്കുന്നയാളും കാർഡും തമ്മിലുള്ള ഒരു പതിവാണ്, ബന്ധിപ്പിക്കാവുന്ന ശ്രോതാവല്ല. ഒന്നും കേൾക്കുന്നില്ല, ഒന്നും മറുപടി നൽകുന്നില്ല.

യന്ത്രത്തെ ഉണർത്തുന്നത് നെറ്റ്‌വർക്ക് ഇന്റർഫേസാണ്, അത് ബാക്കി സിസ്റ്റം ഓഫായിരിക്കുമ്പോൾ സ്റ്റാൻഡ്ബൈ റെയിലിൽ നിന്ന് അൽപ്പം സർക്യൂട്ടറിക്ക് വൈദ്യുതി നൽകി നിർത്തുന്നു. അതിനാൽ ആ ക്രമീകരണം പൂർണ വൈദ്യുതി നഷ്ടവും ഉറക്കവും രണ്ടും താങ്ങണം: ഓഫ് ചെയ്യുമ്പോൾ സ്റ്റാൻഡ്ബൈ വൈദ്യുതി വിച്ഛേദിക്കുന്ന ബോർഡിന് ഇനി എന്തെങ്കിലും സ്വീകരിക്കാനുള്ള കാർഡില്ല.

റൗട്ട് ചെയ്ത ടണലിന് അത് എത്തിക്കാനാകാത്തത് എന്തുകൊണ്ട്

റൗട്ട് ചെയ്ത VPN ഇന്റർഫേസ് രണ്ട് ടണൽ വിലാസങ്ങൾക്കിടയിലുള്ള പോയിന്റ്-ടു-പോയിന്റ് IP ലിങ്കാണ്. അത് സമപ്രായക്കാർക്ക് വിലാസം നൽകിയ പാക്കറ്റുകൾ വഹിക്കാൻ ഉള്ളതാണ്, അതുകൊണ്ടാണ് പിംഗ്, SSH, ഫയൽ ഷെയറുകൾ അതിലൂടെ സാധാരണ പ്രവർത്തിക്കുന്നത്. സംപ്രേഷണ ഫ്രെയിം ആ സമപ്രായക്കാർക്ക് വിലാസം നൽകിയതല്ല, പരിമിത സംപ്രേഷണ വിലാസം ഒരു റൗട്ടറും തനിയെ കൈമാറുന്നില്ല.

സബ്നെറ്റിലേക്ക് നിർദ്ദേശിച്ച സംപ്രേഷണം കൈമാറ്റം ചെയ്യുന്നത് റൗട്ടറിന്റെ ബോധപൂർവമായ സാധ്യതയാണ്, മിക്ക സ്ഥിര ക്രമീകരണങ്ങളും അത് ഓഫ് ചെയ്യുന്നു, അപ്പോഴും അത് ആ സബ്നെറ്റിന് തന്നെ എത്തിക്കുന്നു, ഒരു പ്രത്യേക ഉറങ്ങുന്ന കാർഡിനല്ല. ഉറങ്ങുന്ന ഹോസ്റ്റിന് ARP യ്ക്കും മറുപടി നൽകാനാകില്ല, അതിനാൽ കൈമാറ്റത്തിന് മുൻപ് ലക്ഷ്യ വിലാസം പരിഹരിക്കാൻ ശ്രമിക്കുന്ന റൗട്ടർ ഫ്രെയിം ഉപേക്ഷിക്കുന്നു, ഒരിക്കലും വരാത്ത മറുപടിക്കായി കാത്തിരിക്കുന്നു. ഒരു സ്ഥിര ബൈൻഡിംഗ് എൻട്രി ആ ഭാഗം ശരിയാക്കുന്നു, സംപ്രേഷണ പരിധിയുടെ പ്രശ്നം തൊടാതെ വിടുന്നു. അതായത് രണ്ട് വേറിട്ട പരിമിതികൾ, ഒന്ന് നീക്കിയാൽ മറ്റതിന് ഒന്നും സംഭവിക്കുന്നില്ല.

കാർഡിലേക്ക് യഥാർത്ഥത്തിൽ എത്തുന്ന മൂന്ന് സ്ഥാനങ്ങൾ

ഓരോ പ്രായോഗിക ക്രമീകരണവും ഫ്രെയിം ലക്ഷ്യത്തിന്റെ സെഗ്മെന്റിൽ വയ്ക്കുന്നു, നെറ്റ്‌വർക്കിനെ എത്ര ശല്യപ്പെടുത്തുന്നു എന്നതിൽ അവ വ്യത്യസ്തമാണ്:

1. ലക്ഷ്യ സെഗ്മെന്റിൽ എപ്പോഴും ഓണായിരിക്കുന്ന ഒരു ഉപകരണം വയ്ക്കുക. വൈദ്യുതിയിൽ നിൽക്കുന്ന റൗട്ടർ, NAS അല്ലെങ്കിൽ ചെറിയ ലിനക്സ് പെട്ടി ഫ്രെയിം പ്രാദേശികമായി അയക്കാം, ടണലിലൂടെ അതിൽ എത്തിയ ഉടൻ, VPN യിൽ ഒന്നും മാറുന്നില്ല.
2. റൗട്ടർ തന്നെ ഫ്രെയിം അയക്കട്ടെ. പല ഫേംവെയറുകളും LAN ബ്രിഡ്ജിൽ നിന്ന് അയക്കുന്ന ഉണർത്തൽ പേജ് നൽകുന്നു, ലക്ഷ്യം ആ ബ്രിഡ്ജിൽ ഉള്ളിടത്തോളം ഇത് പ്രവർത്തിക്കുന്നു, രണ്ടാം റൗട്ടറിന് പിന്നിലല്ലെങ്കിൽ.
3. സംപ്രേഷണങ്ങൾ യഥാർത്ഥത്തിൽ കടക്കേണ്ടതുണ്ടെങ്കിൽ സ്ഥലങ്ങളെ TAP തരം ടണൽ ഉപയോഗിച്ച് പാലം ചെയ്യുക. ഇത് രണ്ട് സംപ്രേഷണ ഡൊമെയിനുകൾ കൂട്ടിച്ചേർക്കുന്നു, കൂടെ സംപ്രേഷണ കൊടുങ്കാറ്റുകൾ, ഒരൊറ്റ വിലാസ പ്ലാൻ, രണ്ട് സ്ഥലങ്ങളും ഒരുമിച്ച് കാണുന്ന ഓരോ കണ്ടെത്തൽ പ്രോട്ടോക്കോളും വരുന്നു.

ആദ്യ ഓപ്ഷനാണ് ഒരു യന്ത്രത്തിന് മുൻഗണന നൽകേണ്ടത്. മൂന്നാമത്തേത് തുടർച്ചയായ ചെലവുള്ള നെറ്റ്‌വർക്ക് രൂപകൽപ്പന തീരുമാനമാണ്, അതിനാൽ അതിനെ അങ്ങനെ കാണുക, ഒരു ഡെസ്ക്ടോപ്പിനുള്ള പെട്ടെന്നുള്ള പരിഹാരമായി അല്ല.

ഏത് സഹായി ഫ്രെയിം അയക്കുന്നു, അത് ഏത് ബ്രിഡ്ജിലോ VLAN ലോ ആണെന്ന് എഴുതുക. തെറ്റായ ഇന്റർഫേസിൽ നിന്ന് അയക്കുന്ന സഹായി പൂർണ റെക്കോർഡിംഗും ഒരിക്കലും ഉണരാത്ത യന്ത്രവും നൽകുന്നു, ആ ജോടി ഒരു ഉച്ചയ്ക്ക് തിന്നുന്നു.

ക്ലയന്റിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുൻപ് അയക്കൽ പരിശോധിക്കുക

ആദ്യം ലക്ഷ്യ കാർഡ് നോക്കുക, കാരണം ഒരു അയക്കുന്നയാളും തയ്യാറല്ലാത്ത കാർഡിനെ ഉണർത്താനാകില്ല. താഴെയുള്ള കമാൻഡ് പിന്തുണയുള്ളതും നിലവിലുള്ളതുമായ ഉണർത്തൽ രീതികൾ വായിക്കുന്നു, നിലവിലെ g മൂല്യം എന്നാൽ magic packet ഓണാണ്:

ethtool enp3s0 | grep -A1 'Wake-on'
ip neigh show 192.168.1.50
tcpdump -ni br0 -e 'ether broadcast and udp dst port 9'
etherwake -i br0 3c:7c:3f:00:11:22

അയക്കൽ നടക്കുമ്പോൾ സഹായിയിൽ റെക്കോർഡിംഗ് ഓടിക്കുക, വിജയം അനുമാനിക്കുന്നതിന് പകരം അത് വായിക്കുക. ശരിയായ ബ്രിഡ്ജിൽ നിന്ന് സംപ്രേഷണ ലക്ഷ്യ MAC യോടെ പുറത്തുപോകുന്ന ഫ്രെയിമാണ് അയക്കൽ പ്രവർത്തിച്ചതിന്റെ ഏക തെളിവ്; റെക്കോർഡിംഗ് ശൂന്യമാണെങ്കിൽ അയക്കുന്നയാൾ മറ്റൊരു ഇന്റർഫേസ് തിരഞ്ഞെടുത്തു, ബാക്കി പരിശോധന അർത്ഥശൂന്യമാണ്. UDP ഡാറ്റാഗ്രാമിന് പകരം അസംസ്കൃത ഫ്രെയിം നിർമ്മിക്കുന്ന അയക്കുന്നയാൾ ആ ഫിൽട്ടറിന് ചേരുന്നില്ല, അതിനാൽ ഒന്നും അയച്ചിട്ടില്ല എന്ന് തീരുമാനിക്കുന്നതിന് മുൻപ് നിങ്ങളുടെ ഉപകരണം ഏത് രൂപം ഉപയോഗിക്കുന്നു എന്ന് നോക്കുക.

Windows ൽ കാർഡിന്റെ തുല്യമായ പരിശോധന powercfg /devicequery wake_armed, ഇത് സിസ്റ്റം ഉണർത്താൻ അനുമതിയുള്ള ഉപകരണങ്ങൾ പട്ടികപ്പെടുത്തുന്നു. ആ പട്ടികയിൽ ഇല്ലാത്ത നെറ്റ്‌വർക്ക് അഡാപ്റ്റർ അതിന് അയക്കുന്ന ഓരോ പാക്കറ്റും അവഗണിക്കും, ഫ്രെയിം വയറിൽ എത്ര ശരിയായി കാണപ്പെട്ടാലും.

പിന്നെ ഉണരൽ തന്നെയും തുടർച്ചയും സ്ഥിരീകരിക്കുക. ഓണാകുന്നെങ്കിലും പേരിൽ എത്താനാകാത്ത യന്ത്രത്തിന് സ്ഥിര വിലാസവും DNS രേഖയും വേണം, കാരണം സംപ്രേഷണത്തിലൂടെ പേര് പരിഹരിക്കുന്നത് ഇപ്പോഴും ടണൽ കടക്കുന്നില്ല. വയർലെസ് ഉണർത്തൽ വേറിട്ടതും വയർ പതിപ്പിനെക്കാൾ വളരെ കുറഞ്ഞ വിശ്വാസ്യതയുള്ളതുമാണ്, അതിനാൽ VPN ഉൾപ്പെടുത്തുന്നതിന് മുൻപ് അതേ സെഗ്മെന്റിൽ അത് പരീക്ഷിക്കുക. ടിക്കറ്റിൽ ഇന്റർഫേസ് പേരും സഹായിയുടെ ഹോസ്റ്റും എഴുതുക, കാരണം അടുത്ത തകരാർ സാധാരണയായി അതേ രണ്ട് വസ്തുതകളെക്കുറിച്ചാണ്.