കൊല്ലപ്പെട്ട openconnect: റൂട്ടുകളും DNS-ഉം ഇപ്പോഴും ടണലിലേക്കാണ് ചൂണ്ടുന്നത്

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

അവസ്ഥ സൃഷ്ടിക്കപ്പെട്ട ക്രമത്തിൽ യന്ത്രത്തിലൂടെ നടക്കുക: പ്രോസസ്, ലിങ്ക്, റൂട്ട്, resolver. ഓരോ ഘട്ടവും ക്ലയന്റ് യഥാർത്ഥത്തിൽ പോയോ അതോ നിങ്ങളുടെ ടെർമിനലിൽ നിന്ന് വേർപെട്ടത് മാത്രമാണോ എന്ന് പറയുന്നു, ആ വ്യത്യാസമാണ് എന്തെങ്കിലും നന്നാക്കണോ എന്ന് തീരുമാനിക്കുന്നത്.

പ്രോസസിൽ നിന്ന് തുടങ്ങുക, കോൺഫിഗറേഷനിൽ നിന്നല്ല

ഒരു റൂട്ടിൽ തൊടുന്നതിന് മുമ്പ് ടെർമിനൽ തുറന്ന് ഇപ്പോഴും എന്താണ് പ്രവർത്തിക്കുന്നതെന്ന് ചോദിക്കുക. pgrep -a openconnect ഓരോ ഇൻസ്റ്റൻസും അതിന്റെ ആർഗ്യുമെന്റുകളോടെ പട്ടികപ്പെടുത്തുന്നു, അത് pid ഫയലും അതിന് നൽകിയ സ്ക്രിപ്റ്റും കാണിക്കുന്നു. നിങ്ങൾ പ്രതീക്ഷിക്കാത്ത ഒരു പ്രോസസ് ഏത് ലോഗിനെക്കാളും വേഗത്തിൽ ഫാന്റം ടണൽ വിശദീകരിക്കുന്നു.

ഒന്നും പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ, ലിങ്ക് നോക്കുക. ip link show tun0 ഇന്റർഫേസ് അതിജീവിച്ചോ എന്ന് പറയുന്നു, കൂടാതെ ip route show dev tun0 ഇപ്പോഴും അതിൽ ബന്ധിപ്പിച്ചിരിക്കുന്ന റൂട്ടുകൾ പട്ടികപ്പെടുത്തുന്നു. തുടർന്ന് resolver ഇതിലൂടെ പരിശോധിക്കുക resolvectl status. മാറ്റുന്നതിന് മുമ്പ് മൂന്ന് ഔട്ട്പുട്ടുകളും എഴുതിവയ്ക്കുക, ആ രേഖയാണ് പിന്നീട് പഴയ എൻട്രിയെ പുതിയതിൽ നിന്ന് വേർതിരിക്കാനുള്ള വഴി.

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

മാറ്റങ്ങൾ പിൻവലിക്കുന്നത് സഹായ സ്ക്രിപ്റ്റാണ്

openconnect ഇന്റർഫേസ്, റൂട്ടുകൾ അല്ലെങ്കിൽ resolver എൻട്രികൾ സ്വയം നീക്കം ചെയ്യുന്നില്ല. അത് ഒരു ബാഹ്യ സഹായിയെ വിളിക്കുന്നു, /etc/vpnc/vpnc-script upstream build-ൽ, /usr/share/vpnc-scripts/vpnc-script Debian, Ubuntu പാക്കേജുകളിൽ, തിരഞ്ഞെടുപ്പ് ഇതാണ്: -s. ടണൽ ഉയർത്തുന്ന അതേ സ്ക്രിപ്റ്റാണ് അത് പൊളിക്കുന്നതും.

പ്രോസസ് ആ സഹായിയെ വിളിക്കാതെ പുറത്തുപോയാൽ, അവസ്ഥ അവശേഷിക്കും. OpenConnect മാനുവൽ സ്ക്രിപ്റ്റ് ഇല്ലാതെ റൂട്ടിംഗും നാമ സേവനവും ശരിയായി പ്രവർത്തിക്കില്ലെന്ന് അത് വ്യക്തമായി പറയുന്നു, പുറത്തുപോകുമ്പോൾ ഇന്റർഫേസിന്റെ അവസ്ഥ പൊളിക്കുന്ന ഘടകമായി സഹായിയെ വിവരിക്കുന്നു. അതുകൊണ്ടാണ് ക്ലയന്റ് ആരംഭിക്കുമ്പോൾ പാത പ്രധാനമാകുന്നത്: -s.

ആ പാതയിലേക്ക് ഏത് സിഗ്നൽ എത്തുന്നു എന്നത് പതിപ്പുകൾക്കിടയിൽ മാറി. 7.06 മാനുവൽ SIGTERM-നെ സ്ക്രിപ്റ്റ് ഒഴിവാക്കുന്ന തൽക്ഷണ പുറത്തുപോക്കായി കാണുന്നു. നിലവിലെ build-കൾ INT, TERM എന്നിവയെ സെഷൻ ലോഗ് ഓഫ് ചെയ്യപ്പെടുകയും സഹായി പ്രവർത്തിക്കുകയും ചെയ്യുന്ന ശുദ്ധമായ നിർത്തലായി രേഖപ്പെടുത്തുന്നു. രണ്ട് സ്വഭാവങ്ങളിൽ ഒന്ന് അനുമാനിക്കുന്നതിനുപകരം നിങ്ങളുടെ കൈവശമുള്ള ബൈനറിയുടെ SIGNALS വിഭാഗം വായിക്കുക.

man openconnect | sed -n '/^SIGNALS/,/^LIMITATIONS/p'

നിങ്ങളുടെ build രേഖപ്പെടുത്തുന്ന സിഗ്നൽ അയയ്ക്കുക

സിഗ്നൽ അറിഞ്ഞുകഴിഞ്ഞാൽ പ്രോസസ് പാറ്റേൺ കൊണ്ടല്ല, pid കൊണ്ട് നിർത്തുക.

pgrep -a openconnect
sudo kill -INT "$(cat /var/run/openconnect.pid)"

തുടർന്ന് എക്സിറ്റ് സ്റ്റാറ്റസ് വിശ്വസിക്കുന്നതിനുപകരം ആദ്യ ഭാഗത്തെ മൂന്ന് പരിശോധനകൾ ആവർത്തിക്കുക. ip link show tun0 പരാജയപ്പെടേണ്ടതാണ്, ip route show dev tun0 ഒന്നും പ്രിന്റ് ചെയ്യരുത്, കൂടാതെ resolvectl status ഇനി VPN ലിങ്ക് പട്ടികപ്പെടുത്തരുത്.

SIGHUP ഒരു സ്റ്റോപ്പ് ബട്ടണല്ല: അത് വിച്ഛേദിക്കുന്നു, സ്ക്രിപ്റ്റ് പ്രവർത്തിപ്പിക്കുന്നു, സെഷൻ പുനരാരംഭിക്കാവുന്നതായി വിടുന്നു: --cookie. SIGUSR2 തൽക്ഷണ പുനർബന്ധനം നിർബന്ധമാക്കുന്നു. SIGKILL വൃത്തിയാക്കൽ പൂർണ്ണമായും ഒഴിവാക്കുന്നു, ഈ ലേഖനം പറയുന്നത് കൃത്യമായി ആ അവസ്ഥയെക്കുറിച്ചാണ്.

resolv.conf മാറ്റാതെ resolver നന്നാക്കുക

മിക്ക Ubuntu സിസ്റ്റങ്ങളിലും /etc/resolv.conf systemd-resolved-ലേക്കുള്ള സിംബോളിക് ലിങ്കാണ്, നിങ്ങൾ എഡിറ്റ് ചെയ്യേണ്ട ഫയലല്ല. അത് മാറ്റുന്നത് VPN-ന് മാത്രമല്ല, എല്ലാ നെറ്റ്വർക്കുകൾക്കും നാമ വിവർത്തനം തകർക്കുന്നു. പകരം ടണലിന്റെ രജിസ്ട്രേഷൻ നീക്കം ചെയ്യുക:

resolvectl revert tun0
resolvectl query example.com

സിസ്റ്റം systemd-resolved-ന് പകരം resolvconf ഉപയോഗിക്കുന്നുവെങ്കിൽ, ഓരോ ഇന്റർഫേസിന്റെയും രേഖ ലിങ്ക് വിടാൻ പറയുന്നതുവരെ നിലനിൽക്കും, കൂടാതെ resolvconf -d tun0 തുല്യമായ പ്രവർത്തനമാണ്. കമാൻഡ് തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ് ഏത് resolver ഉപയോഗിക്കുന്നുവെന്ന് പരിശോധിക്കുക.

മരിച്ച ലിങ്കിന് പിന്നിലെ സെർവറിലേക്ക് ഇപ്പോഴും ലക്ഷ്യമിടുന്ന lookup ടൈംഔട്ട് ആകുന്നതുവരെ തൂങ്ങിക്കിടക്കുന്നു, ആ കാലതാമസം അവശേഷിക്കുന്ന റൂട്ടിനെക്കാൾ തകർന്ന DNS സെർവറിനെപ്പോലെ തോന്നുന്നു.

അടുത്ത ഡിസ്കണക്ട് വിരസമാക്കുക

സ്റ്റാർട്ടപ്പിലും ഷട്ട്ഡൗണിലും pid ഫയലിന്റെ പാത സമാനമായി നിലനിർത്താൻ ഓരോ തവണയും --pid-file നൽകി, അല്ലെങ്കിൽ openconnect ഒരു unit-ന് കീഴിൽ പ്രവർത്തിപ്പിക്കുക അതിന്റെ KillSignal നിങ്ങളുടെ പതിപ്പ് രേഖപ്പെടുത്തുന്ന സിഗ്നലുമായി പൊരുത്തപ്പെടുന്നു. ആദ്യം ഫോർഗ്രൗണ്ടിൽ പരീക്ഷിക്കുമ്പോൾ സഹായി പ്രിന്റ് ചെയ്യുന്ന ഷട്ട്ഡൗൺ സന്ദേശങ്ങൾ കാണാം.

കണക്ട് ചെയ്യുക, ഡിസ്കണക്ട് ചെയ്യുക, മൂന്ന് പരിശോധനകൾ ഒരിക്കൽ പ്രവർത്തിപ്പിക്കുക. ശുദ്ധമായ പുറത്തുപോക്ക് VPN ലിങ്കോ VPN റൂട്ടോ VPN resolver എൻട്രിയോ വിടുന്നില്ല. മൂന്നിൽ ഒന്ന് അതിജീവിച്ചാൽ, ഏത് ഘടകം വൃത്തിയാക്കാൻ പരാജയപ്പെട്ടുവെന്ന് ഇപ്പോൾ നിങ്ങൾക്കറിയാം. അടുത്ത അന്വേഷണം പിന്നീട് തൂങ്ങിക്കിടക്കുന്ന lookup-ൽ നിന്നല്ല, ആ ഉത്തരത്തിൽ നിന്നാണ് ആരംഭിക്കുന്നത്.