ലാപ്ടോപ്പ് ഉണരുന്നതിന് ശേഷം OpenVPN എന്തിന് മരിക്കുന്നു?

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

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

യന്ത്രവൽക്കരിക്കുന്നതിന് മുൻപ് ഉണരൽ പുനരുൽപ്പാദിപ്പിക്കുക

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

ക്ലയന്റ് സ്വയം തിരികെ വന്നാൽ, ഹൂക്ക് വിശ്വാസ്യതയ്ക്ക് പകരം അധിക തിരക്ക് ചേർക്കുന്നു. അത് ഒരിക്കലും കരകയറുന്നില്ലെങ്കിൽ, യന്ത്രവൽക്കരണമാണ് സത്യസന്ധമായ പരിഹാരം.

systemd സ്ലീപ്പ് ഹൂക്ക് യഥാർത്ഥത്തിൽ എവിടെയാണ്

പഴയ പല ഗൈഡുകളും /etc/pm/sleep.d ചൂണ്ടിക്കാണിക്കുന്നു, ഇത് pm-utils സ്വന്തമാക്കുന്ന ഡയറക്ടറിയാണ്, systemd അടിസ്ഥാനമാക്കിയ സ്ലീപ്പ് ഇത് ഒരിക്കലും സമീപിക്കുന്നില്ല. systemd /usr/lib/systemd/system-sleep/, /etc/systemd/system-sleep/ എന്നിവയിൽ നിന്ന് ഹൂക്കുകൾ വായിക്കുന്നു, ആദ്യം ഘട്ടവും പിന്നീട് പ്രവർത്തനവും നൽകുന്നു, അതിനാൽ ഹൂക്ക് ശാഖപിരിയുന്ന ഏക മൂല്യങ്ങൾ pre, post എന്നിവയാണ്. പാക്കേജ് ചെയ്ത ഫയൽ തിരുത്തുന്നതിന് പകരം പ്രാദേശിക പകർപ്പ് /etc ക്ക് കീഴിൽ സൂക്ഷിക്കുക, സ്ക്രിപ്റ്റ് പരിവർത്തനത്തിന് നടുവിൽ root ആയി പ്രവർത്തിക്കുന്നു എന്ന് ഓർക്കുക, അതിനാൽ അത് വേഗം മടങ്ങണം.

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart ഒരു യൂണിറ്റിനെ സ്പർശിക്കുന്നത് അത് ഇതിനകം സജീവമാകുമ്പോൾ മാത്രമാണ്, അതിനാൽ നിങ്ങൾ ബോധപൂർവം ഓഫ് ചെയ്ത ടണൽ ഉണരലിലുടനീളം ഓഫായി തന്നെ തുടരും. --no-block ക്ലയന്റ് ചർച്ച നടത്തുമ്പോൾ ഹൂക്ക് കാത്തിരിക്കുന്നത് തടയുന്നു, നെറ്റ്വർക്ക് ഇതുവരെ ഉയർന്നിട്ടില്ലാത്തപ്പോൾ ഇത് പ്രധാനമാണ്. രണ്ട് ഫ്ലാഗുകളും ഒരുമിച്ച് ഉണരൽ ശ്രേണി മുഴുവൻ പിടിച്ചുവയ്ക്കുന്നതിന് പകരം നിശ്ശബ്ദമായി പരാജയപ്പെടുന്ന ഹൂക്കിനെ അർത്ഥമാക്കുന്നു. യൂണിറ്റ് ഇതിനകം നിർത്തിയിട്ടുണ്ടെങ്കിൽ ഒന്നും സംഭവിക്കുന്നില്ല, അതാണ് അവിടെ നിങ്ങൾ ആഗ്രഹിക്കുന്ന ഫലം.

സേവനം വീണ്ടെടുക്കുക, tun0 അനങ്ങാതിരിക്കട്ടെ

tun0 കൈകൊണ്ട് താഴ്ത്തിയാൽ, ഡീമൺ ഇനി സ്വന്തമല്ലാത്ത ഇന്റർഫേസ് നിരീക്ഷിച്ചുകൊണ്ടിരിക്കും, അടുത്ത അവസ്ഥാ മാറ്റം ആശയക്കുഴപ്പമുള്ള പിശകുകൾ ഉണ്ടാക്കും. ഇന്റർഫേസിന് പകരം സേവനത്തെയോ അതിന്റെ കണക്ഷൻ പ്രൊഫൈലിനെയോ ലക്ഷ്യം വയ്ക്കുക; ആദ്യം യൂണിറ്റിന്റെ കൃത്യമായ പേര് പരിശോധിക്കുക, കാരണം ഡിസ്ട്രിബ്യൂഷൻ പാക്കേജുകളും OpenVPN 3 ഉം NetworkManager ഉം എല്ലാം വ്യത്യസ്തമായവ തിരഞ്ഞെടുക്കുന്നു. NetworkManager പ്രൊഫൈൽ ആ കണക്ഷൻ റീസൈക്കിൾ ചെയ്യുമ്പോൾ തിരികെ വരുന്നു, അതിനാൽ systemd യൂണിറ്റ് അവിടെ ലക്ഷ്യമല്ല. സംവിധാനം എന്തുമാകട്ടെ, അത് നിങ്ങൾ കൈകൊണ്ട് പരിശോധിച്ച അതേ പ്രവർത്തനമായിരിക്കണം.

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

നിങ്ങൾക്ക് നിയന്ത്രിക്കാൻ കഴിയാത്ത സമയം കൈകാര്യം ചെയ്യുക

വയർലെസ് അസോസിയേഷനും DHCP യും പലപ്പോഴും ഹൂക്ക് പ്രവർത്തിച്ച ശേഷം പൂർത്തിയാകുന്നു, അതിനാൽ സെർവറിലേക്ക് പാത ഇല്ലാത്തപ്പോൾ പുനരാരംഭം പരാജയപ്പെടാം. ആ വിലാസത്തിനായി അൽപ്പം കാത്തിരിക്കുക, ഒരിക്കൽ കൂടി ശ്രമിക്കുക, ഫലം രേഖപ്പെടുത്തുക.

പേര് നിർണ്ണയം ഒരു വേറിട്ട മത്സരമാണ്, കാരണം ഡെസ്ക്ടോപ്പിന്റെ നെറ്റ്വർക്ക് സ്റ്റാക്ക് ടണൽ ഇതിനകം ഉയർന്നതിന് ശേഷം DNS പുനഃസ്ഥാപിക്കാം. പ്രവർത്തിക്കുന്ന റൂട്ടിൽ നിന്ന് അനുമാനിക്കുന്നതിന് പകരം resolvectl query internal.example ഉപയോഗിച്ച് ലുക്കപ്പുകൾ വെവ്വേറെ പരിശോധിക്കുക. ശരിയായി റൂട്ട് ചെയ്ത് ഒന്നും പരിഹരിക്കാത്ത ടണൽ DNS പ്രശ്നമാണ്, ഹൂക്കിന്റെ പ്രശ്നമല്ല.

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