വിച്ഛേദിക്കപ്പെട്ട VPN-ലേക്ക് OpenConnect എത്ര നേരം വീണ്ടും ശ്രമിക്കണം?

--reconnect-timeout ഒരു ഇടുങ്ങിയ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: ടണൽ വീണതിന് ശേഷം, ഈ ക്ലയന്റ് പ്രോസസ് കൈവിട്ട് പുറത്തുപോകുന്നതിന് മുമ്പ് എത്ര നേരം ശ്രമിച്ചുകൊണ്ടിരിക്കും. OpenConnect മാനുവൽ പേജ് ആ ഓപ്ഷൻ നഷ്ടപ്പെട്ട ലിങ്കിനോ ഉത്തരം നൽകുന്നത് നിർത്തിയ പിയർക്കോ ശേഷമുള്ള വീണ്ടും ശ്രമങ്ങൾക്ക് 300 സെക്കൻഡ് എന്ന രേഖപ്പെടുത്തിയ സ്ഥിരമൂല്യത്തോടെ രേഖപ്പെടുത്തുന്നു, ഈ സംഖ്യ ഒരു പ്രവർത്തിക്കുന്ന ക്ലയന്റിനുള്ള അവസാന തീയതിയാണ്, VPN ലഭ്യമായി തുടരുന്നു എന്നതിന് തെളിവല്ല. ഇത് പ്രോസസ് ജീവനോടെ നിർത്താനുള്ള നയവുമല്ല, ആശയക്കുഴപ്പത്തിന്റെ ഭൂരിഭാഗവും ഇവിടെ നിന്നാണ് തുടങ്ങുന്നത്.

മുകളിൽ രണ്ടാമതൊരു സംവിധാനം ഇരിക്കുമ്പോൾ ആശയക്കുഴപ്പം വളരുന്നു. ക്ലയന്റ് പുനരാരംഭിക്കുന്ന മേൽനോട്ടക്കാരൻ, ഗേറ്റ്വേയിലേക്ക് പിംഗ് ചെയ്യുന്ന പരിശോധകൻ, ഉൾനിർമ്മിത വീണ്ടും-ശ്രമ വിൻഡോ എന്നിവയെല്ലാം ഒരൊറ്റ പരാജയത്തോട് പ്രതികരിച്ചേക്കാം, തുടർന്ന് സംഭവം ആർക്കും ഒത്തുചേർക്കാനാകാത്ത മൂന്ന് സമയരേഖകൾ നൽകുന്നു.

വീണ്ടും-ബന്ധിപ്പിക്കൽ വിൻഡോ യഥാർത്ഥത്തിൽ എന്താണ് പരിമിതപ്പെടുത്തുന്നത്

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

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

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

മേൽനോട്ടക്കാരന്റെ പുനരാരംഭങ്ങളും ക്ലയന്റിന്റെ വീണ്ടും ശ്രമങ്ങളും രണ്ട് പാളികളാണ്

പ്രവർത്തിക്കുന്ന ക്ലയന്റ് അതിന്റെ സ്വന്തം വിൻഡോ ചെലവാക്കട്ടെ, സേവന മാനേജർ എക്സിറ്റിനോട് പ്രതികരിക്കട്ടെ. systemd-ന് കീഴിൽ പുനരാരംഭ നയത്തോടെയുള്ള ഫോർഗ്രൗണ്ട് ക്ലയന്റ് കൃത്യമായി ആ വിഭജനം നൽകുന്നു: പരിമിതമായ കാലയളവിൽ ശ്രമങ്ങൾ, പിന്നെ ഒരു പുനരാരംഭ തീരുമാനം. ഫലം പിന്നീടും പുനർനിർമ്മിക്കാനാകുന്ന ഒരൊറ്റ സമയരേഖയാണ്.

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

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

ആ വരിയിലെ രണ്ട് വിശദാംശങ്ങൾക്ക് ഭാരമുണ്ട്. --background പ്രോസസിനെ വേർപെടുത്തുന്നു, അതിനാൽ pid ഫയൽ അതിന്മേലുള്ള ഏക വിശ്വസനീയമായ പിടി ആകുന്നു, കൂടാതെ ടൈംഔട്ട് ആ അതേ പ്രോസസ് ജീവിച്ചിരിക്കുന്നിടത്തോളം മാത്രം ചെലവാകുന്നു; അതിനെ കൊല്ലുന്ന മേൽനോട്ടക്കാരൻ തുടരാൻ ബജറ്റ് അവശേഷിപ്പിക്കുന്നില്ല.

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

കൈമാറ്റം വീണ്ടും-ശ്രമ ലൂപ്പുമായി മത്സരിക്കാതിരിക്കാൻ

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

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

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

തടസ്സത്തിനിടയിലും ശേഷവും എന്താണ് പരിശോധിക്കേണ്ടത്

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

പരിശോധനകൾ പുറത്തേക്ക് അഭിമുഖീകരിക്കുന്നതായി നിർത്തുക, കാരണം പ്രോസസ് പട്ടിക സ്വയം വളരെ കുറച്ചേ തെളിയിക്കുന്നുള്ളൂ. ചെറിയ തടസ്സത്തിലുടനീളം pid സ്ഥിരതയോടെ നിൽക്കുന്നുണ്ടോ നോക്കുക, പിന്നീട് നീണ്ടതിന് ശേഷം അത് പോയി ഒരിക്കൽ മാറ്റിസ്ഥാപിക്കപ്പെട്ടുവെന്ന് സ്ഥിരീകരിക്കുക:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

ചെറിയ തടസ്സത്തിനിടയിൽ ക്ലയന്റ് യഥാർത്ഥത്തിൽ വീണ്ടും ശ്രമിച്ചുവെന്ന്, നേരത്തെ പുറത്തുപോയില്ലെന്ന്, റൂട്ടുകളും റിസോൾവർ എൻട്രികളും പകർപ്പുകളില്ലാതെ തിരികെ വന്നുവെന്ന് ഉറപ്പാക്കുക. നീണ്ട തടസ്സത്തിന് വൃത്തിയായ എക്സിറ്റും അതിന് ശേഷം കൃത്യം ഒരു പുനരാരംഭവും ഉറപ്പാക്കുക. പ്രാമാണീകരണ പരാജയത്തിന്, ക്ലയന്റ് തന്നെ നിരസിച്ചുകൊണ്ടിരിക്കുന്ന ഗേറ്റ്വേയ്ക്കെതിരെ കറങ്ങുന്നില്ലെന്ന് ഉറപ്പാക്കുക. pid കുന്നുകൂടാതെ ഒരൊറ്റ മൂല്യത്തിലേക്ക് മടങ്ങുന്നുവെന്ന പരിശോധന ചേർക്കുക.

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