NetworkManager-ൽ gateway-ping-timeout യഥാർത്ഥത്തിൽ എന്തിനെ കാത്തിരിക്കുന്നു

നെറ്റ്വർക്ക് ഉപയോഗയോഗ്യമാകുന്നതിന് മുമ്പ് ബൂട്ട് ചെയ്യുന്ന ലാപ്ടോപ്പിനെക്കുറിച്ചുള്ള ഒരു ത്രെഡിൽ നിങ്ങൾ connection.gateway-ping-timeout കാണുന്നു, അത് ഉയർത്തുന്നു, എന്നിട്ട് എന്തോ മാറുന്നു. നിങ്ങൾ കരുതുന്ന കാരണത്താൽ ആ മാറ്റം സഹായിച്ചോ എന്നത് വേറെ ചോദ്യമാണ്. ആ ടൈമർ പ്രവർത്തിക്കുമ്പോൾ ആക്ടിവേഷൻ യഥാർത്ഥത്തിൽ എന്താണ് ചെയ്യുന്നത് എന്നതിലും, ഈ കാത്തിരിപ്പിന് രണ്ട് സാധ്യമായ അവസാനങ്ങളുണ്ട് എന്നതിലും നിന്നാണ് ഉത്തരം തുടങ്ങുന്നത്.

കമാൻഡ് ലൈനിൽ നിന്ന് ഒരു കണക്ഷൻ പിന്തുടരുക, അപ്പോൾ അർത്ഥം വ്യക്തമാകും.

ഒരു ആക്ടിവേഷൻ പിന്തുടരുന്നു

ആഗോള ഡിഫോൾട്ടിലല്ല, സംരക്ഷിച്ച കണക്ഷനിൽ നിന്ന് തുടങ്ങുക, കാരണം ഇത് ഓരോ കണക്ഷനുമുള്ള പ്രോപ്പർട്ടിയാണ്. യഥാർത്ഥത്തിൽ ആവശ്യമുണ്ടെങ്കിൽ മാത്രം --show-secrets ചേർക്കുക; ക്രമീകരണം തന്നെ ഒരു രഹസ്യമല്ല.

nmcli -f connection.id,connection.gateway-ping-timeout connection show
nmcli connection show "Wired connection 1" | grep gateway-ping

പ്രോപ്പർട്ടി പൂജ്യമായിരിക്കുമ്പോൾ, അതാണ് രേഖപ്പെടുത്തിയ ഡിഫോൾട്ട്, അഡ്രസ്സിംഗ് പൂർത്തിയാകുന്നതോടെ ആക്ടിവേഷൻ മുന്നോട്ട് പോകുന്നു. ഒരു പോസിറ്റീവ് മൂല്യം നൽകിയാൽ, ഗേറ്റ്വേയിൽ നിന്ന് മറുപടി വരുന്നതുവരെയോ ടൈംഔട്ട് കഴിയുന്നതുവരെയോ IP കോൺഫിഗറേഷന്റെ ആക്ടിവേഷൻ കാത്തിരിക്കുന്നു.

തുടർന്ന് ഇവന്റ് സ്ട്രീം നിരീക്ഷിച്ചുകൊണ്ട് കണക്ഷൻ താഴ്ത്തി വീണ്ടും ഉയർത്തുക. നിങ്ങൾ കാണുന്ന ക്രമമാണ് ഈ ക്രമീകരണത്തിന്റെ പ്രവർത്തനം: ഉപകരണ നില, അഡ്രസ്സിംഗ്, കാത്തിരിപ്പ്, ഒടുവിൽ ആശ്രിത സേവനങ്ങൾ സാധാരണയായി ക്രമീകരിക്കുന്ന ആക്ടിവേറ്റഡ് നില.

കാത്തിരിപ്പിന് രണ്ട് അവസാനങ്ങളുണ്ട്

രണ്ട് അവസാനങ്ങളും പ്രധാനമാണ്, മിക്ക ആളുകളും ഓർക്കുന്നത് ഒന്ന് മാത്രം. ഗേറ്റ്വേയിൽ നിന്നുള്ള മറുപടി കാത്തിരിപ്പ് നേരത്തെ അവസാനിപ്പിക്കുന്നു, എന്തെങ്കിലും മറുപടി നൽകിയോ ഇല്ലയോ എന്നത് പരിഗണിക്കാതെ ടൈംഔട്ടും അത് അവസാനിപ്പിക്കുന്നു. ആക്ടിവേഷൻ പൂർത്തിയാകുന്നതിന് മുമ്പ് ഈ പ്രോപ്പർട്ടി വിജയകരമായ ping ആവശ്യപ്പെടുന്നില്ല.

ആ ഒരു വാക്യം ഹോട്ടലുകളിലും സമ്മേളന വേദികളിലും ഉള്ള ലാപ്ടോപ്പുകളെക്കുറിച്ചുള്ള ഒരുപാട് ആശയക്കുഴപ്പം തീർക്കുന്നു, അവിടെ പ്രവേശന പോർട്ടൽ നിങ്ങൾ ലോഗിൻ ചെയ്യുന്നതുവരെ ICMP നിരസിക്കുന്നത് പതിവാണ്. ടൈംഔട്ട് കഴിഞ്ഞതിന് ശേഷവും കണക്ഷൻ ആക്ടിവേറ്റ് ചെയ്യുന്നു; അത് ആവശ്യമായതിനേക്കാൾ വൈകി മാത്രം അങ്ങനെ ചെയ്യുന്നു, കണക്ഷന് ശേഷം ക്രമീകരിച്ചിട്ടുള്ള ഓരോ സേവനവും അതിനൊപ്പം കാത്തിരിക്കുന്നു.

ഇത് ഒരു ലൈവ്നസ് പരിശോധനയുമല്ല. കണക്ഷൻ ഉയർന്നതിന് ശേഷം ഗേറ്റ്വേയിലേക്ക് ping ആരംഭിക്കുന്ന ഒന്നും വിവരണത്തിലില്ല, പിന്നീടുള്ള ping പരാജയപ്പെട്ടതിനാൽ സജീവ പ്രൊഫൈൽ വിച്ഛേദിക്കുന്ന ഒന്നുമില്ല. നഷ്ടം കണ്ടെത്തൽ ആവശ്യമാണെങ്കിൽ, അത് പ്രോട്ടോക്കോളിനോ ടണൽ ഉടമയ്ക്കോ ഉള്ളതാണ്, ആക്ടിവേഷനിൽ ഒരിക്കൽ പ്രവർത്തിച്ച ഒരു പ്രോപ്പർട്ടിക്കല്ല.

രണ്ട് വസ്തുക്കൾ, ഒരു ക്രമീകരണം

വയേർഡ് അടിസ്ഥാന പ്രൊഫൈലും VPN പ്രൊഫൈലും വെവ്വേറെ കോൺഫിഗറേഷൻ വസ്തുക്കളാണ്, ഒന്നിൽ പ്രോപ്പർട്ടി ക്രമീകരിക്കുന്നത് മറ്റൊന്നിനെ ബാധിക്കുന്നില്ല. അടിസ്ഥാന കണക്ഷൻ പേരിടുന്ന VPN പ്രൊഫൈൽ അതിന്റെ ആക്ടിവേഷൻ ക്രമീകരണങ്ങളൊന്നും പാരമ്പര്യമായി സ്വീകരിക്കുന്നില്ല, അതുകൊണ്ടാണ് നിങ്ങൾ മാറ്റിയ മൂല്യം നിങ്ങൾ നിരീക്ഷിച്ചിരുന്ന കാര്യത്തിൽ യാതൊരു ഫലവുമില്ലാത്തതായി തോന്നുന്നത്.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office VPN" | grep gateway-ping

പേരുകളല്ല, UUID-കൾ വായിക്കുക. പുനഃസ്ഥാപനത്തിനോ പ്രൊഫൈൽ വീണ്ടെടുക്കലിനോ ശേഷം പേരുകൾ തനിപ്പകർപ്പാകുന്നു, ഒരേ ദൃശ്യ നാമമുള്ള രണ്ട് കണക്ഷനുകൾ യഥാർത്ഥ ഫയൽ മാറാതിരിക്കെ തെറ്റായ ഫയൽ എഡിറ്റ് ചെയ്യാൻ നിങ്ങളെ പ്രേരിപ്പിക്കും.

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

കാത്തിരിപ്പിന് സാക്ഷ്യപ്പെടുത്താൻ കഴിയാത്തത്

ഏറ്റവും കൂടുതൽ സമയം എടുക്കുന്ന ഭാഗം ഇവിടെയാണ്. പ്രാദേശിക റൂട്ടറിൽ നിന്നുള്ള മറുപടി, ആക്ടിവേഷൻ സമയത്ത് ഒരു ഹോസ്റ്റ് ഒരു ICMP എക്കോയ്ക്ക് മറുപടി നൽകി എന്ന് മാത്രം തെളിയിക്കുന്നു. VPN എൻഡ്പോയിന്റ് റിസോൾവ് ചെയ്യുന്നുണ്ടോ, ക്ലയന്റിന്റെ ഐഡന്റിറ്റി സ്വീകരിക്കപ്പെടുന്നുണ്ടോ, സ്വകാര്യ റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടോ, ഓഫീസ് റിസോൾവർ മറുപടി നൽകുന്നുണ്ടോ, നിങ്ങൾക്ക് പ്രധാനമായ ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുമോ എന്നൊന്നും അത് തെളിയിക്കുന്നില്ല.

അവ വെവ്വേറെ തെളിവുകളുള്ള വെവ്വേറെ ആശ്രിതത്വങ്ങളാണ്. DNS പരാജയപ്പെടുമ്പോഴും ഗേറ്റ്വേയ്ക്ക് മറുപടി നൽകാം, എല്ലാ ആപ്ലിക്കേഷൻ പാതകളും പ്രവർത്തിക്കുമ്പോഴും ഗേറ്റ്വേയ്ക്ക് നയപ്രകാരം ICMP നിശ്ശബ്ദമായി ഉപേക്ഷിക്കാം. അതിനാൽ ഈ പ്രോപ്പർട്ടിയിൽ വ്യവസ്ഥ വയ്ക്കുന്നത് ഏത് പാളി വൈകുന്നു എന്നതിനെക്കുറിച്ചുള്ള ഒരു ഊഹമാണ്, അതിന്റെ അളവല്ല.

ഒരു ആശ്രിത സേവനത്തിനായി കാത്തിരിക്കുകയാണെങ്കിൽ, അതിന് എന്ത് വേണമെന്ന് പേരിടുക. അനുവദിച്ച വിലാസത്തിന് അഡ്രസ്സിംഗ് മറുപടി നൽകുന്നു. ടണലിന് ടണലിന്റെ സ്വന്തം നില മറുപടി നൽകുന്നു. സ്വകാര്യ നാമത്തിന് ഒരു ക്വറി മറുപടി നൽകുന്നു. ആപ്ലിക്കേഷന് ആപ്ലിക്കേഷൻ മറുപടി നൽകുന്നു, ആ മറുപടികളൊന്നും ഗേറ്റ്വേയുടെ പേരിലുള്ള ഒരു ടൈമറിൽ നിന്ന് വരുന്നില്ല.

മാറ്റുന്നുവെങ്കിൽ, എന്തുകൊണ്ടെന്ന് എഴുതിവയ്ക്കുക

അംഗീകരിച്ച മാറ്റത്തിന് മുമ്പ് മുമ്പത്തെ മൂല്യവും കാരണവും രേഖപ്പെടുത്തുക, എന്നിട്ട് എല്ലായിടത്തുമല്ല, നിർദ്ദിഷ്ട കണക്ഷനിൽ അത് ക്രമീകരിക്കുക. നീണ്ട കാത്തിരിപ്പ് ആ കണക്ഷന് ശേഷം ക്രമീകരിച്ചിട്ടുള്ള എല്ലാറ്റിന്റെയും ആക്ടിവേഷൻ സമയം മാറ്റുന്നു, അത് സാവധാനമുള്ള സിസ്റ്റത്തെ മികച്ചതായും വേഗമുള്ളതിനെ തകർന്നതായും തോന്നിപ്പിക്കാം.

ഒരു ചരിത്രപരമായ കെണി പേരിടാൻ യോഗ്യമാണ്: ഇത്തരം ഒരു മൂല്യം ചിലപ്പോൾ പഴയ എഡിറ്റർ ഒരു പ്രൊഫൈൽ സ്വീകരിക്കാൻ വേണ്ടി മാറ്റപ്പെടുന്നു. അതാണ് യഥാർത്ഥ കഥയെങ്കിൽ, നിങ്ങൾക്ക് ഒന്നല്ല, രണ്ട് സംഭവങ്ങളുണ്ട്. എഡിറ്റർ സേവ് ചെയ്തു, ഒരു ലൈവ് നെറ്റ്വർക്ക് നയം മാറി. എഡിറ്ററോ പ്ലഗിനോ ശരിയാക്കി ടൈമർ തിരികെ വയ്ക്കുക.

NetworkManager സോഴ്സ് ഈ പ്രോപ്പർട്ടിയെ ഗേറ്റ്വേ മറുപടി അല്ലെങ്കിൽ ടൈംഔട്ട് വരെയുള്ള IP അഡ്രസ്സിംഗ് വിജയത്തിന്റെ കാലതാമസമായി നിർവചിക്കുന്നു, ഡിഫോൾട്ട് പൂജ്യം, കൂടാതെ കണക്ഷൻ ക്രമീകരണത്തിന്റെ നിർവചനം രണ്ടാം കൈയിൽ നിന്ന് കേട്ട ഏതെങ്കിലും സ്വഭാവത്തെ ആശ്രയിക്കുന്നതിന് മുമ്പ് വായിക്കേണ്ട റഫറൻസാണ്.