OpenVPN active (exited) എന്ന് പറയുന്നുണ്ടോ? നിങ്ങൾ ആരംഭിച്ച ഇൻസ്റ്റൻസ് കണ്ടെത്തുക

നിങ്ങൾ ടണൽ പരിശോധിച്ച്, systemctl status openvpn പ്രവർത്തിപ്പിച്ച്, Main PID ഇല്ലാതെയും പ്രോസസ് പട്ടിക ശൂന്യമായും active (exited) കാണുന്നു. സേവനം ആരംഭിച്ച് മരിച്ചു എന്നതാണ് സ്വാഭാവിക വായന, അതിനാൽ നിങ്ങൾ unit തുറന്ന് /bin/true കണ്ടെത്തി പാക്കേജ് തകർന്നതാണെന്ന് തീരുമാനിക്കുന്നു. Debian പാക്കേജിംഗിൽ ആ അവസ്ഥ രൂപകൽപ്പന അനുസരിച്ച് പ്രവർത്തിക്കുന്ന wrapper ആണ്, ടണൽ അത് ആരംഭിക്കുന്ന instance unit-കളിലൊന്നിൽ ജീവിക്കുന്നു. ഏത് ഇൻസ്റ്റൻസ് അത് നിർമ്മിച്ചു എന്ന് സമഗ്ര unit ഒരിക്കലും പറയില്ല.

ഈ unit-ൽ active (exited) യഥാർത്ഥത്തിൽ എന്താണ് അർത്ഥമാക്കുന്നത്

പാക്കേജ് ചെയ്ത unit ഒറ്റത്തവണ ജോലിയാണ്: അതിന്റെ ExecStart /bin/true ആണ്, പൂർത്തിയായ unit-നെ active (exited) ആയി റിപ്പോർട്ട് ചെയ്യുന്നത് RemainAfterExit=yes ആണ്. ആ നിർദ്ദേശം നീക്കിയാൽ അതേ വിജയകരമായ /bin/true ജോലി inactive (dead)-ൽ അവസാനിക്കുന്നു, അതാണ് ആളുകൾ പ്രതീക്ഷിക്കുന്നതും എതിർദിശയിൽ തെറ്റായി വായിക്കുന്നതുമായ അവസ്ഥ. കമാൻഡ് വെറും സ്ഥാനപൂരകമാണ്, unit മറ്റ് unit-കൾ ചെയ്യുന്ന ജോലിയെക്കുറിച്ച് റിപ്പോർട്ട് ചെയ്യുന്നു. ഈ ക്രമീകരണത്തിൽ ഒന്നും തകർന്നിട്ടില്ല, /bin/true മാറ്റുന്നത് ടണലിനെയല്ല, പാക്കേജിംഗ് കരാറിനെയാണ് മാറ്റുന്നത്.

wrapper നിയോഗിക്കുന്നു. പാക്കേജ് കോൺഫിഗറേഷനോ അതിന്റെ systemd ജനറേറ്ററോ നൽകുന്ന instance unit-കൾ ഇത് ആരംഭിക്കുന്നു, അതിനാൽ ശൂന്യമായ പ്രോസസ് പട്ടിക ടണലിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. ഇൻസ്റ്റൻസ് തിരഞ്ഞെടുക്കാത്തപ്പോഴും wrapper വിജയിക്കുന്നു, ഒന്നും ആരംഭിക്കുന്നുമില്ല. അവസ്ഥ wrapper പ്രവർത്തിച്ചോ എന്ന് ഉത്തരം നൽകുന്നു, ടണൽ ഉണ്ടോ എന്നല്ല.

ബ്രാക്കറ്റിലെ വാക്കല്ല, status ഔട്ട്പുട്ടിലെ മൂന്ന് വരികൾ വായിക്കുക. Loaded systemd വായിച്ച unit ഫയലിനെ പേരിടുന്നു, Active അവസാന വിജയകരമായ പ്രവർത്തനത്തിന്റെ സമയമുദ്ര വഹിക്കുന്നു, Main PID ഇല്ലാത്തത് പൂർത്തിയായ ഒറ്റത്തവണ ജോലിയുമായി യോജിക്കുന്നു. ആ മൂന്ന് വരികളാണ് ഈ wrapper-നെ ആരംഭിച്ച് ഒരു സെക്കൻഡ് കഴിഞ്ഞ് വീണ സേവനത്തിൽ നിന്ന് വേർതിരിക്കാനുള്ള വഴിയും.

status വീണ്ടും വായിക്കുന്നതിന് മുമ്പ് unit-കൾ പട്ടികപ്പെടുത്തുക

എന്താണ് പ്രവർത്തിക്കുന്നതെന്ന് ചോദിക്കുന്നതിന് മുമ്പ് systemd-നോട് എന്താണ് ഉള്ളതെന്ന് ചോദിക്കുക. ഇൻസ്റ്റൻസ് സൃഷ്ടിക്കാതെ തന്നെ ടെംപ്ലേറ്റ് ഇൻസ്റ്റാൾ ചെയ്യപ്പെടാം, സൃഷ്ടിച്ച unit മാത്രമാണ് ടണൽ വഹിക്കുന്നത്. ലോഡ് ചെയ്ത സെറ്റിൽ നിന്ന് ആരംഭിക്കുക:

systemctl list-units 'openvpn*'

ആ പട്ടിക systemd ഈ നിമിഷം ലോഡ് ചെയ്തതാണ്, ടണൽ പട്ടികയോട് ഏറ്റവും അടുത്തത് അതാണ്. ഇൻസ്റ്റാൾ ചെയ്ത unit ഫയലുകൾ മറ്റൊരു ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു, ഒന്നും സൃഷ്ടിക്കാത്തപ്പോഴും ആ പട്ടിക ടെംപ്ലേറ്റ് കാണിക്കുന്നു:

systemctl list-unit-files 'openvpn*'

രണ്ട് പട്ടികകളും ഒരുമിച്ച് വായിക്കുക, രണ്ടാമത്തേതിലെ ടെംപ്ലേറ്റും ആദ്യത്തേതിലെ ഇൻസ്റ്റൻസും വ്യത്യസ്ത ഉത്തരങ്ങളാണ്. നിലവിലുള്ള ടെംപ്ലേറ്റും പ്രവർത്തിക്കുന്ന ഇൻസ്റ്റൻസും ഒരേ വസ്തുതയല്ല, രണ്ടാമത്തേത് മാത്രമാണ് ടണൽ അർത്ഥമാക്കുന്നത്. പാക്കേജ് ലേഔട്ടുകൾ വിതരണങ്ങൾക്കും OpenVPN പതിപ്പുകൾക്കും ഇടയിൽ വ്യത്യാസപ്പെടുന്നു. പഴയ openvpn@ ടെംപ്ലേറ്റ്, വേർതിരിച്ച client-ഉം server-ഉം ജോടി, വിതരണ wrapper എന്നിവയെല്ലാം അവയുടെ പാക്കേജിംഗിൽ സാധുവായിരിക്കാം.

നിങ്ങൾ കണ്ട ട്യൂട്ടോറിയലിനല്ല, നിങ്ങളുടെ യന്ത്രത്തിന് അനുയോജ്യമാക്കുക. മറ്റൊരാളുടെ ഔട്ട്പുട്ടിലെ ഇൻസ്റ്റൻസ് നാമം office ആകാം, നിങ്ങളുടേത് home അല്ലെങ്കിൽ work ആകാം. കൈമാറ്റം ചെയ്യുന്നത് രീതിയാണ്, സ്ട്രിംഗ് അല്ല.

ഇൻസ്റ്റൻസ് നാമത്തെ അത് വായിക്കുന്ന ഫയൽ വരെ പിന്തുടരുക

upstream client ടെംപ്ലേറ്റിൽ unit-ന്റെ പ്രവർത്തന ഡയറക്ടറി /etc/openvpn/client ആണ്, അതിന്റെ കമാൻഡ് അവിടെ നിന്ന് %i.conf എടുക്കുന്നു, അതിനാൽ openvpn-client@office /etc/openvpn/client/office.conf വായിക്കുന്നു. ഉദാഹരണത്തെ വിശ്വസിക്കുന്നതിന് പകരം ഇൻസ്റ്റാൾ ചെയ്ത unit-ൽ ആ മാപ്പിംഗ് സ്ഥിരീകരിക്കുക, നിങ്ങളുടെ ടെംപ്ലേറ്റ് പഴയതോ വിതരണത്തിന്റെ പുനരെഴുത്തോ ആകാം:

systemctl cat [email protected]

ആ ഔട്ട്പുട്ടിന്റെ അടിയിൽ കാണുന്ന drop-in-കൾ വായിക്കുക, .d/-ന് കീഴിലുള്ള ഫയൽ ExecStart, പ്രവർത്തന ഡയറക്ടറി അല്ലെങ്കിൽ കോൺഫിഗറേഷൻ പാത്ത് മാറ്റാം. നിങ്ങൾ office.ovpn എന്ന് ഡൗൺലോഡ് ചെയ്ത പ്രൊഫൈൽ ഇൻസ്റ്റൻസ് തുറക്കുന്ന ഫയൽ അല്ല. ഈ വിടവാണ് നിങ്ങൾ ഒരിക്കലും തിരുത്തിയിട്ടില്ലാത്ത ഒരു പാത്ത് പിശക് പേരിടുന്നതിന്റെ സാധാരണ കാരണം.

പ്രൊഫൈലിനുള്ളിലെ ആപേക്ഷിക പാത്തുകളാണ് അടുത്ത കെണി. ca, cert, key റഫറൻസുകൾ ആപേക്ഷികമായി നിർത്തി പ്രധാന ഫയൽ നീക്കിയാൽ, കാണാത്ത ഫയൽ പിശകിനെ മറ്റൊരു കാണാത്ത ഫയൽ പിശകിനാൽ മാറ്റുന്നു. രണ്ടാമത്തേത് ഉണ്ടെന്ന് നിങ്ങൾക്ക് ഉറപ്പുള്ള ഒരു ഫയലിനെ ചൂണ്ടുന്നു, അതിനാൽ ഫയൽ നാമത്തേക്കാൾ പ്രൊഫൈൽ ഡയറക്ടറിയാണ് പ്രധാനം.

അത് ആരംഭിച്ച്, പിന്നീട് ആ ഇൻസ്റ്റൻസിന്റെ ജേണൽ വായിക്കുക

നിങ്ങൾ ഇപ്പോൾ പരിശോധിച്ച ഇൻസ്റ്റൻസ് ആരംഭിക്കുക, സമഗ്ര unit-ന്റെ ലോഗിൽ ടണലിന്റെ പിശകുകൾ ഉണ്ടാകില്ല. പിന്നീട് ഈ ബൂട്ടിന്റെ ജേണൽ വായിച്ച് അതേ ക്രമത്തിൽ കോൺഫിഗറേഷൻ പിശക്, ഫയൽ പ്രവേശന പിശക്, കണക്ഷൻ പിശക് എന്നിവ തിരയുക, ഓരോന്നും ആരംഭത്തിന്റെ വ്യത്യസ്ത ഘട്ടത്തിൽ പരാജയപ്പെടുന്നു.

sudo systemctl start [email protected]
journalctl -u [email protected] -b

ആരംഭിക്കുന്നതും പ്രവർത്തനക്ഷമമാക്കുന്നതും വ്യത്യസ്ത തീരുമാനങ്ങളാണ്: start unit ഇപ്പോൾ പ്രവർത്തിപ്പിക്കുന്നു, enable അടുത്ത ബൂട്ട് ഒരുക്കുന്നു, enable --now രണ്ടും ഒരു ഘട്ടത്തിൽ ചെയ്യുന്നു. daemon-reload unit നിർവചനങ്ങൾ വീണ്ടും വായിക്കുന്നു, പ്രവർത്തിക്കുന്ന പ്രോസസ് പുനരാരംഭിക്കുന്നില്ല, തിരുത്തിയ പ്രൊഫൈൽ പ്രയോഗിക്കുന്നുമില്ല. പ്രൊഫൈൽ മാറ്റിയ ശേഷം ഇൻസ്റ്റൻസ് പുനരാരംഭിക്കുക, ഫയൽ വീണ്ടും വായിക്കുന്നത് അതാണ്.

അതേ ടണലിൽ രണ്ടാമതൊരു മാനേജർ ഇടരുത്

NetworkManager-ഉം OpenVPN 3 സെഷൻ മാനേജർമാരും സ്വന്തം കണക്ഷൻ അവസ്ഥ കൈവശം വയ്ക്കുന്നു, അവയിലൊന്നിന് അടുത്ത് systemd ഇൻസ്റ്റൻസ് ഇട്ടാൽ അതേ ടണലിൽ രണ്ട് ഉടമകളാകും. ടണൽ ഉയർന്ന് ഏതാനും സെക്കൻഡുകൾ കഴിഞ്ഞ് മാറ്റിസ്ഥാപിക്കപ്പെടുന്നതോ, നിർത്തിയിട്ടിരിക്കാൻ വിസമ്മതിക്കുന്നതോ ആണ് ലക്ഷണം. നിങ്ങളുടെ വിതരണം ഡെസ്ക്ടോപ്പിനായി രേഖപ്പെടുത്തുന്ന മാനേജർ തിരഞ്ഞെടുത്ത്, സർവറിൽ systemd ബോധപൂർവം ഉപയോഗിക്കുക.

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

യഥാർത്ഥ ചോദ്യത്തിന് ഇൻസ്റ്റൻസിന്റെ പേര്, അത് വായിച്ച ഫയൽ, പരാജയപ്പെട്ട ജേണൽ വരി എന്നിവ ഉപയോഗിച്ച് ഉത്തരം നൽകുക. systemd സംയോജനത്തെക്കുറിച്ചുള്ള OpenVPN-ന്റെ കുറിപ്പുകൾ ടെംപ്ലേറ്റ് ലേഔട്ടും ഇൻസ്റ്റൻസ് നാമം പരിഹരിക്കുന്ന ഫയൽ മാപ്പിംഗും വിവരിക്കുന്നു.