എന്തോ ആവർത്തിച്ച് ഒരു OpenVPN യൂണിറ്റ് ആരംഭിക്കുന്നു: ഉറവിടം കണ്ടെത്തുക

OpenVPN ഇൻസ്റ്റൻസ് ബൂട്ട് സമയത്ത് നിങ്ങൾക്ക് അറിയാത്ത പേരിൽ വരുന്നു, അത് നിർത്തുന്നത് അടുത്ത റീബൂട്ട് വരെ പ്രവർത്തിക്കുന്നു. ഈ മാതൃക അർത്ഥമാക്കുന്നത് നിങ്ങൾ പ്രക്രിയ നീക്കം ചെയ്തു എന്നാണ്, സജീവമാക്കൽ അല്ല. ഇവ രണ്ട് വ്യത്യസ്ത വസ്തുക്കളാണ്, അവയിൽ ഒന്ന് മാത്രമേ സ്റ്റാറ്റസ് സ്ക്രീനിൽ കാണുന്നുള്ളൂ. സജീവമാക്കൽ കണ്ടെത്താൻ നാല് വായന-മാത്രം കമാൻഡുകളും ഒരു തീരുമാനവും ആവശ്യമാണ്.

ആദ്യം കൃത്യമായ യൂണിറ്റ് പേരിടുക

പ്രൊഫൈൽ ഫയൽ പേരിന് പകരം journalലെ യൂണിറ്റ് പേരിൽ നിന്ന് ആരംഭിക്കുക. ഇൻസ്റ്റൻസിന്റെ പേര് openvpn@, openvpn-client@, openvpn-server@ അല്ലെങ്കിൽ വിതരണ-നിർദ്ദിഷ്ടമായത് ആകാം, പേര് ഊഹിക്കുന്നത് നിങ്ങളെ തെറ്റായ ടെംപ്ലേറ്റിലേക്ക് നയിക്കുന്നു. സ്റ്റാറ്റസ് ഔട്ട്പുട്ട് യഥാർത്ഥത്തിൽ പ്രവർത്തിച്ച യൂണിറ്റ് പേരിടുന്നു, ഇവിടെ പ്രധാനമായ ഒരേയൊരു പേര് അതാണ്. ഏതെങ്കിലും പ്രത്യയം ഉൾപ്പെടെ അത് കൃത്യമായി പകർത്തുക.

ഇനിപ്പറയുന്ന കമാൻഡുകൾ ഒന്നും മാറ്റാതെ ആ യൂണിറ്റ് വിവരിക്കുന്നു. systemctl show ഫ്രാഗ്മെന്റ് പാത, ഉറവിട പാത, യൂണിറ്റ് ഫയൽ അവസ്ഥ, ഏതെങ്കിലും drop-in, അത് സജീവമാക്കിയത് എന്താണ് എന്നിവ റിപ്പോർട്ട് ചെയ്യുന്നു. list-dependencies --reverse ഏത് ലോഡ് ചെയ്ത യൂണിറ്റുകൾ അതിലേക്ക് ചൂണ്ടുന്നു എന്ന് കാണിക്കുന്നു. രണ്ടും വായന-മാത്രം, അതിനാൽ സിദ്ധാന്തം രൂപപ്പെടുത്തുന്നതിന് മുമ്പ് അവ പ്രവർത്തിപ്പിക്കുക.

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

ഫയലിന്റെ പേര് അറിയാൻ ടെംപ്ലേറ്റ് വായിക്കുക

ഇൻസ്റ്റൻസ് യൂണിറ്റ് ടെംപ്ലേറ്റിന്റെ വിപുലീകരണമാണ്, ടെംപ്ലേറ്റ് ഏത് കോൺഫിഗറേഷൻ ഫയൽ വായിക്കുന്നു എന്ന് തീരുമാനിക്കുന്നു. ഇൻസ്റ്റൻസിന് നിർദ്ദിഷ്ടമായ പ്ലേസ്ഹോൾഡറിൽ അവസാനിക്കുന്ന കമാൻഡ് ലൈൻ ഇൻസ്റ്റൻസ് പേരും പ്രത്യയവുമായി പരിഹരിക്കുന്നു. പ്രത്യയം .conf ആണെങ്കിൽ ഇൻസ്റ്റൻസിന്റെ പേര് old ആണെങ്കിൽ, ഫയൽ old.conf ആണ്. ഇൻസ്റ്റൻസിന് old.conf എന്ന് പേരിട്ടാൽ, അതേ ടെംപ്ലേറ്റ് old.conf.conf ആവശ്യപ്പെടുന്നു.

ആ വിശദാംശം പകർപ്പുകളുടെ ഒരു വിഭാഗം വിശദീകരിക്കുന്നു. ആരോ തെറ്റായ പേരിൽ രണ്ടാമത്തെ ഇൻസ്റ്റൻസ് ചേർക്കുന്നു, ആദ്യത്തേത് പ്രവർത്തിക്കുന്നു, ഹോസ്റ്റ് രണ്ട് ടണലുകളും ഒരു ആശയക്കുഴപ്പമുള്ള ലോഗും സഹിതം അവസാനിക്കുന്നു.

നിങ്ങൾ എഡിറ്റ് ചെയ്തതായി ഓർക്കുന്ന ഫയലിന് പകരം പ്രാബല്യത്തിലുള്ള ടെംപ്ലേറ്റ് വായിക്കുക. Drop-in കമാൻഡ് ലൈൻ മാറ്റിസ്ഥാപിക്കാം, ബൂട്ടിൽ പ്രവർത്തിക്കുന്നത് ആ പകരമാണ്.

അത് ബൂട്ട് ഇടപാടിലേക്ക് എങ്ങനെ പ്രവേശിക്കുന്നു എന്ന് കണ്ടെത്തുക

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

/run/systemd/generator ക്ക് കീഴിൽ സൃഷ്ടിച്ച ഔട്ട്പുട്ട് ഒരു ഉൽപ്പന്നമാണ്, ഉറവിടമല്ല. അത് എഡിറ്റ് ചെയ്യുന്നത് അടുത്ത ജനറേഷൻ വരെ മാത്രം നിലനിൽക്കുന്നു, അതിനാൽ അവിടെ പ്രയോഗിച്ച തിരുത്ത് വിജയകരമായി തോന്നി പിന്നീട് തിരികെ വരുന്നു.

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

സജീവമാക്കൽ നീക്കം ചെയ്യുക, പ്രക്രിയ മാത്രമല്ല

ഇൻസ്റ്റൻസ് നേരിട്ട് സജീവവും യഥാർത്ഥത്തിൽ കാലഹരണപ്പെട്ടതുമാണെങ്കിൽ, systemctl disable --now അത് നിർത്തി ഒരു ഘട്ടത്തിൽ ബൂട്ട് ലിങ്ക് നീക്കം ചെയ്യുന്നു. ഈ ടണൽ ഹോസ്റ്റിലേക്കുള്ള നിങ്ങളുടെ ഏക അഡ്മിൻ പാതയല്ലെന്ന് ആദ്യം പരിശോധിക്കുക. കമാൻഡ് ജീവിതചക്രത്തിന്റെ ഉദാഹരണമാണ്, യന്ത്രത്തിലെ ഓരോ VPN ഉം നിർത്താനുള്ള നിർദ്ദേശമല്ല. പരിശോധന കമാൻഡിന് മുമ്പ് നടത്തുക, പിന്നീടല്ല.

രണ്ട് പകുതികളും വേർതിരിക്കാവുന്നതാണ്, പലപ്പോഴും ആശയക്കുഴപ്പത്തിലാകുന്നു. പ്രവർത്തനരഹിതമാക്കുന്നത് പ്രവർത്തിക്കുന്ന സേവനത്തെ നിർത്തുന്നില്ല, നിർത്തുന്നത് സജീവമാക്കൽ നീക്കം ചെയ്യുന്നില്ല, അതിനാൽ ഭാഗിക കമാൻഡ് ബൂട്ടിൽ തിരികെ വരുന്ന പ്രശ്നം വിശദീകരിക്കുന്നു.

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

സ്റ്റാറ്റസ് സ്ക്രീനിനാൽ അല്ല, റീബൂട്ടിലൂടെ പരിശോധിക്കുക

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

പഴയ പ്രൊഫൈൽ അതിന്റെ ഉടമസ്ഥാവകാശം മനസ്സിലാകുന്നതുവരെ സൂക്ഷിച്ച്, പിന്നീട് ഉദ്ദേശിച്ച പ്രക്രിയിലൂടെ വിരമിക്കുക. വിജയം എന്നത് അസാന്നിധ്യമായ ഒരു യൂണിറ്റും പ്രവർത്തിക്കുന്ന ആക്സസ് പാതയുമാണ്, ഒരു സ്ക്രീനിൽ നിന്ന് കാണാതായ പരാജയപ്പെട്ട യൂണിറ്റല്ല.