ടെർമിനൽ അടയ്ക്കുമ്പോൾ AnyConnect വിച്ഛേദിക്കപ്പെടുന്നു: സെഷൻ പരിശോധനകൾ

ടണൽ പ്രവർത്തിക്കുന്നു, ഒരു അധിക ടെർമിനൽ അടയ്ക്കുന്നു, ക്ലയന്റിൽ ഒരു കീപ്പോലും അമർത്താതെ തന്നെ VPN താഴെ പോകുന്നു. Linux AnyConnect ക്ലയന്റിൽ റിപ്പോർട്ട് ചെയ്യുന്ന കാരണം റൂട്ടിംഗ് അല്ല, സെഷൻ അക്കൗണ്ടിംഗ് ആണ്: ടണൽ ഉയർന്നപ്പോൾ ഏതൊക്കെ ലോഗിൻ സെഷനുകൾ ഉണ്ടായിരുന്നു എന്ന് ക്ലയന്റ് രേഖപ്പെടുത്തുകയും അവയിലേതെങ്കിലും അവസാനിക്കുന്നതിനെ ടണൽ താഴേക്കിടാനുള്ള കാരണമായി കണക്കാക്കുകയും ചെയ്യുന്നു. താഴെയുള്ള പരിശോധനകൾ ക്രമത്തിൽ നടക്കുന്നു, ആദ്യം പരാജയപ്പെടുന്നത് ഈ പെരുമാറ്റമാണോ നിങ്ങൾ കാണുന്നത് എന്ന് അറിയിക്കും. ക്ലയന്റിന്റെ സാധാരണ ഔട്ട്പുട്ടിൽ ടെർമിനലിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, അതിനാൽ കൺസെൻട്രേറ്ററെ കുറ്റപ്പെടുത്തുക എന്ന ആദ്യ ചിന്ത സാധാരണയായി പാഴ്വേലയാണ്.

സിസ്റ്റം ഫയലുകൾ തിരുത്തുന്നതിൽ നിന്ന് തുടങ്ങരുത്. ഓരോ ഘട്ടവും വിച്ഛേദനം വിശദീകരിക്കുന്നു അല്ലെങ്കിൽ ഒരു സാധ്യത ഒഴിവാക്കുന്നു, ചെലവു കുറഞ്ഞ ഘട്ടങ്ങൾ ആദ്യം വരുന്നു.

സെഷൻ വിച്ഛേദനത്തെ അണ്ടർലേ വിച്ഛേദനത്തിൽ നിന്ന് വേർതിരിക്കുക

വിച്ഛേദനത്തിന് ശേഷം ഉടൻ വീണ്ടും കണക്ട് ചെയ്യുക. അതേ നെറ്റ്വർക്കിൽ, പുതിയ ക്രെഡൻഷ്യലുകളില്ലാതെ, ഏതാനും സെക്കൻഡുകൾക്കുള്ളിൽ തിരികെ വരുന്ന ടണൽ മരിച്ച അപ്പ്ലിങ്കോ Wi-Fi റോമിംഗോ കൺസെൻട്രേറ്ററിലെ നിഷ്ക്രിയ ടൈംഔട്ടോ അല്ല, മറിച്ച് അടച്ച സെഷൻ പോലുള്ള പ്രാദേശിക കാരണത്തെ സൂചിപ്പിക്കുന്നു. Connecting ൽ തൂങ്ങിക്കിടക്കുന്നതോ നെറ്റ്വർക്ക് മാറ്റുന്നതുവരെ പരാജയപ്പെടുന്നതോ ആയ ടണൽ മറ്റൊരു ലേഖനമാണ്.

ടണൽ ഉയർന്നപ്പോൾ എന്തെല്ലാം തുറന്നിരുന്നു എന്ന് എഴുതിവയ്ക്കുക: ക്ലയന്റ് പ്രവർത്തിപ്പിച്ച ടെർമിനൽ, ഏതെങ്കിലും രണ്ടാം ഷെൽ, ഗ്രാഫിക്കൽ ലോഗിൻ, മറ്റൊരു യന്ത്രത്തിൽ നിന്നുള്ള ഏതെങ്കിലും SSH സെഷൻ. ആ പട്ടിക നിങ്ങൾക്ക് അൽപസമയത്തിനുള്ളിൽ ആവശ്യമാകും, അടുത്ത വിച്ഛേദനത്തിന് ശേഷം ഓർമ്മയിൽ നിന്ന് അത് പുനർനിർമ്മിക്കുന്നത് വിശ്വസനീയമല്ല.

കണക്ട് ചെയ്ത സമയത്ത് ക്ലയന്റ് എന്താണ് രേഖപ്പെടുത്തിയതെന്ന് പരിശോധിക്കുക

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

എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് ക്ലയന്റിന് കാണാൻ കഴിയുന്നത് പട്ടികപ്പെടുത്തുക:

who
w
last -n 10
sudo ls -l /run/utmp

who ൽ നിന്നുള്ള ഓരോ വരിയും utmp ലെ ഒരു ഉപയോക്തൃ പ്രോസസ് എൻട്രിയാണ്. നിങ്ങളുടെ സെഷൻ രണ്ടുതവണ പ്രത്യക്ഷപ്പെടുന്നെങ്കിൽ, ഒരിക്കൽ ഗ്രാഫിക്കൽ ലോഗിനിനും ഒരിക്കൽ ടെർമിനലിനും, രണ്ട് എൻട്രികളും കണക്ട് ചെയ്ത സമയത്ത് ഉണ്ടായിരുന്നു, രണ്ടും സാധ്യതകളാണ്.

utmp ൽ നിന്ന് നിങ്ങളുടെ സ്വന്തം എൻട്രി മാത്രം നീക്കുക

പ്രസിദ്ധീകരിച്ച പരിഹാരം നിങ്ങൾ ഉപയോഗിക്കാൻ പോകുന്ന സെഷനെ ക്ലയന്റ് തുടങ്ങുന്നതിന് മുൻപ് utmp ൽ അദൃശ്യമാക്കുന്നു. ഒരു ചെറിയ C പ്രോഗ്രാം getutent() വഴി നടന്ന്, ut_line സ്റ്റാൻഡേർഡ് ഇൻപുട്ടിന്റെ TTY-ക്ക് തുല്യമായ റെക്കോർഡ് കണ്ടെത്തി, ആ റെക്കോർഡ് വീണ്ടും എഴുതുന്നു. ക്രമം ബോധപൂർവമാണ്: setutent(), എൻട്രി വായിക്കുക, അതിന്റെ ut_id പകർത്തുക, ut_type DEAD_PROCESS ആയി സജ്ജമാക്കുക, ഉപയോക്തൃ-വരി ഫീൽഡുകൾ മായ്ക്കുക, pututline() ഉപയോഗിച്ച് തിരികെ എഴുതുക, തുടർന്ന് endutent().

അത് കോംപൈൽ ചെയ്ത്, ക്ലയന്റ് തുടങ്ങുന്ന ഷെല്ലിൽ നിന്ന് root ആയി പ്രവർത്തിപ്പിക്കുക:

sudo ./utmpremove && /opt/cisco/anyconnect/bin/vpn -s connect vpn.example.edu

ഉപകരണം ഒന്നും ചെയ്യുന്നില്ല എന്ന ഭൂരിഭാഗം റിപ്പോർട്ടുകൾക്കും രണ്ട് പരാജയ രീതികളാണ് കാരണം. ഇത് സ്റ്റാൻഡേർഡ് ഇൻപുട്ടിനോട് ബന്ധിപ്പിച്ച TTY-യിൽ പ്രവർത്തിക്കുന്നു, അതിനാൽ ടെർമിനലില്ലാത്ത ഒരു സ്ക്രിപ്റ്റിൽ നിന്നോ ക്രോൺ ജോബിൽ നിന്നോ പ്രവർത്തിപ്പിച്ചാൽ ഒരുമിച്ചു ചേർക്കാൻ ഒന്നും ശേഷിക്കുന്നില്ല. കൂടാതെ /run/utmp സാധാരണ ഉപയോക്താക്കൾക്ക് എഴുതാൻ കഴിയില്ല, അതിനാൽ root അല്ലാത്ത റൺ എക്സിറ്റ് സ്റ്റാറ്റസ് പരിശോധിച്ചില്ലെങ്കിൽ നിശ്ശബ്ദമായി പരാജയപ്പെടുന്നു.

ടണൽ അടയ്ക്കലിനെ അതിജീവിക്കുന്നുണ്ടെന്ന് പരിശോധിക്കുക

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

ഇപ്പോഴും വിച്ഛേദിക്കുന്നെങ്കിൽ, നിരീക്ഷിച്ചിരുന്ന സെഷൻ മറ്റെവിടെയോ ആയിരുന്നു, മിക്കപ്പോഴും നിങ്ങളുടെ ടെർമിനൽ സൃഷ്ടിച്ച ഗ്രാഫിക്കൽ ലോഗിൻ, ഒരു TTY എൻട്രി നീക്കം ചെയ്യുന്നത് സഹായിക്കില്ല. കൂടുതൽ ശസ്ത്രക്രിയ ചെയ്യുന്നതിന് പകരം ഒന്നാം ഘട്ടത്തിലെ പൂർണ്ണ പട്ടികയുമായി നിരീക്ഷണം ആവർത്തിക്കുക.

utmp പുനരെഴുത്ത് തെറ്റായ ഉത്തരമാകുമ്പോൾ

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

നിങ്ങളുടെ സ്ഥാപനം അനുസരണത്തിനായി സെഷൻ അക്കൗണ്ടിംഗ് ശേഖരിക്കുന്നെങ്കിൽ, ഈ പരിഹാരം ആ ആവശ്യകതയുമായി വൈരുദ്ധ്യമാകുന്നു, പിന്തുണയ്ക്കുന്ന ഉത്തരം ഒരു ക്ലയന്റ് പതിപ്പോ മറ്റൊരു ആക്സസ് രീതിയോ ആണ്, പാച്ച് ചെയ്ത utmp അല്ല. മിക്കവർക്കും ഏറ്റവും കുറഞ്ഞ ഇടപെടൽ ഉള്ള പരിഹാരം, ദിവസം മുഴുവൻ തുറന്നിരിക്കുന്ന ഒരു സെഷനിൽ നിന്ന് ക്ലയന്റ് തുടങ്ങി ആ ജാലകം വെറുതെ വിടുക എന്നതാണ്.

ടിക്കറ്റ് അടയ്ക്കുന്നതിന് മുൻപ്, ടണൽ ഉയർന്നപ്പോൾ ക്ലയന്റ് ഏത് സെഷനെ നിരീക്ഷിച്ചിരുന്നു എന്ന് രേഖപ്പെടുത്തുക. ആ ഒരു വരിയാണ് നിഗൂഢമായ വിച്ഛേദനത്തെ യന്ത്രത്തിലെ അടുത്ത വ്യക്തിക്ക് പുനരാവിഷ്കരിക്കാവുന്ന അവസ്ഥയാക്കി മാറ്റുന്നത്.