ഒരു ടൈംഔട്ടിന് ശേഷം നിങ്ങളുടെ OpenVPN ക്ലയന്റ് എന്തുകൊണ്ട് നിലയ്ക്കുന്നു

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

മോണിറ്ററിംഗ് അവകാശപ്പെടുന്നതിൽ നിന്നല്ല, യൂണിറ്റ് യഥാർത്ഥത്തിൽ ചെയ്തതിൽ നിന്ന് തുടങ്ങുക. systemctl status openvpn-client@office, journalctl -u openvpn-client@office -n 50 എന്നിവ പുറത്തുപോകാനുള്ള കാരണവും ക്ലയന്റ് പോകുന്നതിന് മുമ്പ് എഴുതിയ അവസാന വരിയും കാണിക്കുന്നു.

ആരും ശ്രദ്ധിക്കുന്നതിന് മുമ്പ് പ്രോസസ് പുറത്തുപോയി

പിശകില്ലാതെ അപ്രത്യക്ഷമാകുന്ന ക്ലയന്റ് സാധാരണയായി മനഃപൂർവം പുറത്തുപോയിരിക്കും. ഈ പെരുമാറ്റം നിർണ്ണയിക്കുന്നത് പ്രൊഫൈലാണ്, സേവന മാനേജരല്ല: ping-exit എതിർവശം മറുപടി നിർത്തുന്ന ഉടൻ പ്രോസസ് അവസാനിപ്പിക്കുന്നു, അതേസമയം ping-restart പ്രോസസ് നിലനിർത്തി അതിനുള്ളിൽ വീണ്ടും ബന്ധിപ്പിക്കുന്നു. സെഷൻ പരിധികളും നിഷ്ക്രിയതാ ടൈമറുകളും പുറത്തുനിന്ന് അതേ ചിത്രം നൽകുന്നു: ടണലും ഇല്ല, അലാറവും ഇല്ല.

രണ്ട് ping നിർദ്ദേശങ്ങൾക്ക് ഒരു പ്രൊഫൈലിൽ ഒരുമിച്ച് നിൽക്കാനാവില്ല, അതിനാൽ ഒന്ന് തിരഞ്ഞെടുത്ത് തിരഞ്ഞെടുപ്പ് രേഖപ്പെടുത്തുക. സെർവറും നോക്കുക, കാരണം അതിന്റെ സ്വന്തം ping-exit ക്ലയന്റ് എന്ത് ആവശ്യപ്പെട്ടാലും സെഷൻ അടയ്ക്കുന്നു, ആ തീരുമാനം ആരെടുത്തുവെന്ന് സെർവർ ലോഗ് മാത്രം രേഖപ്പെടുത്തുന്നു.

ping-exit, ping-restart എന്നിവയ്ക്കിടയിലുള്ള തിരഞ്ഞെടുപ്പ്

സ്വയം സുഖപ്പെടേണ്ട ലാപ്ടോപ്പിനോ വിദൂര സ്ഥലത്തിനോ ping-restart തിരഞ്ഞെടുക്കുക, മരിച്ച ടണൽ പ്രോസസ് നിർത്തി മറ്റെന്തെങ്കിലും അതിൽ പ്രവർത്തിക്കേണ്ട സന്ദർഭങ്ങൾക്ക് ping-exit സൂക്ഷിക്കുക. സംഖ്യകളേക്കാൾ പ്രധാനം ബന്ധമാണ്: ping 10 ഒപ്പം ping-restart 60 എന്നത് പരിശോധനയ്ക്ക് മുമ്പ് പത്ത് സെക്കൻഡ് നിശ്ശബ്ദതയും റീസ്റ്റാർട്ടിന് മുമ്പ് അറുപതും അർത്ഥമാക്കുന്നു, ഇത് നഷ്ടമുള്ള മൊബൈൽ ലിങ്കിൽ ആക്രമണാത്മകവും വയർ ലിങ്കിൽ ന്യായയുക്തവുമാണ്. കാരണം വരിക്ക് അടുത്ത് എഴുതുക, അല്ലാത്തപക്ഷം അടുത്ത വായനക്കാരൻ ഡിഫോൾട്ട് മൂല്യങ്ങൾ മനഃപൂർവമായിരുന്നുവെന്ന് കരുതും.

തുടർന്ന് പുറത്തുപോയത് യഥാർത്ഥത്തിൽ പ്രോസസ് തന്നെയാണെന്ന് ഉറപ്പാക്കുക. ടണൽ മരിച്ചിരിക്കുമ്പോൾ സജീവമെന്ന് റിപ്പോർട്ട് ചെയ്യുന്ന യൂണിറ്റ് മറ്റൊരു പരാജയമാണ്, അത് താഴെ ചർച്ച ചെയ്യുന്നു.

യൂണിറ്റ് യഥാർത്ഥത്തിൽ റീസ്റ്റാർട്ട് ചെയ്യുന്ന മേൽനോട്ടം

systemd ഹോസ്റ്റിൽ ഏറ്റവും ചെറിയ സ്ഥിരമായ മാറ്റം ഒരു drop-in ഫയലാണ്: Restart=on-failure, RestartSec=10 എന്നിവ /etc/systemd/system/[email protected]/restart.conf ഫയലിൽ. systemd അതിന്റെ സ്വന്തം നിർവചനങ്ങൾ വീണ്ടും ലോഡ് ചെയ്യുമ്പോൾ മാത്രമാണ് drop-in വായിക്കുന്നത്, അതിനാൽ അതിനുശേഷം systemctl daemon-reload പ്രവർത്തിപ്പിക്കുക. മൂല്യം എത്തിയെന്ന് അനുമാനിക്കുന്നതിനുപകരം systemctl show -p Restart -p ExecMainStatus openvpn-client@office ഉപയോഗിച്ച് പരിശോധിക്കുക. ഫയൽനാമത്തിലെ ഇൻസ്റ്റൻസ് യൂണിറ്റ് യഥാർത്ഥത്തിൽ ലോഡ് ചെയ്യുന്ന പ്രൊഫൈൽ ആയിരിക്കണം, അതിനാൽ office ന് വേണ്ടി എഴുതിയ ഫയൽ openvpn-client@home ന് ഒന്നും ചെയ്യുന്നില്ല.

on-failure ഒരു കേസ് അവഗണിക്കുന്നു: സ്ഥിതി പൂജ്യമുള്ള വൃത്തിയായ പുറത്തുപോകൽ. ചില പൊളിക്കൽ പാതകൾ അങ്ങനെ അവസാനിക്കുന്നു, അതിനാൽ മാനുവൽ പേജിന്റെ വാക്കുകൾ വിശ്വസിക്കുന്നതിനുപകരം രേഖപ്പെടുത്തിയ സ്ഥിതി വായിക്കുക. നിങ്ങളുടെ ക്ലയന്റ് പൂജ്യത്തോടെ കീഴടങ്ങുകയാണെങ്കിൽ, നിങ്ങൾക്ക് Restart=always ആവശ്യമാണ്, അതിന്റെ വില എന്നത് യഥാർത്ഥത്തിൽ തകർന്ന പ്രൊഫൈൽ സ്റ്റാർട്ട് നിരക്ക് പരിധി പ്രവർത്തിക്കുകയും ജേർണൽ നിറയുകയും ചെയ്യുന്നതുവരെ വീണ്ടും വീണ്ടും തിരികെ വരുന്നു എന്നതാണ്.

Restart=always മനഃപൂർവമായ നിർത്തലിന് ശേഷവും പ്രവർത്തിക്കുന്നു. അറ്റകുറ്റപ്പണിക്ക് systemctl stop ഉപയോഗിക്കുക, നിങ്ങൾ ജോലി ചെയ്യുമ്പോൾ യൂണിറ്റ് നിലയ്ക്കേണ്ടതുണ്ടെങ്കിൽ അത് മാസ്ക് ചെയ്യുക.

ടണൽ നിലയ്ക്കുമ്പോൾ ചോർച്ച പിടിക്കുക

മേൽനോട്ടം ടണൽ തിരികെ കൊണ്ടുവരുന്നു; ടണൽ ഇല്ലാത്തപ്പോൾ ട്രാഫിക് പുറത്തുപോകുന്നത് അത് തടയുന്നില്ല. persist-tun വീണ്ടും ബന്ധിപ്പിക്കലുകൾക്കിടയിൽ ഉപകരണവും അതിന്റെ റൂട്ടുകളും നിലനിർത്തുന്നു, ഇത് സൗകര്യപ്രദവും ഒരു ജാലകം തുറക്കുന്നതുമാണ്. ഉപകരണം അതിജീവിക്കുന്നു, റൂട്ടുകൾ ഇപ്പോഴും അതിലേക്കാണ്, പാക്കറ്റുകൾ സംരക്ഷണമില്ലാതെയും റിപ്പോർട്ടില്ലാതെയും പുറത്തൊഴുകുന്നു. ഇത് ഒരു നയ തിരഞ്ഞെടുപ്പാണ്, നിഷ്പക്ഷ ഡിഫോൾട്ടല്ല.

ഒരു ഹോസ്റ്റിന് സംരക്ഷിക്കപ്പെടാത്ത പാക്കറ്റുകൾ അൽപ്പവും അയയ്ക്കാൻ പാടില്ലെങ്കിൽ, അത് ഫയർവാൾ മാത്രമേ ഉറപ്പാക്കാൻ കഴിയൂ. ടണൽ ഇന്റർഫേസും VPN സെർവറിന്റെ വിലാസവും അനുവദിച്ച് ബാക്കിയെല്ലാം ഉപേക്ഷിക്കുന്ന ഔട്ട്പുട്ട് നിയമം ക്ലയന്റ് മരിച്ചതിനുശേഷവും നിലനിൽക്കുന്നു, ക്ലയന്റിന്റെ സ്വന്തം കോൺഫിഗറേഷനിൽ ക്ലയന്റ് കൊണ്ടുപോകാത്ത ട്രാഫിക് ഫിൽട്ടർ ചെയ്യാൻ ഒന്നുമില്ല.

ക്ലയന്റ് മനഃപൂർവം നിർത്തി ഇത് പരീക്ഷിക്കുക. systemctl stop openvpn-client@office പ്രവർത്തിപ്പിക്കുക, തുടർന്ന് curl -m 5 https://example.com, അത് ഭൗതിക ലിങ്കിലൂടെ വിജയിക്കുന്നതിനുപകരം പരാജയപ്പെടണം. വിജയം എന്നത് ഫയർവാൾ നിയമം ഇല്ലെന്നോ വളരെ അനുവദനീയമാണെന്നോ അർത്ഥമാക്കുന്നു.

വീണ്ടും ബന്ധിപ്പിക്കുക, ടണൽ വീണ്ടും ട്രാഫിക് കൊണ്ടുപോകുന്നുവെന്ന് ഉറപ്പാക്കുക, അതിനുശേഷം മാത്രം പരിശോധന മോണിറ്ററിംഗിൽ ചേർക്കുക. cron-ൽ നിന്ന് ip addr tun ഉപകരണത്തിനായി അന്വേഷിക്കുന്നത് ഏറ്റവും കൂടുതൽ പരാജയപ്പെടുന്ന മേൽനോട്ടമാണ്, കാരണം persist-tun ഉള്ളപ്പോൾ ഉപകരണം സെഷനെക്കാൾ കൂടുതൽ കാലം ജീവിക്കുന്നു, ഒന്നും കൊണ്ടുപോകാതിരിക്കുമ്പോഴും പരിശോധന ആരോഗ്യം റിപ്പോർട്ട് ചെയ്യുന്നു.