OpenVPN സർട്ടിഫിക്കറ്റും കീയും എങ്ങനെ നിർണ്ണയിക്കുന്നു: ഇൻലൈൻ PEM അല്ലെങ്കിൽ ഫയൽ പാത

സന്ദേശം പറയുന്നത് OpenVPN ഒരു ഇൻലൈൻ സർട്ടിഫിക്കറ്റ് ലോഡ് ചെയ്യാനാകില്ല എന്നാണ്, എന്നാൽ നിങ്ങളുടെ മനസ്സിലുള്ള ഫയൽ നാമം വിപരീതം പറയുന്നു. ഫയൽ സിസ്റ്റത്തിൽ എന്തുണ്ട് എന്നതിനേക്കാൾ പ്രധാനം പാർസർ എന്ത് സ്വീകരിച്ചു എന്നതാണ്, കാരണം cert നിർദ്ദേശം തികച്ചും വ്യത്യസ്തമായ രണ്ട് തരം മൂല്യങ്ങൾ സ്വീകരിക്കുന്നു. ഒന്ന് അത് തുറക്കുന്ന പാതയാണ്; മറ്റൊന്ന് കോൺഫിഗറേഷനിനുള്ളിൽ വന്ന PEM ടെക്സ്റ്റാണ്. പ്രവർത്തിക്കുന്ന ക്ലയന്റിന് ഏത് രൂപം ലഭിച്ചു എന്ന് അറിയുന്നതുവരെ ഓരോ തിരുത്തലും ഊഹമാണ്.

രണ്ട് സംഭരണ രൂപങ്ങൾ, ഒരു നിർദ്ദേശം

cert, key, ca എന്നീ നിർദ്ദേശങ്ങൾ ഓരോന്നും പാതയോ ഇൻലൈൻ ബ്ലോക്കോ സ്വീകരിക്കുന്നു. മൂല്യം പാതയാകുമ്പോൾ OpenVPN ആ ഫയൽ തുറന്ന് ഡിസ്കിൽ നിന്ന് ഒബ്ജക്ട് വായിക്കുന്നു. കോൺഫിഗറേഷനിൽ cert ടാഗുകൾ കൊണ്ട് അതിർത്തിയിട്ട ബ്ലോക്ക് ഉണ്ടെങ്കിൽ, അതേ നിർദ്ദേശം പകരം ആ ടാഗുകൾക്കിടയിലുള്ള ഉള്ളടക്കം ഉപയോഗിക്കുന്നു, പ്രത്യേക ഫയലൊന്നും ഇടപെടുന്നില്ല.

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

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

ഇൻലൈൻ ബ്ലോക്ക് എങ്ങനെ ഒബ്ജക്ട് ആകുന്നു

ഇൻലൈൻ ഉള്ളടക്കം കോൺഫിഗറേഷനിൽ നിന്ന് വേർതിരിച്ചെടുത്ത് ടെക്സ്റ്റായി PEM പാർസറിന് നൽകുന്നു. ആ പാർസർ സാധാരണ അതിരുകൾ പ്രതീക്ഷിക്കുന്നു: BEGIN വരി, base64 പേലോഡ്, അനുയോജ്യമായ END വരി. ബ്ലോക്ക് പരാജയപ്പെട്ട പകർപ്പ് മൂലം മുറിഞ്ഞതാണെങ്കിൽ, ഡൗൺലോഡ് പേജ് അത് HTMLിൽ പൊതിഞ്ഞതാണെങ്കിൽ, അല്ലെങ്കിൽ ഡാഷുകൾ സാധാരണവൽക്കരിച്ച എഡിറ്ററിൽ തുറന്നതാണെങ്കിൽ, പാർസർ നിലവിലുള്ളതായി തോന്നുന്ന ഉള്ളടക്കത്തിൽ പരാജയപ്പെടുന്നു.

<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

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

ലോഡ് ചെയ്ത പ്രൊഫൈൽ യഥാർത്ഥത്തിൽ ഏത് രൂപമാണ് ഉപയോഗിക്കുന്നതെന്ന് പരിശോധിക്കുക, നിങ്ങളുടെ എഡിറ്റർ യാദൃച്ഛികമായി തുറന്ന ഫയലല്ല:

grep -nE '^(ca|cert|key) |^<(ca|cert|key)>' client.ovpn

പാത സൂചന എങ്ങനെ പരിഹരിക്കപ്പെടുന്നു

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

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

വെവ്വേറെ സംഭരിച്ച സർട്ടിഫിക്കറ്റിനായി, അതിന് മുകളിൽ എന്തെങ്കിലും ഡീബഗ് ചെയ്യുന്നതിന് മുൻപ് ഒരു ഓഫ്ലൈൻ പാർസ് ഒബ്ജക്ട് സ്ഥിരീകരിക്കുന്നു:

openssl x509 -in client.crt -noout -subject -issuer -dates
openssl pkey -in client.key -noout -check

ആ കമാൻഡുകൾ ഫയലുകൾ വായിക്കാനാകുമെന്നും ഘടനാപരമായി സാധുവാണെന്നും തെളിയിക്കുന്നു. സഹകാരി ഇഷ്യൂവറെ വിശ്വസിക്കുന്നു, സർട്ടിഫിക്കറ്റ് ഇപ്പോഴും സാധുതാ കാലയളവിനുള്ളിലാണ്, അല്ലെങ്കിൽ കീ അതിനുള്ളതാണ് എന്ന് അവ തെളിയിക്കുന്നില്ല.

പാർസർ പിശകിന് എന്ത് പറയാനാകും എന്ത് പറയാനാകില്ല

പാർസ് പരാജയം പ്രശ്നത്തെ ഒരു ഇൻപുട്ടിലേക്കും ഒരു ഘട്ടത്തിലേക്കും പരിമിതപ്പെടുത്തുന്നു. ക്ലയന്റ് രണ്ട് സംഭരണ രൂപങ്ങളിൽ ഏതാണ് ഉപയോഗിച്ചതെന്ന് അത് പറയുന്നില്ല, ഒബ്ജക്ട് സ്വീകരിക്കുമായിരുന്നോ എന്നും പറയുന്നില്ല. വെവ്വേറെ തെളിവുകളുള്ള വെവ്വേറെ ചോദ്യങ്ങളാണ് ഇവ.

പാർസ് വിജയിച്ചതിന് ശേഷം, അടുത്ത പരാജയം പിന്നീടുള്ള ഘട്ടത്തിന്റേതാണ്. വിശ്വാസ നിരസനം, ഉദ്ദേശ്യ പൊരുത്തക്കേട് അല്ലെങ്കിൽ കീ പൊരുത്തക്കേട് ലോഡറല്ല, സഹകാരിയോ TLS പാളിയോ ആണ് റിപ്പോർട്ട് ചെയ്യുന്നത്. അതേ ഫയൽ ആവർത്തിച്ച് മാറ്റുന്നത് ആ പിശകിനെ നീക്കില്ല.

അന്വേഷണ സമയത്ത് സംവേദനക്ഷമമായ പകുതി പൊതു റിപ്പോർട്ടുകൾക്ക് പുറത്ത് സൂക്ഷിക്കുക. നിർദ്ദേശങ്ങളുടെ പേരുകൾ, പിശക് ടെക്സ്റ്റ്, ബ്ലോക്കിന്റെ ഘടന എന്നിവ പങ്കിടുക, കീ മെറ്റീരിയലും തിരിച്ചറിയാവുന്ന പേലോഡും നീക്കം ചെയ്ത്. openvpn(8) കൈപ്പുസ്തകം ഫയൽ നിർദ്ദേശങ്ങളുടെ രണ്ട് രൂപങ്ങളും അവയ്ക്ക് പിന്നിലെ പ്രവർത്തന ഡയറക്ടറി സ്വഭാവവും രേഖപ്പെടുത്തുന്നു.