ഓരോ മണിക്കൂറിലെയും OpenVPN വിച്ഛേദം: പുനർചർച്ചയോ യഥാർത്ഥ പുനർബന്ധനമോ?

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

ഘട്ടങ്ങൾ ക്രമത്തിൽ ചെയ്യുക, കാരണം ആദ്യത്തേത് പേജിന്റെ ബാക്കി ഭാഗം നിങ്ങൾക്ക് ബാധകമാണോ എന്ന് തീരുമാനിക്കുന്നു. മുന്നോട്ട് ചാടിയാൽ, അതുമായി യാതൊരു ബന്ധവുമില്ലാത്ത ഒരു തകരാറിനായി ടൈമർ ട്യൂൺ ചെയ്ത് ഒരു വൈകുന്നേരം ചെലവഴിക്കും.

മൃദുവായ പുനഃസജ്ജീകരണത്തെ പുനരാരംഭത്തിൽ നിന്ന് വേർതിരിക്കുക

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

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

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

നിലവിലുള്ള ടൈമർ വായിക്കുക, നിങ്ങളുടെ ഫയലല്ല

reneg-sec ഡാറ്റാ ചാനലിന്റെ പുനർചർച്ചകൾക്കിടയിലുള്ള സെക്കൻഡുകളുടെ എണ്ണമാണ്, അതിന്റെ സ്ഥിരമൂല്യം 3600 ആണ്. ഓരോ പക്ഷവും സ്വന്തം മൂല്യം വഹിക്കുന്നു, രണ്ടിൽ ചെറുതാണ് യഥാർത്ഥത്തിൽ പുതുക്കൽ പ്രചോദിപ്പിക്കുന്നത്. ആ ഒരു നിയമം മിക്ക റിപ്പോർട്ടുകളും വിശദീകരിക്കുന്നു: വലിയ സംഖ്യ സജ്ജീകരിക്കുന്ന ക്ലയന്റ് പ്രൊഫൈലും സെർവർ സ്ഥിരമൂല്യം സൂക്ഷിക്കുമ്പോൾ മണിക്കൂറിൽ ഒരിക്കൽ പുനഃസജ്ജീകരിക്കപ്പെടുന്നു.

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

ക്ലയന്റ് ഫയലിൽ നിന്ന് നിഗമനത്തിലെത്തുന്നതിന് മുമ്പ് സെർവറിന്റെ നിലവിലുള്ള കോൺഫിഗറേഷനും, അത് പുഷ് ചെയ്യുന്ന എല്ലാം ഉൾപ്പെടെ വായിക്കുക. പിന്നീട് വിശദാംശം ഉയർത്തി ഒരു ഇടവേള ആരംഭം മുതൽ അവസാനം വരെ നിരീക്ഷിക്കുക: ലെവൽ 3 ഇതിനകം പുനർചർച്ച വരികൾ കാണിക്കുന്നു, സമയ അടയാളങ്ങൾ സംഭവം ഓരോ 3600 സെക്കൻഡിലും ആവർത്തിക്കുന്നുണ്ടോ അതോ പ്രവർത്തനത്തെ പിന്തുടരുന്നുണ്ടോ എന്ന് പറയുന്നു.

യഥാർത്ഥത്തിൽ പുഷ് ചെയ്യുന്നിടത്ത് അത് മാറ്റുക

പ്രചരിക്കുന്ന പ്രതിവിധി ക്ലയന്റ് പ്രൊഫൈലിലെ ഒരു വരിയാണ്, ഏകദേശം പകുതി സമയം അത് തെറ്റായ സ്ഥലമാണ്. പക്ഷത്തിന്റെ കുറഞ്ഞ മൂല്യം വിജയിക്കുന്നതിനാൽ, ടൈമർ പൂജ്യത്തിൽ സജ്ജീകരിച്ച ക്ലയന്റിനെ മാറ്റാത്ത സെർവർ ഇപ്പോഴും പുനർചർച്ചയ്ക്ക് വിധേയമാക്കാം.

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

പ്രൊഫൈലുകൾ കേന്ദ്രീകൃതമായി നിർമ്മിക്കുന്നിടത്ത്, വിന്യസിച്ച പകർപ്പല്ല, ടെംപ്ലേറ്റ് തിരുത്തുക, അല്ലെങ്കിൽ അടുത്ത പ്രൊവിഷനിംഗ് റൺ നിങ്ങൾ ഇപ്പോൾ നീക്കിയ മൂല്യം പുനഃസ്ഥാപിക്കും. ഒന്നല്ല, രണ്ട് ഇടവേളകൾ നിരീക്ഷിച്ച് പരിശോധിക്കുക: ഒരു ശാന്തമായ മണിക്കൂർ 7200-ൽ സജ്ജീകരിച്ച ടൈമറുമായും യോജിക്കുന്നു.

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

പുനർചർച്ച പ്രവർത്തനരഹിതമാക്കി നിങ്ങൾ എന്ത് ഉപേക്ഷിക്കുന്നു

സ്ഥിരമായ പുനർചർച്ച ഡാറ്റാ ചാനൽ കീകളുടെ ഒരു സെറ്റ് എത്ര കാലം ട്രാഫിക്കിനെ സംരക്ഷിക്കുന്നു എന്ന് പരിമിതപ്പെടുത്തുന്നു. ടൈമർ ഓഫ് ചെയ്യുന്നത് ടണൽ തകർക്കുന്നില്ല, വീട്ടു റൗട്ടറിലോ ചെറിയ ഓഫീസ് ഗേറ്റ്വേയിലോ പ്രായോഗിക സമ്പർക്കം ലഘുവാണ്. ഇത് എന്നിട്ടും ഒരു കൈമാറ്റമാണ്, അത് ചെയ്യുന്നതിന് മുമ്പ് കൈമാറ്റം പറയേണ്ടതാണ്. മാറുന്നത് ഒരു കീ സെറ്റ് എത്ര കാലം ഒരു സെഷനെ സംരക്ഷിക്കുന്നു എന്നതാണ്, ടണൽ ഒട്ടും പ്രവർത്തിക്കുന്നുണ്ടോ എന്നല്ല.

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

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

ഇടവേള മറ്റെവിടെയോ സൂചിപ്പിക്കുമ്പോൾ

കോൺഫിഗറേഷനിലെ രണ്ട് അയൽക്കാർ സമാന ലക്ഷണങ്ങളും വ്യത്യസ്ത പരിഹാരങ്ങളും ഉണ്ടാക്കുന്നു. നിശ്ചിത കാലയളവിൽ ഒന്നും വരാത്തപ്പോൾ ping-restart ടണൽ പുനരാരംഭിക്കുന്നു, ping-exit ക്ലയന്റിനെ പൂർണ്ണമായി താഴ്ത്തുന്നു. ലോഗിൽ എവിടെയും പുനർചർച്ചയില്ലാത്ത നിഷ്ക്രിയ വിച്ഛേദം ഇവയ്ക്കോ, UDP മാപ്പിംഗ് സ്വന്തം ഷെഡ്യൂളിൽ കാലഹരണപ്പെടാൻ വിട്ട NAT ഉപകരണത്തിനോ ഉള്ളതാണ്.

ഉപഭോക്തൃ റൗട്ടറുകൾ, മൊബൈൽ ഹോട്ട്സ്പോട്ടുകൾ, കാരിയർ-ഗ്രേഡ് NAT എന്നിവയെല്ലാം നിഷ്ക്രിയ UDP സെഷനുകൾ ആരോടും പറയാതെ കാലഹരണപ്പെടാൻ വിടുന്നു. ആ പരാജയം ക്ലോക്കിനെയല്ല, നിഷ്ക്രിയതയെ പിന്തുടരുന്നു, അതാണ് സൂചന: പത്ത് ശാന്തമായ മിനിറ്റുകൾക്ക് ശേഷം വിച്ഛേദിക്കപ്പെടുകയും ഒരു മണിക്കൂർ സ്ഥിരമായ ട്രാഫിക്കിനെ അതിജീവിക്കുകയും ചെയ്യുന്ന സെഷൻ പുനർചർച്ച ചെയ്യുന്നില്ല.

നാലാമത്തേത് മാറ്റുന്നതിന് മുമ്പ് മൂന്ന് കാര്യങ്ങൾ എഴുതുക: അളന്ന ഇടവേള, കണ്ടെത്തിയ നിലവിലുള്ള മൂല്യം, അത് കാണിച്ച കമാൻഡ്. ടൈമർ നീങ്ങുമ്പോൾ ഇടവേളയും നീങ്ങുന്നുവെങ്കിൽ, സംവിധാനം തിരിച്ചറിഞ്ഞു, പരിഹാരം മുകളിലെ കൈമാറ്റത്തെക്കുറിച്ചുള്ള തീരുമാനമാണ്. നീങ്ങുന്നില്ലെങ്കിൽ, ക്രമീകരണം തിരികെ വെച്ച് keepalive, NAT അവസ്ഥ, പാക്കറ്റ് നഷ്ടം എന്നിവ നിരീക്ഷിച്ചുകൊണ്ടിരിക്കുക.