OpenVPN സേവനമായതിന് ശേഷം client-config-dir അവഗണിക്കപ്പെടുന്നു

നിങ്ങളുടെ ടണൽ ഉയരുന്നു, ക്ലയന്റ് ബന്ധിപ്പിക്കുന്നു, പക്ഷേ സ്ഥിരമായ വിലാസവും ആ ഒരു ഉപയോക്താവിനായി നിങ്ങൾ നിർവചിച്ച തള്ളിയ റൂട്ടുകളും കാണുന്നില്ല. ലോഗിൽ “file not found” എന്ന് എഴുതിയിട്ടില്ല, അതാണ് ആളുകളെ സർട്ടിഫിക്കറ്റുകൾ വീണ്ടും ഉണ്ടാക്കാൻ അയക്കുന്നത്. ഇത്തരം കേസുകളിൽ ഭൂരിഭാഗവും ഡീമൺ നിങ്ങൾ പരീക്ഷിച്ച ഷെല്ലിൽ നിന്ന് വ്യത്യസ്തമായ ഡയറക്ടറിയിൽ നിന്നാണ് പ്രവർത്തിക്കുന്നത്, കൂടാതെ client-config-dir നിങ്ങൾ അനുമാനിച്ചതുപോലെ ഒരിക്കലും നിർണ്ണയിക്കപ്പെട്ടിട്ടില്ല. പരിഹാരം പാതയുടെ തിരുത്തലാണ്, ക്രെഡൻഷ്യലുകളുടെ പുനഃസജ്ജീകരണമല്ല.

കോൺഫിഗറേഷനിൽ തൊടുന്നതിന് മുമ്പ് യൂണിറ്റ് വായിക്കുക

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

systemctl show openvpn-server@server -p ExecStart -p WorkingDirectory -p User -p RootDirectory

ശൂന്യമായ WorkingDirectory അർത്ഥമാക്കുന്നത് യൂണിറ്റ് /-ൽ ആരംഭിക്കുന്നു എന്നാണ്, അതിനാൽ ആപേക്ഷിക client-config-dir ccd /ccd-ൽ തിരയുന്നു. ആ ഡയറക്ടറി മിക്കവാറും ഉണ്ടാകാറില്ല, അതിന്റെ അഭാവത്തെ ഡീമൺ മാരകമായി കണക്കാക്കുന്നില്ല.

പരീക്ഷണ സമയത്ത് നിങ്ങൾ ഉപയോഗിച്ച ഇന്ററാക്ടീവ് ലോഞ്ചുമായി ഇത് താരതമ്യം ചെയ്യുക, അവിടെ നിങ്ങളുടെ ഷെല്ലിന്റെ നിലവിലെ ഡയറക്ടറി കോൺഫിഗറേഷൻ ഡയറക്ടറിയായിരുന്നു. അതേ ഫയൽ, അതേ കീവേഡുകൾ, രണ്ട് വ്യത്യസ്ത ഫലങ്ങൾ.

ആപേക്ഷിക പാത എന്തിനെതിരെയാണ് നിർണ്ണയിക്കുന്നത്

ഓപ്ഷൻ ഉപയോഗിക്കുന്ന നിമിഷത്തിൽ പ്രക്രിയയുടെ പ്രവർത്തന ഡയറക്ടറിക്ക് എതിരായി കീവേഡ് നിർണ്ണയിക്കുന്നു. “ഞാൻ --config ഉപയോഗിച്ച് കൈമാറിയ കോൺഫിഗറേഷൻ ഫയലിന് അടുത്ത്” എന്ന് ഇതിനർത്ഥമില്ല. OpenVPN സമ്പൂർണ്ണ പാതയിൽ നിന്ന് കോൺഫിഗറേഷൻ സന്തോഷത്തോടെ വായിക്കും, ആപേക്ഷിക മൂല്യങ്ങൾ എന്നിട്ടും മറ്റൊരിടത്ത് നിർണ്ണയിക്കും, ഇവിടെയുള്ള കെണി അതാണ്. OpenVPN 2.6 കൈപ്പുസ്തകം നിയമം --client-config-dir-ന് കീഴിലും വീണ്ടും --cd-ന് കീഴിലും പറയുന്നു.

cd കീവേഡ് മറ്റ് ഫയലുകൾ വായിക്കുന്നതിന് മുമ്പ് ആ സന്ദർഭം മാറ്റുന്നു, അതിനാൽ cd /etc/openvpn/server സജ്ജീകരിച്ച് പിന്നീട് client-config-dir ccd വയ്ക്കുന്ന യൂണിറ്റ് /etc/openvpn/server/ccd-ലേക്ക് നിർണ്ണയിക്കപ്പെടുന്നു. നിങ്ങൾ cd ചേർത്താൽ, നിർദ്ദേശങ്ങളുടെ ക്രമം പരിശോധിക്കുക, അത് അതേ ഫയലിലെ മറ്റെല്ലാ ആപേക്ഷിക റഫറൻസുകളെയും ബാധിക്കുമെന്ന് ഓർക്കുക.

ഡീമണിന്റെ അക്കൗണ്ടായി പാതയിലൂടെ നടക്കുക

പാത ശരിയായിരിക്കാം, എന്നിട്ടും വായിക്കാനാകില്ല. പ്രിവിലേജ് താഴ്ത്തിയ ശേഷം ഡീമൺ ഇനി root അല്ല, അതിനാൽ ഓരോ മാതൃ ഡയറക്ടറിക്കും ആ അക്കൗണ്ടിന് തിരയൽ അനുമതി വേണം, ക്ലയന്റ് ഫയലിന് തന്നെ വായനാ അനുമതി വേണം. മാതൃ ഡയറക്ടറിയിൽ ഒരു എക്സിക്യൂട്ട് ബിറ്റ് കുറവായാൽ ഫയൽ മറയ്ക്കാൻ മതി, പിശക് സ്വയം ഡിഫോൾട്ട് പൂൾ ലഭിക്കുന്ന ക്ലയന്റായി മാത്രം പ്രത്യക്ഷപ്പെടുന്നു.

namei ഓരോ ഘടകത്തിന്റെയും അനുമതി ക്രമത്തിൽ പ്രിന്റ് ചെയ്യുന്നു, ഇത് ഡയറക്ടറികൾ ഓരോന്നായി പരിശോധിക്കുന്നതിനേക്കാൾ വേഗമാണ്:

namei -l /etc/openvpn/server/ccd/client1

പിന്നീട് വായന നിങ്ങളായി അല്ല, സേവന അക്കൗണ്ടായി പരിശോധിക്കുക:

runuser -u openvpn -- test -r /etc/openvpn/server/ccd/client1 && echo readable

യൂണിറ്റ് chroot ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ, ഡയറക്ടറി ജയിലിനുള്ളിൽ ഉണ്ടായിരിക്കണം, കോൺഫിഗറേഷനിലെ പാത chroot പ്രയോഗിച്ചതിന് ശേഷമാണ് വ്യാഖ്യാനിക്കുന്നത്. ജയിലിന് പുറത്ത് ഹോസ്റ്റിലുള്ള ഫയൽ അകത്തുനിന്ന് അദൃശ്യമാണ്.

ഊഹിക്കാതെ തിരച്ചിൽ സ്ഥിരീകരിക്കുക

ഒരു റീസ്റ്റാർട്ടിനായി ലോഗ് നില ഉയർത്തി, ക്ലയന്റ്-നിർദ്ദിഷ്ട ഓപ്ഷനുകളെക്കുറിച്ച് സെർവർ എന്ത് പറയുന്നു എന്ന് വായിക്കുക. verb 4-ൽ ഡീമൺ ഇറക്കുമതി ചെയ്ത ഓരോ ക്ലയന്റിന്റെയും കോൺഫിഗറേഷൻ റിപ്പോർട്ട് ചെയ്യുന്നു, അതിനാൽ വരി ഇല്ലാതിരിക്കുന്നത് ആ കണക്ഷനുവേണ്ടി ഒരു ഫയലും വായിച്ചിട്ടില്ല എന്നതിന്റെ നേരിട്ടുള്ള തെളിവാണ്.

openvpn --config /etc/openvpn/server.conf --verb 4 --client-config-dir /etc/openvpn/server/ccd

അത് ഒരു ഒഴിവ് പോർട്ടിൽ മുൻവശത്ത് പ്രവർത്തിപ്പിച്ച് ഒരു ക്ലയന്റ് ബന്ധിപ്പിക്കുക. ഇത് systemd-യെ ചിത്രത്തിൽ നിന്ന് പൂർണ്ണമായും ഒഴിവാക്കുന്നു: ഓവർറൈഡുകൾ ഇവിടെ കാണുകയും സേവനത്തിന് കീഴിൽ കാണാതിരിക്കുകയും ചെയ്താൽ, വ്യത്യാസം ഫയലിലല്ല, യൂണിറ്റിന്റെ സന്ദർഭത്തിലാണ്.

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

തിരുത്തുക, റീസ്റ്റാർട്ട് ചെയ്യുക, പരിശോധിക്കുക

കോൺഫിഗറേഷനിൽ ഡയറക്ടറി സമ്പൂർണ്ണമാക്കി അതുപോലെ വയ്ക്കുക. ആപേക്ഷിക പാതകൾ സുരക്ഷിതമാകുന്നത് യൂണിറ്റ് പ്രവർത്തന ഡയറക്ടറി പിൻ ചെയ്യുമ്പോൾ മാത്രമാണ്, പിൻ ചെയ്യുന്നത് പിന്നീട് ആരെങ്കിലും നീക്കം ചെയ്യുന്ന അധിക ചലിക്കുന്ന ഭാഗമാണ്.

client-config-dir /etc/openvpn/server/ccd
ccd-exclusive

ഇൻസ്റ്റൻസ് റീസ്റ്റാർട്ട് ചെയ്യുക, അറിയപ്പെടുന്ന ഒരു ക്ലയന്റ് വീണ്ടും ബന്ധിപ്പിക്കുക, അത് ലഭിച്ച വിലാസം അതിലേക്ക് തള്ളിയ റൂട്ടുകളോടൊപ്പം വായിക്കുക. വിലാസം ആ ക്ലയന്റിന്റെ ഫയലിലെ ifconfig-push വരിയുമായി പൊരുത്തപ്പെടുന്നുവെങ്കിൽ, തിരച്ചിൽ പ്രവർത്തിച്ചു. ക്ലയന്റ് ഇപ്പോഴും പൊതു പൂളിൽ വീഴുന്നുവെങ്കിൽ, ലോഗ് വരികളുടെ എണ്ണത്തിലേക്ക് മടങ്ങുക: പൂജ്യം ഇറക്കുമതി എന്നാൽ പാതയോ ഐഡന്റിറ്റിയോ തെറ്റാണ്, തെറ്റായ ഉള്ളടക്കമുള്ള ഒരു ഇറക്കുമതി എന്നാൽ ഡീമൺ വായിക്കുന്നതിൽ നിന്ന് വ്യത്യസ്തമായ ഫയൽ നിങ്ങൾ തിരുത്തുന്നു എന്നാണ്.

മുൻപത്തെ യൂണിറ്റും കോൺഫിഗറേഷനും ഒരുമിച്ച് പുനഃസ്ഥാപിച്ച് പിന്നോട്ട് പോകുക, പിന്നീട് റീസ്റ്റാർട്ട് ചെയ്യുക. ഇവയൊന്നും സർട്ടിഫിക്കറ്റുകൾ വീണ്ടും ഇഷ്യൂ ചെയ്യേണ്ടതില്ല, ഡയറക്ടറി പ്രശ്നത്തെ ക്രെഡൻഷ്യൽ പ്രശ്നമായി കാണുന്നതാണ് അഞ്ച് മിനിറ്റത്തെ തിരുത്തലിനെ അറ്റകുറ്റപ്പണി ജാലകമാക്കി മാറ്റുന്നത്.