സ്ലീപ്പിന് ശേഷം VPN മരിച്ചു: ടണൽ നഷ്ടമായോ പഴയ ആപ്പോ?

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

ഉണർന്ന ശേഷം മൂന്ന് കാര്യങ്ങൾ കേടാകാം

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

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

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

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

ആദ്യം: ടണൽ തിരികെ വന്നോ?

ക്ലയന്റിന്റെ സ്വന്തം സ്റ്റാറ്റസ് ടെക്സ്റ്റിന് പകരം ഇന്റർഫേസും പിയർ അവസ്ഥയും നോക്കുക. വിലാസമുണ്ടെങ്കിലും സമീപകാല ഹാൻഡ്ഷേക്ക് ഇല്ലാത്ത ഇന്റർഫേസ് പേരിൽ മാത്രം നിൽക്കുന്ന ടണലാണ്.

ip -brief addr show
wg show
ip route show table all | head -20

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

റൂട്ടുകളും DNS കോൺഫിഗറേഷനും കൂടി പരിശോധിക്കുക. ടണൽ അതിന്റെ റൂട്ടുകളില്ലാതെ തിരികെ വരാം, ഇന്റർഫേസ് പ്രവർത്തിക്കുകയും ആന്തരിക നാമങ്ങൾ ഇപ്പോഴും തെറ്റായ സെർവറിലൂടെ പരിഹരിക്കപ്പെടുകയും ചെയ്യുന്ന ആശയക്കുഴപ്പമുള്ള അവസ്ഥ ഇത് സൃഷ്ടിക്കുന്നു.

രണ്ടാമത്: എന്തെങ്കിലും അതിനോട് തിരികെ വരാൻ ആവശ്യപ്പെട്ടോ?

ഇവിടെയാണ് താരതമ്യം അതിന്റെ വില നേടുന്നത്. NetworkManager OpenVPN പ്ലഗിൻ പ്രൊഫൈലും നേറ്റീവ് WireGuard കണക്ഷനും വ്യത്യസ്തമായി കൈകാര്യം ചെയ്യുന്നു, കണക്ഷൻ ക്രമീകരണങ്ങളുടെ റഫറൻസ് connection.autoconnect VPN പ്രൊഫൈലുകൾ സജീവമാക്കുന്നില്ല എന്ന് വ്യക്തമായി പറയുന്നു; കണക്ഷനോടൊപ്പം VPN ഉയർത്തുന്ന സംവിധാനം connection.secondaries ആണ്.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

കൈകൊണ്ട് വീണ്ടും ബന്ധിപ്പിക്കുന്നത് ഓരോ തവണയും പ്രശ്നം പരിഹരിക്കുന്നുവെങ്കിൽ, അത് കേടായ ടണലല്ല, കാണാത്ത സജീവമാക്കലിന്റെ അടയാളമാണ്. ലോഗ് സാധാരണയായി ഇന്റർഫേസ് താഴേക്ക് പോകുന്നതും ഒന്നും അതിനെ തിരികെ കൊണ്ടുവരാത്തതും കാണിക്കും.

ഉടൻ ഒരു സ്ലീപ്പ് ഹുക്ക് ചേർക്കാനുള്ള പ്രേരണയെ ചെറുക്കുക. നെറ്റ്വർക്ക് വീണ്ടെടുക്കുന്നതിന് മുൻപ് പ്രവർത്തിക്കുന്ന ഹുക്ക് സഹായിക്കാൻ ശ്രമിക്കുന്ന അതേ പ്രക്രിയയുമായി മത്സരിക്കുന്നു, പുനരുൽപ്പാദിപ്പിക്കാവുന്ന പ്രശ്നത്തെ ഇടയ്ക്കിടെ വരുന്ന പ്രശ്നമാക്കി മാറ്റുന്നു.

മൂന്നാമത്: ആപ്പ് പഴയ അവസ്ഥ പിടിച്ചിരിക്കുന്നുവോ?

VPN തൊടുന്നതിന് മുൻപ് അതേ ലക്ഷ്യത്തിലേക്ക് പൂർണ്ണമായി പുതിയ സെഷൻ തുറക്കുക. പുതിയ സെഷൻ പ്രവർത്തിക്കുകയും പഴയത് പ്രവർത്തിക്കാതിരിക്കുകയും ചെയ്താൽ, ടണൽ കുഴപ്പമില്ല, ആപ്പ് മരിച്ച കണക്ഷൻ പിടിച്ചിരിക്കുന്നു.

ഇത് മൂന്ന് പരിശോധനകളിൽ ഏറ്റവും വിലകുറഞ്ഞതും ഏറ്റവും കൂടുതൽ ഒഴിവാക്കപ്പെടുന്നതുമാണ്, കാരണം പരാജയപ്പെടുന്ന വിൻഡോ നേരിട്ട് സ്ക്രീനിൽ ഉണ്ട്. അത് അടയ്ക്കുക, വീണ്ടും തുറക്കുക, പ്രശ്നം നിലനിൽക്കുന്നുവോ എന്ന് ശ്രദ്ധിക്കുക. പുതിയ സെഷൻ പ്രവർത്തിക്കുന്നുവെങ്കിൽ, ടണൽ അന്വേഷണം പൂർണ്ണമായി നിർത്തുക. അതും പരാജയപ്പെട്ടാൽ, ആപ്പ് കാരണമല്ല, ലക്ഷണമാണ്.

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

താരതമ്യം പുനരുൽപ്പാദിപ്പിക്കാവുന്നതാക്കുക

ചരങ്ങൾ ചെറുതായി സൂക്ഷിക്കുക: ഒരു ആക്സസ് നെറ്റ്വർക്ക്, ഒരു സ്ലീപ്പ് ദൈർഘ്യം, ഓരോ തവണയും അതേ ആദ്യ അഭ്യർത്ഥന. പിന്നീട് രണ്ട് ഫലങ്ങൾ രേഖപ്പെടുത്തുക: കൈകൊണ്ട് വീണ്ടും ബന്ധിപ്പിക്കുന്നത് അത് പരിഹരിക്കുന്നുവോ, മറ്റൊരു സ്ലീപ്പ് പരാജയം തിരികെ കൊണ്ടുവരുന്നുവോ.

അവസാന നിരീക്ഷണമാണ് മൂന്ന് സ്ഥാനാർത്ഥികളെ ഏറ്റവും വിശ്വസനീയമായി വേർതിരിക്കുന്നത്. പരാജയപ്പെട്ട പഴയ സെഷന് ശേഷം പ്രവർത്തിക്കുന്ന പുതിയ സെഷൻ ടണൽ പ്രശ്നമല്ല, ക്ലയന്റ് വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നത് അത് മാറ്റില്ല.

WireGuard-ന്റെ സ്ഥിരമായ keepalive ഈ ചിത്രത്തിൽ NAT മാപ്പിംഗ് keepalive ആയി മാത്രം വരുന്നു. ഒരു മാപ്പിംഗ് തുറന്നു നിർത്താൻ അത് പാക്കറ്റുകൾ അയയ്ക്കുന്നു; യന്ത്രം ഉറങ്ങുന്നത് അത് തടയുന്നില്ല, പ്രക്രിയ താൽക്കാലികമായി നിർത്തിയിരിക്കുമ്പോൾ അയയ്ക്കുന്നത് തുടരാനും കഴിയില്ല.

ടിക്കറ്റിൽ നിങ്ങൾ കണ്ടത് രേഖപ്പെടുത്തുക: മൂന്നിൽ ഏതാണ് കേടായത്, എന്താണ് അത് പരിഹരിച്ചത്, എങ്ങനെയാണ് പുനരുൽപ്പാദിപ്പിച്ചത്. തിങ്കളാഴ്ച മൂടി തുറക്കുന്ന അടുത്ത വ്യക്തി നിങ്ങളോട് നന്ദി പറയും, ഉത്തരം പൂജ്യത്തിൽ നിന്ന് വീണ്ടും കണ്ടെത്തേണ്ടതില്ല.