OpenVPN-ന്റെ CA സൈനിംഗ് കീ /etc/openvpn-ന് പുറത്ത് സൂക്ഷിക്കുക

ട്യൂട്ടോറിയലിൽ സമാനമായി കാണുന്ന രണ്ട് ഡയറക്ടറികൾ തികച്ചും വ്യത്യസ്ത ജോലികൾ ചെയ്യുന്നു. ഒന്ന് സർട്ടിഫിക്കറ്റ് അതോറിറ്റി സൂക്ഷിക്കുന്നു: അതിന്റെ സ്വകാര്യ കീ, സീരിയൽ കൗണ്ടർ, അത് ഒപ്പിട്ട എല്ലാറ്റിന്റെയും രേഖ. മറ്റൊന്ന് ഡീമണിന് ആരംഭിക്കാനും ക്ലയന്റുകളെ സേവിക്കാനും വേണ്ടത് സൂക്ഷിക്കുന്നു. രണ്ടും ഒരേ ഹോസ്റ്റിൽ ഒരേ അക്കൗണ്ടിന് കീഴിൽ സൂക്ഷിക്കുന്നത് ഒരു ഉച്ചയ്ക്ക് സൗകര്യവും വിന്യാസത്തിന്റെ ബാക്കി ആയുസ്സിന് ചെലവേറിയതുമാണ്, കാരണം അപ്പോൾ ഡീമൺ ഏത് ഐഡന്റിറ്റിയും നിർമ്മിക്കാനാകുന്ന ഒരേയൊരു കീയുടെ അടുത്ത് പ്രവർത്തിക്കുന്നു.

CA വർക്ക്‌സ്പേസിൽ എന്തുണ്ട്

PKI ഡയറക്ടറി ഇഷ്യൂവറുടെ അവസ്ഥയാണ്, കോൺഫിഗറേഷനല്ല. അതിൽ CA-യുടെ സ്വകാര്യ കീയും സർട്ടിഫിക്കറ്റും, സീരിയൽ ഫയൽ, പുറപ്പെടുവിച്ച സർട്ടിഫിക്കറ്റുകളുടെ സൂചിക, അവയിൽ നിന്ന് നിർമ്മിച്ച ഓരോ ഐഡന്റിറ്റിയുടെയും വസ്തുക്കൾ എന്നിവ ഉണ്ട്.

ഒരു അഭ്യർത്ഥന ഒപ്പിടുന്നത് ആ അവസ്ഥ മാറ്റുന്നു, അതിനാൽ വർക്ക്‌സ്പേസ് VPN സേവനം പ്രവർത്തിക്കാത്ത ഹോസ്റ്റിലെ അഡ്മിനിസ്ട്രേറ്റർ നിയന്ത്രിക്കുന്ന അക്കൗണ്ടിന് സ്വന്തമാണ്. CA-യുടെ സ്വകാര്യ കീ വായിക്കാൻ കഴിയുന്ന ആർക്കും സെർവർ വിശ്വസിക്കുന്ന സർട്ടിഫിക്കറ്റ് പുറപ്പെടുവിക്കാം, അതിനാൽ കീയുടെ സംരക്ഷണമാണ് ഒരു ഫയലിലെ മുഴുവൻ വിശ്വാസ മാതൃക. ഒരു ഘട്ടം ലാഭിക്കാൻ അത് രണ്ടാം സ്ഥലത്തേക്ക് പകർത്തുന്നത് സംരക്ഷിക്കാൻ രണ്ടാമത്തെ വസ്തുവും മറക്കാൻ രണ്ടാമത്തെ വസ്തുവും സൃഷ്ടിക്കുന്നു. ഓരോ ഒപ്പും സീരിയൽ കൂട്ടുകയും സൂചികയിൽ ഒരു എൻട്രി ചേർക്കുകയും ചെയ്യുന്നു, അതിനാൽ വർക്ക്‌സ്പേസ് ഫയലുകളുടെ ഫോൾഡറല്ല, അവസ്ഥയുടെ ഒരു പകർപ്പാണ്.

പൊതു CA സർട്ടിഫിക്കറ്റ് വ്യത്യസ്തമാണ്. അത് വിതരണത്തിനുള്ളതാണ്, ക്ലയന്റുകളും സെർവറുകളും പരസ്പരം പരിശോധിക്കാൻ അതാണ് ഉപയോഗിക്കുന്നത്.

ഡീമൺ ആരംഭിക്കുമ്പോൾ വായിക്കുന്നത്

പ്രവർത്തിക്കുന്ന സെർവർ ഒരു ചെറിയ കൂട്ടം ഉപയോഗിക്കുന്നു: സ്വന്തം സർട്ടിഫിക്കറ്റ്, സ്വന്തം സ്വകാര്യ കീ, സഹപ്രവർത്തകരെ പരിശോധിക്കാനുള്ള CA സർട്ടിഫിക്കറ്റ്, തിരഞ്ഞെടുത്ത മോഡിന് ആവശ്യമായ കീ വസ്തുക്കൾ. ഈ പാതകൾ ആരംഭത്തിലും വീണ്ടും റീലോഡിലും വായിക്കുന്നു.

ഉടമസ്ഥത യഥാർത്ഥത്തിൽ ആരംഭിക്കുന്ന യൂണിറ്റിനെ ആധാരമാക്കി വിലയിരുത്തണം, ഇന്ററാക്ടീവ് root ഷെല്ലിനെ അല്ല. പ്രഖ്യാപിത സാൻഡ്‌ബോക്സിംഗ് ഫയൽസിസ്റ്റത്തിന്റെ ഭാഗം വായന-മാത്രമോ അദൃശ്യമോ ആക്കാം, root ആയി കൈകൊണ്ട് ചെയ്യുന്ന പരിശോധന വിജയിച്ചാലും.

systemctl show -p User -p Group -p ReadOnlyPaths [email protected]
stat -c '%a %U:%G' /etc/openvpn/server/server.key
runuser -u openvpn -- test -r /etc/openvpn/server/server.key; echo $?

മൂന്നാമത്തെ വരിയാണ് ആളുകൾ ഒഴിവാക്കുന്നത്. അത് ഡീമണിന്റെ സ്വന്തം അക്കൗണ്ടിനോട് കീ വായിക്കാൻ കഴിയുമോ എന്ന് ചോദിക്കുന്നു, ആനുകൂല്യം വീണതിന് ശേഷം പ്രസക്തമായ ചോദ്യത്തിന്റെ ഏകരൂപം അതാണ്. root ആയി പൂജ്യം എക്സിറ്റ് കിട്ടുന്നത് ആനുകൂല്യം വീണതിന് ശേഷം എന്ത് സംഭവിക്കുന്നു എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

ഏതെങ്കിലും അനുമതി മാറ്റുന്നതിന് മുൻപ് രണ്ട് പരാജയ പാതകൾ വേർതിരിക്കേണ്ടതാണ്. ഒപ്പിടൽ പരാജയം PKI ഡയറക്ടറിയിലേക്കും അതിന്റെ മാതൃ ഡയറക്ടറികളിലെ തിരയൽ അനുമതിയിലേക്കും ഇഷ്യൂവർ പ്രവർത്തിപ്പിക്കുന്ന അക്കൗണ്ടിലേക്കും വിരൽ ചൂണ്ടുന്നു. ആരംഭ പരാജയം യൂണിറ്റിലേക്കും അതിന്റെ പ്രവർത്തന ഡയറക്ടറിയിലേക്കും സെർവർ കോൺഫിഗറേഷനിൽ പേരിട്ടിരിക്കുന്ന പാതകളിലേക്കും വിരൽ ചൂണ്ടുന്നു. മുഴുവൻ വൃക്ഷവും എല്ലാവർക്കും വായിക്കാവുന്നതാക്കുന്നത് ഇവയൊന്നും ശരിയാക്കുന്നില്ല, രണ്ടും ആശ്രയിക്കുന്ന അതിർത്തി നീക്കം ചെയ്യുന്നു.

CA കീ സെർവറിലേക്ക് പകർത്തുന്നത് പിന്നീട് എന്തുകൊണ്ട് പരാജയപ്പെടുന്നു

പകർപ്പ് സാധാരണയായി ഡീബഗ്ഗിംഗ് നടപടിയായി തുടങ്ങുന്നു: ആർക്കെങ്കിലും VPN ഹോസ്റ്റിൽ ഒരു ക്ലയന്റ് പുതുക്കണം, അതിനാൽ CA കീ /etc/openvpn-ൽ എത്തുന്നു, പുതുക്കൽ നടക്കുന്നു. തൽക്ഷണ ജോലി വിജയിക്കുന്നു, അതിർത്തി പോകുന്നു.

പിന്നീട് സെർവർ ബാക്കപ്പ് ചെയ്യുന്നു, ഒപ്പിടൽ അതോറിറ്റി ബാക്കപ്പുകളിൽ ചേരുന്നു. സ്നാപ്പ്ഷോട്ടോ സപ്പോർട്ട് ബണ്ടിലോ കോൺഫിഗറേഷൻ ഡയറക്ടറിയുടെ പകർപ്പോ ഇപ്പോൾ CA സാധുവായിരിക്കുന്നിടത്തോളം വിശ്വസ്ത ഐഡന്റിറ്റികൾ പുറപ്പെടുവിക്കാനുള്ള കഴിവ് വഹിക്കുന്നു. ആ പകർപ്പ് കൈവശമുള്ള ആർക്കും സെർവർ സ്വീകരിക്കുന്ന ഏത് പേരിനും സർട്ടിഫിക്കറ്റ് നിർമ്മിക്കാം, ഒരിക്കലും പുറപ്പെടുവിക്കാത്ത പേരുകൾ ഉൾപ്പെടെ. ആ പുറപ്പെടുവിക്കലിന്റെ ഏക രേഖ അവർ സൂക്ഷിക്കാൻ തിരഞ്ഞെടുക്കുന്നതാണ്.

അത്തരം അവസ്ഥയിൽ നിന്ന് കരകയറുന്നത് ഫയൽ ഡിലീറ്റ് ചെയ്യുന്ന കാര്യമല്ല. കീ വെളിപ്പെട്ടോ എന്ന് തീരുമാനിക്കണം, വെളിപ്പെട്ടെങ്കിൽ CA തിരിക്കണം, എല്ലാ സഹപ്രവർത്തകർക്കും വിശ്വാസം വീണ്ടും വിതരണം ചെയ്യണം. വേറിട്ട വർക്ക്‌സ്പേസ് ആ സംഭാഷണം മുഴുവൻ ഒഴിവാക്കുന്നു.

അക്കൗണ്ടുകൾ, ഡയറക്ടറികൾ, ബാക്കപ്പുകൾ

ഇഷ്യൂവറിന് സ്വന്തം അക്കൗണ്ടും ഹോം ഡയറക്ടറിയും നൽകുക, പ്രായോഗികമെങ്കിൽ VPN ഹോസ്റ്റിൽ നിന്ന് അകലെ സൂക്ഷിക്കുക. ഡീമണിന് വേറെ അക്കൗണ്ട് നൽകുക, വിന്യസിച്ച വസ്തുക്കളിൽ വായനാനുമതിയും സർട്ടിഫിക്കറ്റ് പുറപ്പെടുവിക്കുന്ന ഒന്നിലും എഴുത്തനുമതിയും ഇല്ലാതെ. പൊതു സർട്ടിഫിക്കറ്റുകൾ പുറത്തേക്ക് പകർത്തി വിന്യസിക്കുക, ഇഷ്യൂവറിന്റെ സ്വകാര്യ അവസ്ഥ ഒരിക്കലും അകത്തേക്ക് വലിക്കരുത്. രണ്ട് റോളുകളുടെയും ബാക്കപ്പ് വെവ്വേറെ എടുക്കുക, കാരണം അവയുടെ സംവേദനക്ഷമതയും പുനഃസ്ഥാപന കഥകളും വ്യത്യസ്തമാണ്.

റദ്ദാക്കലിന് ശേഷം സെർവർ കോൺഫിഗറേഷൻ പേരിടുന്ന CRL ഫയൽ പുതുക്കുക, പിന്നീട് പുതിയ കണക്ഷനുകൾ അത് വായിക്കാൻ സേവനം റീലോഡ് ചെയ്യുക. Easy-RSA ഡോക്യുമെന്റേഷൻ വർക്ക്‌സ്പേസ് ക്രമീകരണവും ഒപ്പിടൽ പ്രവാഹവും ഉൾക്കൊള്ളുന്നു; അതിന് ചുറ്റുമുള്ള ഉടമസ്ഥതാ നിയമങ്ങൾ നിങ്ങളുടെ ഹോസ്റ്റിനെക്കുറിച്ചുള്ള തീരുമാനമായി തുടരുന്നു. സേവനം എന്ത് ലോഡ് ചെയ്തു എന്ന് openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate കൊണ്ട് സ്ഥിരീകരിക്കുക, റീലോഡ് അത് എടുത്തു എന്ന് അനുമാനിക്കുന്നതിന് പകരം.

വിഭജനം തെളിയിക്കുന്ന ഒരു പരിശോധന

പ്രവർത്തിക്കുന്ന കേസ് മാത്രമല്ല, നെഗറ്റീവ് കേസും പരിശോധിക്കുക. രൂപകൽപ്പന പ്രകാരം ഇഷ്യൂവർ അക്കൗണ്ടിൽ നിന്ന് സർട്ടിഫിക്കറ്റിൽ ഒപ്പിടുക, പിന്നീട് അതേ അക്കൗണ്ടിന് സേവനം ആരംഭിക്കാനോ സെർവറിന്റെ സ്വകാര്യ കീ വായിക്കാനോ കഴിയില്ലെന്ന് സ്ഥിരീകരിക്കുക. തുടർന്ന് ഡീമണിന്റെ അക്കൗണ്ടിന് CA-യുടെ സ്വകാര്യ കീ വായിക്കാൻ കഴിയില്ലെന്ന് സ്ഥിരീകരിക്കുക.

ആ മൂന്ന് പരിശോധനകൾ കുറച്ച് മിനിറ്റ് എടുക്കും, ജീവനക്കാർ മാറിയാലും നിലനിൽക്കും, കാരണം അവ ശീലത്തെക്കുറിച്ചല്ല, അനുമതികളെക്കുറിച്ചുള്ള പ്രസ്താവനകളാണ്. ഫലം അത് ഉൾക്കൊണ്ട പാതകളും അക്കൗണ്ടുകളും സഹിതം, അവ പ്രവർത്തിപ്പിച്ച തീയതിയും ചേർത്ത് എഴുതുക. അല്ലെങ്കിൽ ഈ വിന്യാസം പാരമ്പര്യമായി ലഭിക്കുന്ന അടുത്ത വ്യക്തി അതിർത്തിയേ ഇല്ലാത്ത ഒരു ട്യൂട്ടോറിയലിൽ നിന്ന് അതിർത്തി വീണ്ടും കണ്ടെത്തും. തീയതിയുള്ള രേഖ തന്നെയാണ് അടുത്ത അവലോകനത്തെ ഒരു ഉച്ചയ്ക്ക് പകരം കുറച്ച് മിനിറ്റാക്കുന്നത്.