ലാപ്ടോപ്പ് കുറച്ചു സമയം തൊടാതെ കിടന്ന ശേഷം നിങ്ങളുടെ ടണൽ മരിക്കുന്നു, ട്രാക്ക്പാഡ് തൊടുന്ന നിമിഷം അത് തിരികെ വരുന്നു. ഈ മാതൃക കാണിക്കുന്നത് VPN ഗേറ്റവേ നിങ്ങളുടെ വിവരങ്ങൾ നിരസിക്കുന്നു എന്നല്ല, മറിച്ച് വയർലെസ് ലിങ്ക് പവർ സേവിലേക്ക് പോകുന്നു എന്നാണ്. അതേ പ്രൊഫൈലിൽ തിരക്കുള്ള ഒരു രാവിലെ അതിന് തെളിവാണ്: ട്രാഫിക് ഒഴുകുമ്പോൾ ടണൽ ജീവിച്ചിരിക്കുന്നു, റേഡിയോ നിശബ്ദമാകുമ്പോൾ വീഴുന്നു. താഴെയുള്ള പരിശോധനകൾ ക്രമത്തിൽ ചെയ്യുക, ആദ്യം പരാജയപ്പെടുന്നിടത്ത് നിർത്തുക, അതിനുശേഷം മാത്രം ഒരു ക്രമീകരണം മാറ്റുക.

ആദ്യ പരിശോധന: വിച്ഛേദനം നിഷ്ക്രിയത്വത്തെ പിന്തുടരുന്നുണ്ടോ?

ഊഹിക്കുന്നതിനു പകരം ബന്ധം തെളിയിച്ച് തുടങ്ങുക. നിങ്ങൾ അയച്ച അവസാന പാക്കറ്റിന്റെ ഭിത്തി-ഘടികാര സമയം, ക്ലയന്റ് ടണൽ തകർന്നതായി റിപ്പോർട്ട് ചെയ്ത സമയം, അതിനിടയിൽ സ്ക്രീൻ ഓഫായോ എന്നിവ എഴുതി വയ്ക്കുക. ഇടവേള ഓരോ തവണയും ഒന്നുതന്നെയാണെങ്കിൽ നിഷ്ക്രിയത്വത്തിന്റെ വഴിയിൽ പ്രശ്നമുണ്ട്; സജീവ ഉപയോഗത്തിനിടയിൽ വിച്ഛേദനങ്ങൾ ക്രമരഹിതമായി വന്നാൽ അഞ്ചാം പരിശോധനയിലേക്ക് പോകുക.

പിൻവലിക്കാൻ ഒന്നും ചെലവാകാത്ത വിലകുറഞ്ഞ പരീക്ഷണം: ഇരുപത് മിനിറ്റ് ഗേറ്റവേയിലേക്ക് സ്ഥിരമായ കുറഞ്ഞ-നിരക്ക് ping അയക്കുക, യന്ത്രത്തെ തനിച്ച് വിടുക. അപ്പോഴാകെ ടണൽ നിലനിന്നാൽ, തുടർച്ചയായ ചെറിയ ട്രാഫിക് ലക്ഷണത്തെ മറയ്ക്കുകയാണ്, പരിഹരിക്കുകയല്ല, അതും ഉപയോഗപ്രദമായ തെളിവാണ്. ആ ping ഔട്ട്പുട്ട് ഞാൻ കരട് ടെർമിനലിൽ സൂക്ഷിച്ച് പിന്നീട് ക്ലയന്റ് ലോഗുമായി താരതമ്യം ചെയ്യുന്നു, കാരണം രണ്ട് ഘടികാരങ്ങളും അപൂർവമായേ ഒത്തുപോകുന്നുള്ളൂ.

രണ്ടാം പരിശോധന: ഇത് VPN ട്രാഫിക് മാത്രമാണോ?

ടണലിനെ കുറ്റപ്പെടുത്തുന്നതിനു മുൻപ്, ലിങ്ക് തന്നെ ഇപ്പോഴും ഉപയോഗയോഗ്യമാണോ എന്ന് കണ്ടെത്തുക. ടണൽ മരിച്ചെങ്കിലും സ്ക്രീൻ ഇപ്പോഴും ഓഫ് ആയിരിക്കുമ്പോൾ, ആക്സസ് പോയിന്റിന്റെ വിലാസത്തിലേക്കും IP വഴി ഒരു പൊതു ഹോസ്റ്റിലേക്കും എത്താൻ ശ്രമിക്കുക. സാധാരണ ping ഉം പരാജയപ്പെട്ടാൽ, റേഡിയോയോ ആക്സസ് പോയിന്റോ നിങ്ങളെ വിട്ടുകളഞ്ഞു, VPN ക്ലയന്റ് കേവലം കാഴ്ചക്കാരനാണ്.

ടണൽ നിശബ്ദമായിരിക്കുമ്പോൾ സാധാരണ ട്രാഫിക് ഒഴുകുന്നുണ്ടെങ്കിൽ, ലിങ്ക് ആരോഗ്യകരമാണ്, പ്രശ്നം ടണലിന്റെ സ്വന്തം ടൈമറുകളിലോ ക്ലയന്റ് പുനരാരംഭം കൈകാര്യം ചെയ്യുന്ന രീതിയിലോ ആണ്. ഇവ രണ്ട് വ്യത്യസ്ത പരിഹാരങ്ങളാണ്, അതിനാൽ ഈ ഘട്ടം ഒഴിവാക്കരുത്. Wi-Fi ഉം Ethernet ഉം ഉള്ള ലാപ്ടോപ്പിൽ കേബിൾ വലിച്ചൂരി നിഷ്ക്രിയത്വ പരീക്ഷണം ആവർത്തിക്കുക: വയർഡ് Ethernet-ൽ അപ്രത്യക്ഷമാകുന്ന നിഷ്ക്രിയത്വ വിച്ഛേദനം വയർലെസ് പാളിക്ക് അനുകൂലമായ ശക്തമായ തെളിവാണ്.

മൂന്നാം പരിശോധന: പവർ സേവ് അവസ്ഥ വായിക്കുക

മിക്ക ഡെസ്ക്ടോപ്പുകളും നിങ്ങൾക്ക് ഒരു ചെക്ക്ബോക്സ് നൽകുന്നു, പക്ഷേ ആ ബോക്സ് ഡ്രൈവർ ഇരിക്കുന്ന അവസ്ഥയല്ല. ആദ്യം ഡ്രൈവറുടെ സ്വന്തം റിപ്പോർട്ട് വായിക്കുക, പിന്നീട് തീരുമാനിക്കുക. mac80211 ഉള്ള Linux-ൽ ഇന്റർഫേസ് നേരിട്ട് ഉത്തരം നൽകുന്നു:

iw dev wlan0 get power_save          # on or off, per interface
sudo iw dev wlan0 set power_save off # diagnostic only, lost on reconnect

രണ്ടാമത്തെ കമാൻഡ് ഒരു പരീക്ഷണമാണ്, പരിഹാരമല്ല. അത് വിച്ഛേദനം, സ്ലീപ്പ് അല്ലെങ്കിൽ റീബൂട്ട് അതിജീവിക്കുന്നില്ല, അതിനാൽ സ്ഥിരമായ മാറ്റങ്ങൾ അവശേഷിപ്പിക്കാതെ സിദ്ധാന്തം പരിശോധിക്കാനുള്ള വ്യക്തമായ വഴിയാക്കുന്നു.

Windows-ൽ powercfg /q SCHEME_CURRENT സജീവ സ്കീം അച്ചടിക്കുന്നു, വയർലെസ് അഡാപ്റ്ററിന്റെ ഉപവൃക്ഷം അഡാപ്റ്ററിനോട് ഊർജ്ജം ലാഭിക്കാൻ ആവശ്യപ്പെടാമോ എന്ന് കാണിക്കുന്നു; അതേ തിരഞ്ഞെടുപ്പ് ഡിവൈസ് മാനേജറിൽ അഡാപ്റ്ററിന്റെ പവർ മാനേജ്മെന്റ് ടാബിലും ഉണ്ട്. macOS-ൽ ഓരോ ഇന്റർഫേസിനും 802.11 പവർ സേവ് നിങ്ങൾക്ക് കാണിച്ചുതരുന്നില്ല, അതിനാൽ പകരംpmset -g സ്ലീപ്പ്, സ്റ്റാൻഡ്ബൈ പെരുമാറ്റത്തിനായി നോക്കുക. അവിടെ പരാജയം സാധാരണയായി റേഡിയോയുടെ നിഷ്ക്രിയ പെരുമാറ്റത്തിലല്ല, സ്ലീപ്പ്-ഉണരൽ വഴിയിലാണ് കണ്ടെത്തുന്നത്.

നാലാം പരിശോധന: ഒരു കാര്യം മാറ്റുക, പിന്നീട് വീണ്ടും പരിശോധിക്കുക

ഓരോ പ്രവർത്തനത്തിലും കൃത്യമായി ഒരു ചരം മാറ്റി അതേ ജോലിഭാരം ആവർത്തിക്കുക. പവർ സേവ് ഓഫായിരിക്കുമ്പോൾ ടണൽ ഇപ്പോൾ ഒരു മണിക്കൂർ നിഷ്ക്രിയത്വം താങ്ങുന്നുണ്ടെങ്കിൽ, നിങ്ങൾ യഥാർത്ഥത്തിൽ എന്തോ പഠിച്ചു. ഇപ്പോഴും വീഴുന്നുണ്ടെങ്കിൽ, അടുത്ത ആശയം പരിശോധിക്കുന്നതിനു മുൻപ് മാറ്റം പിൻവലിക്കുക, അല്ലെങ്കിൽ ഓവർലാപ്പ് ചെയ്യുന്ന മൂന്ന് ക്രമീകരണങ്ങളും ഏതാണ് പ്രധാനം എന്ന അറിവില്ലായ്മയും ബാക്കിയാകും.

കണക്ഷൻ ജീവനോടെ നിലനിർത്തുന്നത് മറ്റൊരു സ്വതന്ത്ര ചരമാണ്, അത് പവർ സേവുമായി പതിവായി കൂട്ടിക്കലർത്തുന്നു. WireGuard-ന്റെPersistentKeepalive = 25 NAT മാപ്പിംഗ് ചൂടോടെ നിലനിർത്തുന്നു;OpenVPN രണ്ടറ്റത്തുംkeepalive ഉംping-restart ഉപയോഗിക്കുന്നു. രണ്ടും അല്ലാത്തപക്ഷം നിശബ്ദമായ ടണലിൽ ട്രാഫിക് സൃഷ്ടിക്കുന്നു, അതിനാൽ വിച്ഛേദനം പരിഹരിക്കുന്നതായി തോന്നുന്ന ജീവനിലേക്കുള്ള നിലനിർത്തൽ റേഡിയോ പ്രശ്നം പരിഹരിക്കുന്നതിനു പകരം മറയ്ക്കുകയായിരിക്കാം. അവ വെവ്വേറെ, ഓരോന്നായി പരിശോധിക്കുക:

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
PersistentKeepalive = 25

അഞ്ചാം പരിശോധന: റേഡിയോ നിരപരാധിയാകുമ്പോൾ

പവർ സേവ് ഓഫും ജീവനിലേക്കുള്ള നിലനിർത്തൽ ഓണും ആയിട്ടും നിഷ്ക്രിയത്വ വിച്ഛേദനങ്ങൾ തുടരുന്നുണ്ടെങ്കിൽ, ലാപ്ടോപ്പിനു പുറത്തേക്ക് നോക്കുക. ആക്സസ് പോയിന്റുകളും വീട്ടുപയോഗ റൂട്ടറുകളും നിഷ്ക്രിയ NAT അല്ലെങ്കിൽ സെഷൻ എൻട്രികൾ സ്വന്തം ഷെഡ്യൂൾ പ്രകാരം കാലഹരണപ്പെടുത്തുന്നു, VPN സെർവർ ട്രാഫിക് ഇല്ലാത്ത സെഷൻ ഉപേക്ഷിച്ചേക്കാം.ഒരേ SSID പങ്കിടുന്ന ആക്സസ് പോയിന്റുകൾക്കിടയിലെ റോമിംഗും ലിങ്ക് പുനഃസജ്ജമാക്കാം, ക്ലയന്റ് അത് വ്യക്തമായി പറയാതെ തന്നെ.

തുടർന്ന് അതേ നെറ്റ്വർക്കിൽ അതേ നിഷ്ക്രിയത്വ പരീക്ഷണം ചെയ്യുന്ന രണ്ടാമത്തെ ഉപകരണവുമായി താരതമ്യം ചെയ്യുക. രണ്ട് ഉപകരണങ്ങൾ ഒരേ ഇടവേളയിൽ വീഴുന്നത് വഴിയുടെയോ സെർവറിന്റെയോ കഥയാണ്; ഒരു ഉപകരണം മാത്രം വീഴുന്നത് പ്രാദേശിക ഡ്രൈവറിന്റെയോ ഊർജ്ജത്തിന്റെയോ കഥയാണ്. ആ താരതമ്യം പത്ത് മിനിറ്റ് എടുക്കും, തെറ്റായ കോൺഫിഗറേഷൻ വീണ്ടും എഴുതുന്നതിൽ നിന്ന് നിങ്ങളെ രക്ഷിക്കും.

ഇത് സ്ഥിരമാക്കുന്നതിനു മുൻപ്

എന്ത് നിലനിർത്താൻ നിങ്ങൾ തയ്യാറാണെന്ന് തീരുമാനിക്കുക. വിച്ഛേദനം കണ്ട നെറ്റ്വർക്കുകളിൽ മാത്രം പവർ സേവ് ഓഫ് ചെയ്യുന്ന പ്രൊഫൈൽ അടിസ്ഥാന സ്ക്രിപ്റ്റ് ന്യായീകരിക്കാവുന്നതാണ്. ഓരോ നെറ്റ്വർക്കിലും ബാറ്ററി ആയുസ്സിന്റെ വില നൽകി എല്ലാം ഓഫ് ചെയ്യുന്ന ആഗോള ക്രമീകരണം സാധാരണയായി അങ്ങനെയല്ല.

  • യഥാർത്ഥ പവർ സേവ് മൂല്യം സ്ക്രിപ്റ്റിന്റെ അടുത്ത് രേഖപ്പെടുത്തുക, അത് പുനഃസ്ഥാപിക്കാനാകണം.
  • ഓരോ ഡ്രൈവർ അല്ലെങ്കിൽ ക്ലയന്റ് അപ്ഡേറ്റിനു ശേഷവും നിഷ്ക്രിയത്വ പരീക്ഷണം ആവർത്തിക്കുക; സ്ഥിരമൂല്യങ്ങൾ മാറുന്നു.
  • പ്രശ്നം റിപ്പോർട്ട് ചെയ്യുമ്പോൾ ping ലോഗും ക്ലയന്റ് ലോഗും ഒരുമിച്ച് സൂക്ഷിക്കുക.
  • രണ്ടാം ഘട്ടം പരാജയപ്പെട്ടാൽ, VPN ക്രമീകരണങ്ങൾ മാറ്റുന്നത് നിർത്തി അതിനെ പ്രാദേശിക ലിങ്ക് തകരാറായി കണക്കാക്കുക.

നിങ്ങൾ ഒരു കാര്യം മാത്രം ചെയ്യുന്നുവെങ്കിൽ, രണ്ടാം പരിശോധന ചെയ്യുക. ഈ പട്ടികയുടെ ബാക്കി നിങ്ങൾക്ക് ബാധകമാണോ എന്ന് തീരുമാനിക്കുന്നത് അതാണ്, ഉത്തരം പവർ സേവ് എന്ന് മുൻകൂട്ടി തീരുമാനിച്ച ശേഷം ആളുകൾ ഒഴിവാക്കുന്ന ഘട്ടവും അതുതന്നെ.

അനുബന്ധ ലേഖനങ്ങൾ