SIGKILL-ന് ശേഷം OpenVPN DNS ബാക്കിയാകുന്നു: ആദ്യം ഉടമയെ പരിശോധിക്കുക

OpenVPN ക്ലയന്റ് കൊല്ലപ്പെട്ടതിന് ശേഷം DNS പരിഹരിക്കുന്നത് നിർത്തുന്നു, ആദ്യ സ്വാഭാവിക പ്രതികരണം /etc/resolv.conf വീണ്ടും എഴുതുക എന്നതാണ്. ആ മാറ്റം പ്രവർത്തിക്കുന്ന ഒരു റിസോൾവർ തകർക്കാം, അതേസമയം യഥാർത്ഥ പഴയ അവസ്ഥ മറ്റൊരിടത്താണ്. ആദ്യം പരിഹരിക്കേണ്ട ചോദ്യം ടണൽ ഇൻസ്റ്റാൾ ചെയ്ത DNS ക്രമീകരണങ്ങളുടെ ഉടമ ആരാണ്, ക്ലീനപ്പ് ഒഴിവാക്കിയ പുറത്തുപോക്കിന് യഥാർത്ഥത്തിൽ പ്രസക്തിയുണ്ടായിരുന്നോ എന്നതാണ്.

മൂന്ന് വ്യവസ്ഥകൾ അറ്റകുറ്റപ്പണി തീരുമാനിക്കുന്നു: പ്രക്രിയ അവസാനിപ്പിച്ച സിഗ്നൽ, ക്രമീകരണങ്ങൾ സ്വീകരിച്ച റിസോൾവർ ഘടകം, ടണൽ ലിങ്ക് ഇപ്പോഴും നിലവിലുണ്ടോ എന്നത്. ഈ ക്രമത്തിൽ ഉത്തരം നൽകുക, പരിഹാരം സാധാരണയായി ഒരു ആഗോള ഫയലും തൊടാതെ വരും.

ഏത് തരത്തിലുള്ള പുറത്തുപോക്കാണ് സംഭവിച്ചതെന്ന് തീരുമാനിക്കുക

Community പതിപ്പിലെ OpenVPN ൽ SIGINT-ഉം SIGTERM-ഉം മിതമായ പുറത്തുപോക്കിനുള്ള അഭ്യർത്ഥനകളാണ്. SIGKILL പിടിക്കാനാവില്ല: അത് തടയാനോ കൈകാര്യം ചെയ്യാനോ കഴിയില്ല, അതിനാൽ ഒരു ഷട്ട്ഡൗൺ റൂട്ടിനും പ്രവർത്തിക്കാനുള്ള അവസരം ലഭിക്കുന്നില്ല. മുൻപിലുള്ള ടെർമിനലിൽ സാധാരണ Ctrl+C SIGINT സൃഷ്ടിക്കുന്നു, കാത്തിരിക്കുന്നത് നിർത്തുന്ന സൂപ്പർവൈസർ സാധാരണയായി SIGKILL-ലേക്ക് ഉയരുന്നു. വ്യത്യാസം പ്രധാനമാണ്, കാരണം രണ്ടാമത്തെ സാഹചര്യം മാത്രമാണ് ഹുക്കുകൾ ഒഴിവാക്കിയതെന്ന് ഉറപ്പാക്കുന്നത്.

screen അല്ലെങ്കിൽ tmux-നുള്ളിൽ പ്രവർത്തിപ്പിക്കുന്നത് Ctrl+C ഏത് സിഗ്നൽ അയക്കുന്നു എന്നത് മാറ്റുന്നില്ല. ടെർമിനൽ സാധാരണയായി എന്ത് ചെയ്യുന്നു എന്നല്ല, പ്രക്രിയ യഥാർത്ഥത്തിൽ എന്ത് ലഭിച്ചു എന്ന് പരിശോധിക്കുക.

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

റിസോൾവർ ആരുടേതാണെന്ന് തീരുമാനിക്കുക

systemd-resolved, resolvconf ശൈലിയിലുള്ള സ്ക്രിപ്റ്റ്, ലളിതമായ ഫയൽ പുനരെഴുത്ത് എന്നിവ മൂന്ന് വ്യത്യസ്ത ഉടമകളാണ്. ആദ്യത്തേത് ഓരോ ലിങ്കിന്റെയും ക്രമീകരണങ്ങൾ മെമ്മറിയിൽ സൂക്ഷിക്കുകയും ഇന്റർഫേസ് അപ്രത്യക്ഷമാകുമ്പോൾ അവ ഉപേക്ഷിക്കുകയും ചെയ്യുന്നു. രണ്ടാമത്തേത് എന്തെങ്കിലും നീക്കം ചെയ്യുന്നത് വരെ നിലനിൽക്കുന്ന രേഖകൾ സൂക്ഷിക്കുന്നു. മൂന്നാമത്തേത് ഒരു ഫയൽ എഴുതുകയും പുനഃസ്ഥാപനം അതെഴുതിയവർക്ക് വിടുകയും ചെയ്യുന്നു.

അറ്റകുറ്റപ്പണി കമാൻഡ് തിരഞ്ഞെടുക്കുന്നതിന് മുൻപ് ഉടമയെ തിരിച്ചറിയുക. ഏതാണ് ഉപയോഗത്തിലുള്ളത് എന്നതിന് അനുസരിച്ച് അതേ ലക്ഷണത്തിന് മൂന്ന് വ്യത്യസ്ത ശരിയായ ഉത്തരങ്ങളുണ്ട്.

NetworkManager കൈകാര്യം ചെയ്യുന്ന VPN ഇതിനകം റിസോൾവർ മാറ്റങ്ങളുടെ ഉടമയായിരിക്കാം. അതിന് മുകളിൽ രണ്ടാമതൊരു സഹായി ചേർത്താൽ ഒരേ ലിങ്കിനായി മത്സരിക്കുന്ന രണ്ട് ഉടമകൾ ഉണ്ടാകും, തോറ്റവരുടെ അവസ്ഥ അടുത്ത വീണ്ടും കണക്ട് ചെയ്യുമ്പോൾ വീണ്ടും പ്രത്യക്ഷപ്പെടും. മാനേജർ ഉത്തരവാദിയാണെങ്കിൽ, ക്രമീകരണം സ്ക്രിപ്റ്റിലല്ല, മാനേജറിൽ തിരുത്തുക.

down ഹുക്കിന് എന്ത് ചെയ്യാനാകും, എന്ത് ചെയ്യാനാകില്ല

സ്ക്രിപ്റ്റ് down TUN/TAP ഉപകരണം അടച്ചതിന് ശേഷം ഒരിക്കൽ പ്രവർത്തിക്കുന്നു. ചേർക്കുമ്പോൾ down-pre ആ ക്രമം മറിച്ചിടുകയും ഉപകരണം ഇപ്പോഴും നിലവിലുള്ളപ്പോൾ സ്ക്രിപ്റ്റ് പ്രവർത്തിപ്പിക്കുകയും ചെയ്യുന്നു, ജീവനുള്ള ലിങ്ക് ആവശ്യമുള്ള സഹായികൾ ഇത് ആവശ്യപ്പെടുന്നു.

ഒരു നിർദ്ദേശവും SIGKILL-ന് ശേഷം ഹുക്ക് പ്രവർത്തിപ്പിക്കുന്നില്ല. അനുമതികളും down-pre വഴി പുനഃസ്ഥാപിക്കപ്പെടുന്നില്ല: ഡീമൺ user അല്ലെങ്കിൽ group നിലയിലേക്ക് താഴുകയോ chroot ലേക്ക് പ്രവേശിക്കുകയോ ചെയ്താൽ, ഹുക്ക് അത് വിടുന്ന പ്രവേശനാനുമതിയോടെ പ്രവർത്തിക്കുന്നു. വിളിക്കപ്പെട്ട ഹുക്ക് എന്നിട്ടും റിസോൾവർ പുതുക്കാൻ പരാജയപ്പെടാം. OpenVPN റഫറൻസ് സിഗ്നലുകളും കോൾബാക്ക് ജീവിതചക്രവും ഉൾക്കൊള്ളുന്നു.

പ്രക്രിയയുടെ എക്സിറ്റ് സ്റ്റാറ്റസിനൊപ്പം ഹുക്കിന്റെ സ്വന്തം പിശകും പരിശോധിക്കുക. കാണാതായ ക്ലീനപ്പും പരാജയപ്പെട്ട ക്ലീനപ്പും റിസോൾവറിൽ ഒരുപോലെയും ലോഗുകളിൽ വ്യത്യസ്തമായും കാണപ്പെടുന്നു.

യഥാർത്ഥത്തിൽ ബാക്കിയുള്ള അവസ്ഥ പരിശോധിക്കുക

systemd-resolved ഉപയോഗിക്കുന്ന സിസ്റ്റത്തിൽ, resolvectl status ഏത് ലിങ്ക് ഇപ്പോഴും VPN DNS സെർവറുകളോ റൂട്ടിംഗ് ഡൊമെയ്നുകളോ വഹിക്കുന്നു എന്ന് കാണിക്കുന്നു. ആ ലിങ്ക് പോയ ഒരു കണക്ഷന്റേതോ ഇപ്പോഴും ഉയർന്നിരിക്കുന്ന മറ്റൊരു ടണലിന്റേതോ ആകാം.

അപ്രത്യക്ഷമാകുന്ന ഇന്റർഫേസ് അതിന്റെ ഓരോ ലിങ്കിന്റെയും കോൺഫിഗറേഷൻ കൂടെ കൊണ്ടുപോകുന്നു, അതിനാൽ ഒഴിവാക്കിയ ഹുക്കിന് വൃത്തിയുള്ള DNS-നൊപ്പം നിലനിൽക്കാം. ലിങ്ക് ഇപ്പോഴും രജിസ്റ്റർ ചെയ്തതും നിർത്തിയ കണക്ഷൻ മാത്രം ഉടമസ്ഥതയിലുള്ളതുമാണെങ്കിൽ, ഉടമയായ മാനേജർ അത് നീക്കം ചെയ്യണം. പഴയ ഒരു സ്ക്രിപ്റ്റ് ആഗോള റിസോൾവർ ഫയൽ വീണ്ടും എഴുതിയിട്ടുണ്ടെങ്കിൽ, പകരം ആ സ്ക്രിപ്റ്റിന്റെ രേഖപ്പെടുത്തിയ പുനഃസ്ഥാപന ഘട്ടം തിരയുക.

മറ്റൊരു ലിങ്ക് മോഷ്ടിക്കാതെ വീണ്ടെടുക്കുക

ഓരോ ലിങ്കിന്റെയും ക്രമീകരണങ്ങൾ നിങ്ങളുടെ കൈകാര്യത്തിലാകുമ്പോൾ, resolvectl revert ലിങ്കിന്റെ പേര് എടുക്കുകയും ആ ഇന്റർഫേസിന്റെ റൺടൈം DNS കോൺഫിഗറേഷൻ മായ്ക്കുകയും ചെയ്യുന്നു. ഇത് പ്രൊഫൈൽ എഡിറ്റിംഗല്ല, റൺടൈം പ്രവർത്തനമാണ്, അതിനാൽ സ്ഥിരമായ കണക്ഷൻ കോൺഫിഗറേഷൻ തൊട്ടുപോകാതെ നിൽക്കുന്നു. തെറ്റായ ലിങ്ക് പേര് നൽകിയാൽ പ്രവർത്തിക്കുന്ന ടണലിന്റെ DNS മായ്ക്കും, അതുകൊണ്ടാണ് പേര് സ്റ്റാറ്റസ് ഔട്ട്പുട്ടിൽ നിന്ന് വരുന്നത്.

എഡിറ്റ് ചെയ്യുന്നതിന് മുൻപ് /etc/resolv.conf ഒരു മാനേജ്ഡ് സിംബോളിക് ലിങ്ക് ആണെന്ന് ഉറപ്പാക്കുക, തുടർന്ന് ക്ലയന്റ് ഒരിക്കൽ കൂടി സാധാരണമായി നിർത്തി DNS വീണ്ടും നോക്കുക. രണ്ടാം നിർത്തൽ വൃത്തിയാക്കുന്നുവെങ്കിൽ, മുൻപത്തെ പ്രശ്നം കോൺഫിഗറേഷനല്ല, നിർബന്ധിത പുറത്തുപോക്കായിരുന്നു.