ഏത് openvpn ബൈനറിയാണ് പ്രവർത്തിക്കുന്നത്? ലോഞ്ച് പാത്ത് പരിശോധിക്കുക

ഒരു പഴയ പരിഹാരം OpenVPN-ന്റെ എക്സിക്യൂട്ടബിൾ ഫയൽ മറ്റൊരിടത്തേക്ക് മാറ്റി, യഥാർത്ഥ പാത്തിൽ ഒരു shell റാപ്പർ വിട്ടു. മാസങ്ങൾക്കുശേഷം ഒരു അപ്ഗ്രേഡ് വരുന്നു, ആ പരിഹാരം പിൻവലിക്കുന്നത് ഏത് ഫയലാണ് യഥാർത്ഥത്തിൽ ക്ലയന്റ് എന്ന ഊഹക്കച്ചവടമായി മാറുന്നു. കമാൻഡ് നാമം, സേവനത്തിൽ കോൺഫിഗർ ചെയ്ത എക്സിക്യൂട്ടബിൾ, പാക്കേജിന്റെ സ്വന്തം ഫയൽ ലിസ്റ്റ് എന്നിവ എല്ലാം വ്യത്യസ്ത വസ്തുക്കളിലേക്ക് ചൂണ്ടാം, മറ്റുള്ളവയില്ലാതെ ഒന്ന് നന്നാക്കുന്നത് ശരിയായതായി തോന്നുന്നതും മോശമായി പെരുമാറുന്നതുമായ ഒരു ഹോസ്റ്റ് സൃഷ്ടിക്കുന്നു.

സേവനം ആരംഭിക്കുന്ന പാത്തിൽ നിന്ന് തുടങ്ങുക

ടെർമിനലും systemd യൂണിറ്റും എക്സിക്യൂട്ടബിളുകൾ ഒരേ രീതിയിൽ പരിഹരിക്കുന്നില്ല. shell PATH-ൽ തിരയുന്നു; യൂണിറ്റ് ഒരു പാത്ത് പേരിടുന്നു, drop-in ഓവർറൈഡുകൾക്ക് നിങ്ങൾ വായിക്കുന്ന ഫയൽ തൊടാതെ അത് മാറ്റാൻ കഴിയും. ആ വ്യത്യാസമാണ് ഈ ജോലിയിലെ മിക്ക ആശയക്കുഴപ്പവും വിശദീകരിക്കുന്നത്. നിങ്ങളുടെ അറ്റകുറ്റപ്പണി ഏത് ഫയലിനെ ലക്ഷ്യമിടണം എന്നും അത് തീരുമാനിക്കുന്നു.

യൂണിറ്റിനോട് എന്താണ് പ്രവർത്തിപ്പിക്കുന്നതെന്ന് ചോദിക്കുക, അത് മാറ്റുന്ന drop-in-കൾ ഉൾപ്പെടെ, അധികാരമുള്ളതായി കരുതുന്ന ഭാഗത്തിനുപകരം ലഭിക്കുന്ന ExecStart വരി വായിക്കുക. പിന്നീട് ആ പാത്ത് ഏതെങ്കിലും സിംബോളിക് ലിങ്കിലൂടെ അന്തിമ ഫയൽവരെ പിന്തുടരുക. ഒരു മറഞ്ഞ ഡയറക്ടറിയിലേക്ക് exec-യോടെ അവസാനിക്കുന്ന റാപ്പർ ഈ പഴയ പരിഹാരങ്ങളുടെ സാധാരണ ക്രമീകരണമാണ്.

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് പരിഹരിച്ച പാത്ത് എഴുതിവയ്ക്കുക.

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

കമാൻഡ് നാമം സേവന പാത്തുമായി താരതമ്യം ചെയ്യുക

രണ്ട് ഉത്തരങ്ങളും പലപ്പോഴും വ്യത്യസ്തമാണ്, ആ വ്യത്യാസം സ്വയമേവ ഒരു തകരാറല്ല. NetworkManager പ്ലഗിൻ അതിന്റെ സ്വന്തം പാത്ത് ആരംഭിക്കാം, ഒരു കണ്ടെയ്നർ മറ്റൊന്ന് മൗണ്ട് ചെയ്യാം.

ട്രാഫിക് ശുശ്രൂഷിക്കുന്ന പ്രക്രിയ ഏത് ഉടമ ആരംഭിക്കുന്നു എന്ന് അറിയുന്നതാണ് പ്രധാനം. യൂണിറ്റ് /usr/local/sbin/openvpn-wrapper പ്രവർത്തിപ്പിക്കുമ്പോൾ നിങ്ങളുടെ shell /usr/sbin/openvpn പരിഹരിക്കുന്നുവെങ്കിൽ, രണ്ടാമത്തെ ഫയൽ നന്നാക്കുന്നത് സേവനത്തിൽ ഒന്നും മാറ്റുന്നില്ല.

ഓരോ സ്ഥാനാർത്ഥിയും ഏത് പാക്കേജിന്റെതാണെന്ന് ചോദിക്കുക, തുടർന്ന് ഫയൽ പാക്കേജ്-നിയന്ത്രിതമാണോ പ്രാദേശികമായി സ്ഥാപിച്ചതാണോ എന്ന് തീരുമാനിക്കുക. ഉടമസ്ഥ പാക്കേജില്ലാത്ത ഫയൽ ആരോ ബോധപൂർവം അവിടെ വച്ചതാണ്, അത് ഇല്ലാതാക്കുന്നതിന് മുമ്പ് പേര്, ഉടമ, കാരണം എന്നിവയർഹിക്കുന്നു. വിപരീത തെറ്റും സാധാരണമാണ്: ഒരു ഫോറം പോസ്റ്റ് അതേ ഡയറക്ടറി ഉപയോഗിച്ചതിനാൽ പഴയ സംഭരിച്ച ബൈനറി ഉപയോഗിച്ച് പാക്കേജ് ഫയൽ മേലെഴുതുന്നത്.

പാക്കേജ് ഫയലുകളെക്കുറിച്ച് പാക്കേജ് ഡാറ്റാബേസിനെ സംസാരിക്കാൻ അനുവദിക്കുക

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

പരിശോധന പ്രവർത്തിപ്പിച്ച് ശൂന്യമായ ഫലത്തെ എന്തിന്റെയും തെളിവായി കണക്കാക്കുന്നതിനുപകരം ഔട്ട്പുട്ട് വായിക്കുക.

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

dpkg കൈപ്പുസ്തകം രേഖപ്പെടുത്തുന്നതനുസരിച്ച്, പരിശോധന ഇൻസ്റ്റാൾ ചെയ്ത ഫയലുകളെ പ്രാദേശികമായി രേഖപ്പെടുത്തിയ മെറ്റാഡാറ്റയുമായി താരതമ്യം ചെയ്യുന്നു, ഉള്ളിടത്ത് സംഭരിച്ച ചെക്ക്സമ്മുകൾ ഉപയോഗിക്കുന്നു. മാറിയ പാക്കേജ് ഫയൽ അത് ശ്രദ്ധിക്കുന്നു, പകരം മറ്റൊരു ബൈനറി പ്രവർത്തിപ്പിക്കുന്നുണ്ടോ എന്ന് അതിന് പറയാനാകില്ല.

നന്നാക്കുന്നതിന് മുമ്പ് അവസ്ഥ രേഖപ്പെടുത്തുക

പരിഹരിച്ച ലോഞ്ച് പാത്ത്, ഫയലിന്റെ പാക്കേജ് ബന്ധം, റാപ്പറിന്റെ സ്ഥാനം, അത് കൊണ്ടുവന്ന മാറ്റരേഖ എന്നിവ ശേഖരിക്കുക. പിന്നീട് ആവശ്യമാകുന്ന ഇന്റഗ്രേഷൻ ജോലി റാപ്പറിലുണ്ടെങ്കിൽ അത് സുരക്ഷിതമായ സ്ഥലത്തേക്ക് പകർത്തുക.

വായിക്കുന്നതിന് മുമ്പ് റാപ്പറിന്റെ ഉള്ളടക്കം ഒരു സഹായ ത്രെഡിൽ പേസ്റ്റ് ചെയ്യരുത്, കാരണം ഈ സ്ക്രിപ്റ്റുകൾ ചിലപ്പോൾ ക്രെഡൻഷ്യലുകളോ ഗേറ്റ്വേ വിവരങ്ങളോ വഹിക്കുന്നു.

ജോലി ചെയ്യുമ്പോൾ സേവനം ഏത് പ്രൊഫൈലുകൾ ഉപയോഗിക്കുന്നു, ആരാണ് കണക്ട് ചെയ്തിരിക്കുന്നത് എന്നിവ രേഖപ്പെടുത്തുക, കാരണം ടണൽ പുനരാരംഭിക്കുന്നത് ഹോസ്റ്റ് നിയന്ത്രിക്കുന്ന സെഷൻ തടസ്സപ്പെടുത്തിയേക്കാം.

ലോഞ്ച് സ്ഥിരീകരിച്ച് റാപ്പർ നീക്കം ചെയ്യുക

നന്നാക്കിയതിന് ശേഷം സേവനം ആരംഭിച്ച്, നിങ്ങൾ ഉദ്ദേശിച്ച പാത്തിൽ പ്രക്രിയ പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക. കൈകൊണ്ട് പ്രവർത്തിപ്പിച്ച പതിപ്പ് അന്വേഷണം ഫയൽ പ്രവർത്തിക്കുന്നുവെന്ന് തെളിയിക്കുന്നു; യൂണിറ്റ് അത് ഉപയോഗിക്കുന്നുവെന്ന് തെളിയിക്കുന്നില്ല.

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

സ്ഥാനഭ്രംശം സംഭവിച്ച റാപ്പർ അത് കൊണ്ടുവന്ന അതേ മാറ്റരേഖയിലൂടെ നീക്കം ചെയ്യുക. പൂർത്തിയായ അറ്റകുറ്റപ്പണി ഏത് എക്സിക്യൂട്ടബിൾ പ്രവർത്തിക്കുന്നു, എന്തുകൊണ്ട്, ഏത് ഫയൽ നീക്കം ചെയ്തു എന്നിവ പറയുന്നു; ഫയൽ നാമം പുനഃസ്ഥാപിച്ച് പ്രതീക്ഷിക്കുന്നത് അതല്ല.