OpenVPN username-as-common-name: നിങ്ങളുടെ CN പരിശോധന ശൂന്യമാകുന്നത് എന്തുകൊണ്ട്
common_name ഉം username ഉം താരതമ്യം ചെയ്യുന്ന client-connect സ്ക്രിപ്റ്റ് ഒരു പേരിനെ അതിനോടുതന്നെ താരതമ്യം ചെയ്തേക്കാം. മാറ്റിസ്ഥാപിക്കൽ നടക്കുന്നതിന് മുൻപ് സർട്ടിഫിക്കറ്റ് അക്കൗണ്ടുമായി ബന്ധിപ്പിക്കുക.
നിങ്ങൾ client-connect സ്ക്രിപ്റ്റ് ചേർക്കുന്നു, അത് common_name username-ൽ നിന്ന് വ്യത്യസ്തമായ ഏത് കണക്ഷനും നിരസിക്കുന്നു, അത് സർട്ടിഫിക്കറ്റും അക്കൗണ്ടും തമ്മിലുള്ള ബന്ധം പോലെ തോന്നുന്നു. username-as-common-name പ്രവർത്തിക്കുന്ന സെർവറിൽ, സ്ക്രിപ്റ്റ് പ്രവർത്തിക്കുന്ന സമയത്തോടെ ആ താരതമ്യം അർത്ഥം നഷ്ടപ്പെട്ടിരിക്കുന്നു. രണ്ട് മൂല്യങ്ങളും ഒരേ സ്ട്രിംഗ് ആണ്, അതിനാൽ പരിശോധന പൂർണ്ണമായും മറ്റൊരാൾക്ക് നൽകിയ സർട്ടിഫിക്കറ്റിനും വിജയിക്കുന്നു.
സ്ക്രിപ്റ്റ് മോശമായി എഴുതിയതിനാൽ പരിശോധന തെറ്റല്ല. അത് വായിക്കുന്ന മൂല്യം അതേ കണക്ഷനിൽ നേരത്തെ മാറ്റിസ്ഥാപിച്ചതിനാൽ അത് തെറ്റാണ്.
താരതമ്യം എന്താണ് തെളിയിക്കുന്നതായി തോന്നുന്നത്
സർട്ടിഫിക്കറ്റ് പ്രാമാണീകരണവും പാസ്വേഡ് പ്രാമാണീകരണവും വേറിട്ട തെളിവുകളാണ്, ഒരേ വ്യക്തിയുടേതാണെന്ന് ആവശ്യപ്പെടാതെ സെർവർ രണ്ടും ആവശ്യപ്പെടാം. വിടവ് യഥാർത്ഥമാണ്: സാധുവായ ഒരു ഉപകരണ സർട്ടിഫിക്കറ്റും ഏതെങ്കിലും സാധുവായ അക്കൗണ്ടും ചേർന്നത് അതേ സർട്ടിഫിക്കറ്റും ഒരു പേരുള്ള അക്കൗണ്ടും ചേർന്നതിൽ നിന്ന് വ്യത്യസ്തമായ അവകാശവാദമാണ്. common_name നെ username മായി താരതമ്യം ചെയ്യുന്ന സ്ക്രിപ്റ്റ് രണ്ടിനുമിടയിലെ കാണാത്ത കണ്ണിയായി വായിക്കപ്പെടുന്നു. common_name ഇപ്പോഴും സർട്ടിഫിക്കറ്റ് പറഞ്ഞത് അർത്ഥമാക്കുന്നുവെങ്കിൽ അത് അങ്ങനെയാകുമായിരുന്നു.
അത് അങ്ങനെയാണോ എന്നത് ഒരു സെർവർ ഓപ്ഷനെ ആശ്രയിച്ചിരിക്കുന്നു, ആ ഓപ്ഷൻ സാധാരണയായി ബന്ധമില്ലാത്ത ഒരു കാരണത്താൽ ഓണാക്കുന്നു, ഉദാഹരണത്തിന് ഓരോ ഉപയോക്താവിന്റെയും കോൺഫിഗറേഷൻ ഫയലുകൾക്ക് പേരിടാൻ എളുപ്പമാക്കാൻ.
username-as-common-name പേരിനോട് ചെയ്യുന്നത്
username-as-common-name സജീവമാക്കുമ്പോൾ, OpenVPN ഉപയോക്തൃനാമവും പാസ്വേഡും പരിശോധിച്ചതിന് ശേഷം സർട്ടിഫിക്കറ്റിന്റെ പൊതുനാമത്തിന് പകരം പ്രാമാണീകരിച്ച ഉപയോക്തൃനാമം ഇടുന്നു. ആ പരിശോധനയിൽ പ്രവർത്തിക്കുന്ന പരിശോധനാ ഹുക്കിന് ഇപ്പോഴും സർട്ടിഫിക്കറ്റിന്റെ പൊതുനാമം ലഭിക്കുന്നു, കാരണം മാറ്റിസ്ഥാപിക്കൽ ഇതുവരെ നടന്നിട്ടില്ല. അതിനുശേഷമുള്ള എല്ലാം, client-connect ഉൾപ്പെടെ, ഉപയോക്തൃനാമം കാണുന്നു. അതിനാൽ പിന്നീടുള്ള കോൾബാക്കിന് ഒരേ ഐഡന്റിറ്റി രണ്ടുതവണ ലഭിക്കുന്നു, അവതരിപ്പിച്ച സർട്ടിഫിക്കറ്റുമായി അത് താരതമ്യം ചെയ്യാൻ കഴിയില്ല.
| Stage | What common_name holds |
|---|---|
| Username and password verification hook | The certificate common name, for example bob-device |
| After the replacement | The authenticated account, alice |
| client-connect callback | The account again, alice |
ഒരു ഉദാഹരണ കണക്ഷൻ പിന്തുടരുക: bob-device ന് നൽകിയ സർട്ടിഫിക്കറ്റ്, alice ആയി വിജയകരമായ ഡയറക്ടറി ലോഗിൻ, ഓപ്ഷൻ സജീവം. പരിശോധനാ ഘട്ടത്തിന് ഇപ്പോഴും രണ്ട് വ്യത്യസ്ത സ്ട്രിംഗുകൾ കാണാം. കണക്ഷൻ ഘട്ടം alice ഉം alice ഉം കാണുന്നു.
ആ ഉദാഹരണം താരതമ്യം എന്തുകൊണ്ട് ശൂന്യമാണെന്ന് കാണിക്കുന്നു. സർട്ടിഫിക്കറ്റ് സാധുതാ പരിശോധനയും പാസ്വേഡ് പരിശോധനയും ഇപ്പോഴും സ്വതന്ത്രമായി നടക്കുന്നതിനാൽ, കണക്ഷൻ മറ്റൊരു രീതിയിൽ സ്വീകരിക്കുമായിരുന്നു എന്ന് അത് കാണിക്കുന്നില്ല.
രണ്ട് ഐഡന്റിറ്റികളും ഇപ്പോഴും നിലനിൽക്കുന്നിടത്ത് ബന്ധം സ്ഥാപിക്കുക
സർട്ടിഫിക്കറ്റിന്റെ ഐഡന്റിറ്റിയും അക്കൗണ്ടും ഒരേസമയം കാണുന്ന ഘട്ടത്തിൽ നിയമം നടപ്പാക്കണം, അതായത് പ്രായോഗികമായി ഉപയോക്തൃനാമ-പാസ്വേഡ് പരിശോധനാ ഹുക്ക് അല്ലെങ്കിൽ അവിടെ ലോഡ് ചെയ്ത പ്ലഗിൻ. ഇതിനകം പാസ്വേഡ് പരിശോധന നടത്തുന്ന പിന്തുണയുള്ള പ്ലഗിൻ സാധാരണയായി ജോഡി നിയമം ചേർക്കാനുള്ള ശരിയായ സ്ഥലമാണ്, കാരണം അതിനെ പേരുകളുടെ താരതമ്യം കൊണ്ട് മാറ്റിയാൽ പാസ്വേഡ് പരിശോധന പൂർണ്ണമായി നഷ്ടപ്പെടും.
കോഡ് എഴുതുന്നതിന് മുൻപ് മാപ്പിംഗ് നിർവചിക്കുക, കാരണം തുല്യത അപൂർവ്വമായേ യഥാർത്ഥ നയമാകൂ. സർട്ടിഫിക്കറ്റ് പലപ്പോഴും ഒരു ഉപകരണത്തെ തിരിച്ചറിയിക്കുന്നു, ലോഗിൻ ഒരു വ്യക്തിയെ തിരിച്ചറിയിക്കുന്നു, ഒരു ഉപകരണത്തിന് നിയമാനുസൃതമായി പലരെയും സേവിക്കാം. നിങ്ങൾ നിയന്ത്രിക്കുന്ന രീതിയിൽ ബന്ധം സൂക്ഷിക്കുക, പേരുമാറ്റൽ, പുനർനൽകൽ, ഡൊമെയ്ൻ യോഗ്യമായ പേരുകൾ എന്നിവയിൽ എന്ത് സംഭവിക്കുമെന്ന് തീരുമാനിക്കുക. ഡയറക്ടറി മനസ്സിലാക്കാതെ ചെറിയ അക്ഷരമാക്കുന്നതോ ഡൊമെയ്ൻ പ്രിഫിക്സ് നീക്കുന്നതോ വേർതിരിഞ്ഞിരിക്കേണ്ട രണ്ട് അക്കൗണ്ടുകൾ ലയിപ്പിച്ചേക്കാം.
ഓപ്ഷൻ ഏത് ക്ലയന്റ് കോൺഫിഗറേഷൻ ബാധകമാകുമെന്നും മാറ്റുന്നു എന്ന് ഓർക്കുക, കാരണം client-config-dir പൊതുനാമത്തിൽ ആണ് അടിസ്ഥാനപ്പെടുത്തിയിരിക്കുന്നത്.
രണ്ട് സാധുവായ ക്രെഡൻഷ്യലുകൾ ഉപയോഗിച്ച് ജോഡി നിയമം പരീക്ഷിക്കുക
നിങ്ങളുടെ നയം അനുവദിക്കുന്ന ജോഡിയിൽ തുടങ്ങി അത് കണക്ട് ചെയ്യുന്നുവെന്ന് ഉറപ്പാക്കുക. പിന്നീട് അതേ സാധുവായ സർട്ടിഫിക്കറ്റ് മറ്റൊരു, എന്നാൽ അല്ലാതെ സാധുവായ അക്കൗണ്ടിനൊപ്പം അവതരിപ്പിക്കുക: ആ ശ്രമം പരാജയപ്പെടണം, തെറ്റായി ടൈപ്പ് ചെയ്ത പാസ്വേഡ് കാരണമല്ല, ജോഡി നിയമം കാരണം പരാജയപ്പെടണം. തെറ്റായ പാസ്വേഡ് പാസ്വേഡ് പരിശോധന പ്രവർത്തിക്കുന്നു എന്ന് തെളിയിക്കുന്നു, സർട്ടിഫിക്കറ്റും അക്കൗണ്ടും തമ്മിലുള്ള നിയമത്തെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.
സർട്ടിഫിക്കറ്റ് ഇല്ലാത്തതും അസാധുവായ സർട്ടിഫിക്കറ്റുമുള്ളതുമായ പാതകളും പരിശോധിക്കുക, ക്ലയന്റ് തല സെറ്റിംഗുകൾക്ക് സെർവർ ഏത് ഐഡന്റിറ്റി ഉപയോഗിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക. താരതമ്യം പ്രവർത്തിക്കാനുള്ള ഏക വഴി username-as-common-name പ്രവർത്തനരഹിതമാക്കുന്നതാണെങ്കിൽ, ആ മാറ്റത്തിന്റെ ചെലവ് ആദ്യം കണക്കാക്കുക, കാരണം അത് ഓരോ ക്ലയന്റിന്റെയും കോൺഫിഗറേഷൻ തിരച്ചിലിനെ സർട്ടിഫിക്കറ്റിന്റെ പേരിലേക്ക് തിരികെ കൊണ്ടുവരുന്നു.