OpenVPN പ്രൊഫൈൽ ലോഡ് ചെയ്യുന്നുണ്ടെങ്കിലും ca.crt കണ്ടെത്തുന്നില്ല

സേവനം ആരംഭിക്കുന്നു, പ്രൊഫൈൽ ഒരു പരാതിയുമില്ലാതെ വായിക്കുന്നു, പിന്നെ ബന്ധമില്ലാത്തതുപോലെ തോന്നുന്ന ഒരു വരിയിൽ മരിക്കുന്നു: അതിന് ca.crt തുറക്കാനാകുന്നില്ല. സർട്ടിഫിക്കറ്റിൽ ഒന്നും മാറിയിട്ടില്ല, unit ഫയലിലെ പ്രൊഫൈൽ പാത പൂർണ്ണമാണ്. ആ സംയോജനമാണ് സൂചന. നിങ്ങൾ നൽകിയ പാത ഒരു ഫയൽ കണ്ടെത്തുന്നു, ആ ഫയലിനുള്ളിലെ പേരുകൾ തികച്ചും വേറെയെവിടെയോ പരിഹരിക്കപ്പെടുന്നു, അതിനാൽ പൂർണ്ണമായി യോഗ്യമെന്നു തോന്നുന്ന ലോഞ്ച് പോലും ആരും ഉദ്ദേശിക്കാത്ത ഒരു ഡയറക്ടറിയിൽ നിന്ന് അതിന്റെ കീകൾ വായിച്ചേക്കാം.

പരാജയത്തിന് കുറച്ച് കാരണങ്ങളേയുള്ളൂ, അവ ക്രമത്തിൽ വേർതിരിക്കുന്നത് ഉചിതമാണ്: പ്രക്രിയയ്ക്ക് യഥാർത്ഥത്തിൽ ഉണ്ടായിരുന്ന അടിസ്ഥാന ഡയറക്ടറി, സേവനത്തിന്റെ ലോഞ്ച് സന്ദർഭം, പാത ശരിയായതിന് ശേഷം ഫയലിനു ചുറ്റുമുള്ള അനുമതികൾ അല്ലെങ്കിൽ സാൻഡ്ബോക്സ്. ഓരോന്നും വ്യത്യസ്ത അടയാളം അവശേഷിപ്പിക്കുന്നു — unit-ൽ, പ്രക്രിയയിൽ, ഫയൽസിസ്റ്റത്തിൽ.

പ്രൊഫൈൽ പാത അടിസ്ഥാന ഡയറക്ടറിയല്ല

/tmp-ൽ ആരംഭിച്ച് /etc/vpn/prod/tenant-a.ovpn സ്വീകരിക്കുന്ന ഒരു പ്രക്രിയ സങ്കൽപ്പിക്കുക. ആ പ്രൊഫൈലിനുള്ളിൽ, ca ca.crt എന്ന വരി ഒരു ആപേക്ഷിക പാത പറയുന്നു. പ്രൊഫൈൽ കണ്ടെത്തിയ ആർഗ്യുമെന്റിൽ ഒന്നും ആ പേര് മാറ്റിയെഴുതുന്നില്ല, അതിനാൽ പ്രക്രിയ /tmp/ca.crt തിരയുന്നു, കാണാത്ത ഫയൽ റിപ്പോർട്ട് ചെയ്യുന്നു.

ആശയക്കുഴപ്പം പിശകുകളുടെ ക്രമത്തിലാണ്. OpenVPN ആദ്യം കോൺഫിഗറേഷൻ പാഴ്സ് ചെയ്ത്, പരാമർശിച്ച ഫയലുകളിൽ എത്തുമ്പോൾ അവ തുറക്കുന്നു, അതിനാൽ പ്രൊഫൈലിലെ ടൈപ്പോ ഏതെങ്കിലും കീ തൊടുന്നതിന് മുമ്പ് റിപ്പോർട്ട് ചെയ്യപ്പെടുന്നു, കാണാത്ത സർട്ടിഫിക്കറ്റ് പാഴ്സിംഗ് അവിടെ എത്തുമ്പോൾ മാത്രം പ്രത്യക്ഷപ്പെടുന്നു. അതിനാൽ ലോഡ് ചെയ്യുന്ന പ്രൊഫൈൽ വാക്യഘടന ശരിയെന്നതിന്റെ തെളിവാണ്, അത് പേര് പറയുന്ന ഫയലുകൾ കണ്ടെത്തിയെന്നതിന്റെയല്ല.

മാനുവൽ എന്ത് വേർതിരിക്കുന്നു: --config, --cd

OpenVPN 2.6 മാനുവൽ രണ്ട് വ്യത്യസ്ത ഓപ്ഷനുകൾ വിവരിക്കുന്നു. ഒന്ന് ഒരു കോൺഫിഗറേഷൻ ഫയൽ ലോഡ് ചെയ്യുന്നു. മറ്റൊന്ന് കോൺഫിഗറേഷൻ, കീ, സ്ക്രിപ്റ്റ്, മറ്റ് ഫയലുകൾ വായിക്കുന്നതിന് മുമ്പ് പ്രക്രിയയുടെ ഡയറക്ടറി മാറ്റുന്നു, നിലവിലെ ഡയറക്ടറിയെ പരാമർശിക്കാത്ത ഒരു പൂർണ്ണ ഡയറക്ടറി ആവശ്യപ്പെടുന്നു.

openvpn --cd /etc/vpn/prod --config tenant-a.ovpn

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

ഏത് തിരഞ്ഞെടുത്താലും ആദ്യ പരാജയത്തിനു പകരം മുഴുവൻ ശൃംഖലയും പരിശോധിക്കുക. ഒരു പ്രൊഫൈൽ മറ്റൊരു കോൺഫിഗറേഷൻ ഫയൽ ഉൾപ്പെടുത്തിയേക്കാം, ഉൾപ്പെടുത്തിയ ഫയലിന്റെ ആപേക്ഷിക നാമങ്ങൾ അവ ഉൾപ്പെടുത്തിയ ഫയലിന്റെ ഡയറക്ടറിയല്ല, അതേ പ്രക്രിയ ഡയറക്ടറിയുടെ അടിസ്ഥാനത്തിൽ പരിഹരിക്കപ്പെടുന്നു. ലോഗ് പാതകൾ, ഓതന്റിക്കേഷൻ ഫയലുകൾ, സഹായ സ്ക്രിപ്റ്റുകൾ എന്നിവ അതേ നിയമം പിന്തുടരുന്നു.

സേവനം മറ്റൊരിടത്ത് ആരംഭിക്കുന്നു

പ്രൊഫൈൽ ഡയറക്ടറിയിലെ ഇന്ററാക്ടീവ് ഷെൽ പാക്കേജ് ചെയ്ത unit-നെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. മാനേജർമാർ അവരുടേതായ വർക്കിംഗ് ഡയറക്ടറി സജ്ജമാക്കുന്നു, റാപ്പർ സ്ക്രിപ്റ്റ് ബൈനറി പ്രവർത്തിക്കുന്നതിന് മുമ്പ് അത് വീണ്ടും മാറ്റിയേക്കാം. പരാജയപ്പെടുന്ന unit മാത്രമാണ് യുക്തി ചെയ്യാൻ യോഗ്യമായ ഏക ലോഞ്ച്.

systemctl show -p WorkingDirectory -p ExecStart --value openvpn@tenant-a
ls -l /proc/$(pgrep -n openvpn)/cwd

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

തിരയലിന് ശേഷം: അനുമതികൾ, chroot, സാൻഡ്ബോക്സ്

ശരിയായ അടിസ്ഥാന ഡയറക്ടറിയും അതേ സന്ദേശം നൽകിയേക്കാം, കാരണം പരിഹരിക്കലും പ്രവേശനവും വേറിട്ട ഘട്ടങ്ങളാണ്. പ്രക്രിയയ്ക്ക് ഓരോ മാതൃ ഡയറക്ടറിയിലും എക്സിക്യൂട്ട് അനുമതിയും ഫയലിൽ വായനാ അനുമതിയും ആവശ്യമാണ്, ഫയൽസിസ്റ്റത്തിന്റെ ഒരു ഭാഗം മറയ്ക്കുന്ന സേവന unit പ്രക്രിയയ്ക്ക് ഒട്ടും കാണാനാകുന്നത് മാറ്റുന്നു.

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

അനുമതികൾ അയച്ചുവിടുന്നതിനു പകരം ഫയൽ ഉടമസ്ഥതയും പ്രക്രിയയുടെ ഐഡന്റിറ്റിയും കൊണ്ട് രോഗനിർണയം ചെയ്യുക. ഈ പിശക് ശാന്തമാക്കാൻ സ്വകാര്യ കീ എല്ലാവർക്കും വായിക്കാനാകുന്നതാക്കുന്നത് ഉച്ചത്തിലുള്ള പരാജയത്തെ നിശ്ശബ്ദതയുമായി കൈമാറുന്നു, കീ ഡയറക്ടറിയിൽ നിങ്ങൾ ഏറ്റവും കുറച്ച് വെളിപ്പെടുത്താൻ ആഗ്രഹിക്കുന്ന ഭാഗമാണ്.

നിങ്ങളുടെ സ്വന്തം ലോഞ്ച് കൊണ്ട് തിരുത്തൽ തെളിയിക്കുക

പ്രൊഫൈലുമായി ബന്ധമില്ലാത്ത ഒരു ഡയറക്ടറിയിൽ നിന്ന് യഥാർത്ഥ unit വീണ്ടും ആരംഭിച്ച് അതേ സ്റ്റാർട്ടപ്പ് വരി നിരീക്ഷിക്കുക. തുടർന്ന് പ്രക്രിയ പ്രവർത്തിക്കുമ്പോൾ ഉദ്ദേശിച്ച ഡയറക്ടറി പിടിച്ചിരിക്കുന്നുവെന്നും ലോഡ് ചെയ്ത സർട്ടിഫിക്കറ്റ് നിങ്ങൾ പ്രതീക്ഷിക്കുന്നതാണെന്നും സ്ഥിരീകരിക്കുക.

systemctl restart openvpn@tenant-a
systemctl status openvpn@tenant-a --no-pager
journalctl -u openvpn@tenant-a -n 20 --no-pager

പാത ലോഡിംഗ് വിജയിക്കുമ്പോഴും ഓതന്റിക്കേഷനും റൗട്ടിംഗും സ്വന്തം പരാജയങ്ങളുള്ള വേറിട്ട ഘട്ടങ്ങളാണ്, കണക്ഷൻ ഉയർന്നുവന്ന് ട്രാഫിക് കടക്കാതിരിക്കുന്നത് മറ്റൊരു അന്വേഷണമാണ്. ഇവിടത്തെ തിരുത്തൽ ഫയലുകൾ ഏത് ഡയറക്ടറിയിൽ നിന്ന് വന്നു എന്നതിനെക്കുറിച്ച് മാത്രമാണ്, അത് വിളിയിൽ കാണേണ്ടതാണ്, അവസാനം കൈകൊണ്ട് ഓടിച്ചയാളുടെ ഓർമ്മയിൽ അല്ല.

പ്രൊഫൈൽ ഒരു കോൺഫിഗറേഷൻ മാനേജർ വിന്യസിക്കുന്നുവെങ്കിൽ അടിസ്ഥാന ഡയറക്ടറിയോ പൂർണ്ണ ഫയൽ നാമങ്ങളോ അവിടെയും ഇടുക. ഒരു ഹോസ്റ്റിൽ കൈകൊണ്ട് ചെയ്യുന്ന തിരുത്തൽ അടുത്ത പുനർനിർമ്മാണത്തിന് ശേഷം മടങ്ങിവരുന്ന ഈ പ്രശ്നത്തിന്റെ പതിപ്പാണ്.