DHCP പുതുക്കലിന് ശേഷം VPN വീഴുമോ? വിലാസങ്ങൾ താരതമ്യം ചെയ്യുക

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

വീണ ക്ലയന്റിൽ നിന്ന് തുടങ്ങുക

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

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

ഇവന്റിന് ചുറ്റുമുള്ള നാല് മൂല്യങ്ങൾ താരതമ്യം ചെയ്യുക

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

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

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

പുതുക്കൽ എന്ത് മാറ്റാം, എന്ത് മാറ്റാനാവില്ല

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

കണക്ഷന്റെ പൊതു വശം ഒരു പ്രാദേശിക മാറ്റവും കൂടാതെ മാറാം. കാരിയർ-ഗ്രേഡ് വിവർത്തനത്തിന് പിന്നിൽ, VPN പിയർ കാണുന്ന വിലാസം പ്രാദേശിക ലീസ് ചെയ്തതിൽ നിന്ന് സ്വതന്ത്രമായി വീണ്ടും അനുവദിക്കാം, ആ വീണ്ടും അനുവദിക്കൽ ക്ലയന്റിന്റെ ഉള്ളിൽ നിന്ന് പ്രാദേശിക നെറ്റ്‌വർക്ക് പരാജയത്തിന് സമാനമായി കാണുന്നു. പ്രാദേശികമായി റിപ്പോർട്ട് ചെയ്ത വിലാസത്തെ പിയർ വശത്തുള്ള നിരീക്ഷണവുമായി താരതമ്യം ചെയ്യുക മാത്രമാണ് അവയെ വേർതിരിക്കാനുള്ള വഴി.

ക്ലയന്റ് പൊരുത്തപ്പെടാൻ പരാജയപ്പെടുമ്പോൾ

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

സേവനം തിരികെ കൊണ്ടുവരുന്ന കൈകൊണ്ടുള്ള റീസ്റ്റാർട്ട് പൊരുത്തപ്പെടുത്തൽ എവിടെ പരാജയപ്പെട്ടു എന്നതിനുള്ള സൂചനയാണ്, ലീസും ടണലുകളും പൊരുത്തപ്പെടില്ല എന്നതിനുള്ള തെളിവല്ല. പരീക്ഷണ വേളയിൽ തടയൽ നയം നിലനിർത്തുക, അല്ലെങ്കിൽ പരീക്ഷണം തന്നെ മറ്റൊരു കാരണത്തിന്റെ തടസ്സമായി മാറും. ക്ലയന്റ് സ്വയം കരകയറിയോ, എത്ര സമയമെടുത്തു, ഏത് വിലാസത്തിലേക്ക് വീണ്ടും ശ്രമിച്ചു എന്നിവ രേഖപ്പെടുത്തുക; ആ ക്രമം ഇന്റർഫേസിൽ കാണിക്കുന്ന വിച്ഛേദന കാരണത്തെക്കാൾ കൂടുതൽ പറയുന്നു.

കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് സംഭവം ആവർത്തിക്കുക

ഷെഡ്യൂളിനായി കാത്തിരിക്കുന്നതിന് പകരം അവസ്ഥ പുനർനിർമ്മിക്കുക: ലീസ് വിട്ട് വീണ്ടും പുതുക്കുക, അല്ലെങ്കിൽ തത്തുല്യമായ നിയന്ത്രിത സംഭവം നിർബന്ധമാക്കി ടണൽ അതിജീവിക്കുന്നുണ്ടോ എന്ന് നിരീക്ഷിക്കുക. മാനേജുചെയ്യുന്ന നെറ്റ്‌വർക്കിൽ ഏത് വിലാസ മാറ്റവും നെറ്റ്‌വർക്ക് ഉടമയുമായി ഏകോപിപ്പിക്കുക, കാരണം ഏകപക്ഷീയമായ സ്ഥിര അനുവാദം ആ വിലാസം ഇതിനകം ഉള്ള ഉപകരണവുമായി കൂട്ടിയിടിക്കാം.

പിന്തുണയുള്ള തിരുത്തലിന് ശേഷം അതേ സംഭവം ആവർത്തിച്ച്, പിന്നീട് ഒരു ആപ്ലിക്കേഷനും പേര് അന്വേഷണവും പരീക്ഷിക്കുക, കാരണം വീണ്ടും ബന്ധിപ്പിക്കുകയും എന്നാൽ DNS തകർക്കുകയും ചെയ്യുന്ന ടണൽ പ്രധാനമായ പരീക്ഷണത്തേക്കാൾ ദുർബലമായ പരീക്ഷണത്തിൽ വിജയിക്കുന്നു. ഷെഡ്യൂൾ ചെയ്ത ലീസിനെ കാരണമായി പേരിടുന്നതിന് പകരം നിങ്ങൾ നിരീക്ഷിച്ച നിർദ്ദിഷ്ട മാറ്റം അതിന്റെ സമയമുദ്രയോടെ റിപ്പോർട്ട് ചെയ്യുക. ഈ രണ്ട് റിപ്പോർട്ടുകൾ തമ്മിലുള്ള വ്യത്യാസം അടുത്തയാൾ തകരാർ പുനർനിർമ്മിക്കാനാകുമോ അതോ കേട്ടുകേൾവി മാത്രമോ എന്നതാണ്.