status=200/CHDIR: systemd ഒരിക്കലും OpenVPN ആരംഭിച്ചില്ല

CHDIR പരാജയം അർത്ഥമാക്കുന്നത് systemd ഒരു ഡയറക്ടറിയിൽ പ്രവേശിക്കാനായില്ല എന്നാണ്, OpenVPN ഒരു പ്രൊഫൈൽ വായിക്കാനായില്ല എന്നല്ല. VPN കോൺഫിഗറേഷൻ തൊടുന്നതിന് മുമ്പ് unit വായിക്കുക.

സേവനം പരാജയപ്പെടുന്നു, ലോഗുകളിൽ spawn ഉം ഒരു ഡയറക്ടറിയും പരാമർശിക്കുന്നു, ആദ്യ പ്രവണത VPN കോൺഫിഗറേഷൻ പരിശോധിക്കുകയാണ്. ആ ഫയലിൽ നിന്ന് ഇതുവരെ ഒന്നും വായിച്ചിട്ടില്ല. systemd പ്രക്രിയ തയ്യാറാക്കുമ്പോൾ, എക്സിക്യൂട്ടബിൾ പ്രവർത്തിക്കുന്നതിന് മുമ്പുതന്നെ പരാജയപ്പെട്ടു, അതിനാൽ ഒരു parser, ഒരു സർട്ടിഫിക്കറ്റ്, ഒരു ദൂരസ്ഥ ഹോസ്റ്റ് എന്നിവയൊന്നും ആലോചിക്കപ്പെട്ടില്ല. സ്റ്റാറ്റസ് കോഡിനെ OpenVPN നെക്കുറിച്ചല്ല, systemd നെക്കുറിച്ചുള്ള പ്രസ്താവനയായി വായിക്കുന്നതാണ് ഇതിനെ ചെറിയ അന്വേഷണമാക്കുന്നത്.

ആപ്ലിക്കേഷന് മുമ്പ് സ്റ്റാറ്റസ് കോഡ് വായിക്കുക

സേവന നാമത്തിന് ശേഷമുള്ള സംഖ്യാ കോഡ് പരാജയപ്പെട്ട ഘട്ടത്തെ സൂചിപ്പിക്കുന്നു. ഡയറക്ടറി പരാജയം CHDIR സ്റ്റാറ്റസായി റിപ്പോർട്ട് ചെയ്യുന്നു, അതേസമയം പ്രവർത്തിപ്പിക്കാനാകാത്ത എക്സിക്യൂട്ടബിൾ തികച്ചും വേറെ കോഡാണ്. രണ്ടും സംഗ്രഹ വരിയിൽ ഒരുപോലെ കാണപ്പെടുന്നു, അവയുടെ കാരണങ്ങളിൽ ഒന്നും പൊതുവായില്ല.

ഈ വ്യത്യാസം പ്രധാനമാണ്, കാരണം പരിഹാരങ്ങൾ വേറെ ഫയലുകളിലാണ്. CHDIR പരാജയം ഒരു പാതയെയും സേവനം അതിനെ എങ്ങനെ കാണുന്നു എന്നതിനെയും സംബന്ധിച്ചതാണ്. Exec പരാജയം ബൈനറി, അതിന്റെ ഇന്റർപ്രിറ്റർ അല്ലെങ്കിൽ ബന്ധമില്ലാത്ത mount എന്നിവയെ സംബന്ധിച്ചതാണ്. VPN ദൂരസ്ഥ പോയിന്റ്, സൈഫർ പട്ടിക, അല്ലെങ്കിൽ സർട്ടിഫിക്കറ്റ് പാത മാറ്റുന്നത് ഇവയൊന്നും പരിഹരിക്കില്ല.

പരാജയം തുടക്കത്തിലാണ്, വിജയകരമായ പ്രവർത്തനത്തിന് ശേഷമല്ല എന്ന് ഉറപ്പാക്കുക. ഇന്നലെ സേവനം പ്രവർത്തിച്ചിരുന്നെങ്കിൽ, ഇപ്പോൾ അതേ ഘട്ടത്തിൽ പരാജയപ്പെടുന്നുവെങ്കിൽ, ഡയറക്ടറി, അതിന്റെ അനുമതികൾ, അല്ലെങ്കിൽ unit തന്നെ എന്തോ മാറിയിരിക്കുന്നു, ആ മാറ്റമാണ് അന്വേഷിക്കേണ്ട തെളിവ്.

എവിടെ ആയിരിക്കണം എന്ന് unit-നോട് ചോദിക്കുക

നിങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്തതായി കരുതുന്ന ഫയലല്ല, പ്രാബല്യത്തിലുള്ള unit വായിക്കുക, കാരണം drop-in ഫയലുകൾ പ്രധാന unit ഒരിക്കലും തിരുത്താതെ പ്രവർത്തന ഡയറക്ടറി അതിലംഘിക്കാം. show-യുടെ ഔട്ട്പുട്ട് ചോദ്യത്തിന് നേരിട്ട് ഉത്തരം നൽകുന്നു:

systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30

upstream സെർവർ ടെംപ്ലേറ്റിന്, പ്രവർത്തന ഡയറക്ടറി സെർവർ കോൺഫിഗറേഷൻ ഡയറക്ടറിയാണ്, ഇൻസ്റ്റാൻസിന്റെ പേര് അതിനുള്ളിലെ പ്രൊഫൈൽ തിരഞ്ഞെടുക്കുന്നു. അതിനാൽ branch എന്ന പേരുള്ള ഇൻസ്റ്റാൻസ് അതേ ഡയറക്ടറിയിൽ സ്വന്തം ഫയൽ പ്രതീക്ഷിക്കുന്നു, മറ്റൊരിടത്ത് വെച്ച പ്രൊഫൈൽ പ്രവർത്തന ഡയറക്ടറി നിബന്ധന പാടെ പാലിക്കുന്നില്ല.

unit ആവശ്യപ്പെടുന്നതും നിലവിലുള്ളതും താരതമ്യം ചെയ്യുക. മുമ്പ് ഉണ്ടായിരുന്ന പാത, ഇപ്പോൾ മറ്റൊരിടത്തേക്ക് ചൂണ്ടുന്ന സിംബോളിക് ലിങ്ക്, അല്ലെങ്കിൽ ഇനി ഒരു ഡയറക്ടറിയുമായി പൊരുത്തപ്പെടാത്ത ഇൻസ്റ്റാൻസ് നാമം—ഇവയെല്ലാം ഈ പരാജയം ഉണ്ടാക്കുന്ന സാധാരണ മാറ്റങ്ങളാണ്.

സേവനം കാണുന്ന രീതിയിൽ പാത പരിശോധിക്കുക

നിങ്ങളുടെ shell-ഉം സേവനവും ഫയൽ സിസ്റ്റത്തിന്റെ ഒരേ കാഴ്ച പങ്കിടുന്നില്ല. കോൺഫിഗർ ചെയ്ത റൂട്ട് ഡയറക്ടറിയോ root image-ഓ unit-നുള്ളിൽ കേവല പാതയുടെ അർത്ഥം മാറ്റുന്നു, ഹോസ്റ്റിൽ വ്യക്തമായി ഉള്ള ഒരു പാത ആ നാമ സ്ഥലത്ത് ഇല്ലായിരിക്കാം. കൈകൊണ്ടുള്ള പരിശോധന വിശ്വസിക്കുന്നതിന് മുമ്പ് unit-ന്റെ ക്രമീകരണങ്ങൾ വായിക്കുക.

അനുമതികൾ പ്രശ്നം വർധിപ്പിക്കുന്നു. സേവനം ഒരു നിർദിഷ്ട ഉപയോക്താവായി പ്രവർത്തിക്കുന്നു, ആ ഉപയോക്താവിന് ലക്ഷ്യത്തിലെത്താൻ ഓരോ മാതൃ ഡയറക്ടറിയിലൂടെയും കടക്കാൻ കഴിയണം, ലക്ഷ്യം മാത്രം വായിക്കാൻ കഴിഞ്ഞാൽ പോരാ. root-ന് വായിക്കാവുന്നതും സേവന ഉപയോക്താവിന് കടക്കാനാകാത്തതുമായ ഡയറക്ടറി കാണാത്ത പാത പോലെ തോന്നുന്ന പരാജയം ഉണ്ടാക്കുന്നു.

namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths

കഠിനീകരണ ക്രമീകരണങ്ങളും ഈ ചിത്രത്തിന്റെ ഭാഗമാണ്. ഹോം ഡയറക്ടറികൾ മറയ്ക്കുന്നതോ ഫയൽ സിസ്റ്റത്തിന്റെ ഒരു ഭാഗം വായന-മാത്രമാക്കുന്നതോ ആയ unit തന്നോട് കോൺഫിഗർ ചെയ്തത് തന്നെ ചെയ്യുന്നു, പ്രവർത്തന ഡയറക്ടറി sandbox ഇപ്പോഴും വെളിപ്പെടുത്തുന്നിടത്ത് ആയിരിക്കണം.

ഉടമയെ ശരിയാക്കുക, പിന്നെ മറ്റൊരു പിശക് പ്രതീക്ഷിക്കുക

ആ കോൺഫിഗറേഷന്റെ ഉടമയിലൂടെ ലേഔട്ടോ unit-ഓ തിരുത്തുക. പ്രൊഫൈൽ പ്രതീക്ഷിത ഡയറക്ടറിയിലേക്ക് മാറ്റുന്നത് ലേഔട്ട് തെറ്റാകുമ്പോൾ ന്യായമായ തിരുത്താണ്, പക്ഷേ പ്രവേശിക്കാനാകാത്ത ഡയറക്ടറിയെ അത് വിശദീകരിക്കുന്നില്ല, അതിനാൽ അതിനെ പൊതുവായ ഉത്തരമായി കാണരുത്.

കോൺഫിഗറേഷൻ ട്രീയിൽ അനുമതികൾ വികസിപ്പിക്കാനോ sandbox നീക്കം ചെയ്യാനോ ഉള്ള ഷോർട്ട്കട്ടിനെ എതിർക്കുക. രണ്ടും ലക്ഷണം മായ്ക്കുന്നു, അതോടൊപ്പം അവിടെ ബോധപൂർവം വെച്ച സംരക്ഷണങ്ങളും നീക്കം ചെയ്യുന്നു, അടുത്ത പരാജയം വ്യാഖ്യാനിക്കാൻ കൂടുതൽ ബുദ്ധിമുട്ടാകും.

ഇൻസ്റ്റാൻസ് വീണ്ടും ആരംഭിച്ച് വിജയം അനുമാനിക്കുന്നതിന് പകരം അടുത്ത സംഭവം വായിക്കുക. അടുത്ത സാദ്ധ്യമായ പിശക് OpenVPN തന്റെ കോൺഫിഗറേഷൻ ഫയൽ തുറക്കാനാകുന്നില്ല എന്നതാണ്, അത് പുരോഗതിയാണ്: പ്രവർത്തന ഡയറക്ടറിയിൽ പ്രവേശിച്ചു, parser ഇപ്പോൾ പ്രവർത്തിക്കുന്നു. അവിടെ നിന്ന് unit-ന്റെ യഥാർത്ഥ ഫയൽ മാപ്പിംഗ് പിന്തുടരുക, നെറ്റ്വർക്ക് പ്രശ്നപരിഹാരത്തിലേക്ക് തിരികെ പോകരുത്.

systemd-ന്റെ എക്സിക്യൂഷൻ റഫറൻസ് പ്രവർത്തന ഡയറക്ടറി റൂട്ട് ഡയറക്ടറികളോടും sandbox-മായും എങ്ങനെ വ്യാഖ്യാനിക്കുന്നു എന്ന് നിർവചിക്കുന്നു. ഓർക്കേണ്ട മാതൃക ലളിതമാണ്: ഓരോ സ്റ്റാറ്റസ് കോഡും വ്യത്യസ്ത ഘട്ടത്തെ സൂചിപ്പിക്കുന്നു, ആപ്ലിക്കേഷന്റെ സ്വന്തം പിശകുകൾ മാത്രമാണ് ആപ്ലിക്കേഷനെ വിവരിക്കുന്നത്.

അനുബന്ധ ലേഖനങ്ങൾ