ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് ഇല്ലാതെ OpenVPN: സർവർ നയം, പ്രൊഫൈൽ അല്ല

സർട്ടിഫിക്കറ്റും കീയും വരികൾ ഇല്ലാതാക്കി പ്രൊഫൈൽ കൈമാറുന്നു, എന്നിട്ടും കണക്ഷൻ സർട്ടിഫിക്കറ്റ് പിശകിൽ പരാജയപ്പെടുന്നു. ആ ആവശ്യകത നടപ്പാക്കിയത് ഒരിക്കലും പ്രൊഫൈൽ ആയിരുന്നില്ല. ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് നിർബന്ധമാണോ എന്ന് തീരുമാനിക്കുന്നത് സർവറാണ്, ക്ലയന്റ് വശത്തെ ഒരു മാറ്റവും അത് ചർച്ചയിലൂടെ ഒഴിവാക്കുന്നില്ല. അതിനാൽ പരിഹാരം സർവർ നയത്തിലെ മാറ്റമാണ്, ബോധപൂർവം ചെയ്യുന്നത്, അതിനെ ആശ്രയിക്കുന്ന എല്ലാം അതേ ഘട്ടത്തിൽ പുതുക്കുന്നു.

പ്രൊഫൈൽ നയമല്ല

Community OpenVPN 2.6 നിർബന്ധിത ക്ലയന്റ് സർട്ടിഫിക്കറ്റുകളോടെയാണ് വരുന്നത്, കാരണം verify-client-cert സ്വതേ require ആണ്. അത് none ആക്കി സജ്ജീകരിക്കുന്നതാണ് സർട്ടിഫിക്കറ്റ് ആവശ്യപ്പെടുന്നത് നിർത്തി ക്ലയന്റ് പ്രാമാണീകരണം സർവർ ഇതിനകം നടത്തുന്ന ഉപയോക്തൃനാമവും പാസ്വേഡും ക്രമീകരണത്തിന് ഏൽപ്പിക്കുന്നത്. പഴയ ഗൈഡുകൾ അതേ ആശയത്തിന്റെ പഴയ അക്ഷരവിന്യാസമായ client-cert-not-required ലേക്ക് നീളുന്നു, അതിനാൽ നിങ്ങളുടെ ഇൻസ്റ്റാൾ ചെയ്ത പതിപ്പ് രേഖപ്പെടുത്തുന്ന നിർദ്ദേശം ഉപയോഗിക്കുക. ഏതായാലും മാറ്റം സർവറിൽ സംഭവിക്കുന്നു, ഒരു ക്ലയന്റ് പ്രൊഫൈലിനും അത് ചെയ്യാനാകില്ല.

താഴെയുള്ള ഭാഗം സർവർ വശത്തെ മുഴുവൻ മാറ്റമാണ്, ഒറ്റയ്ക്ക് അത് പ്രവർത്തിക്കുന്ന പ്രാമാണീകരണ കോൺഫിഗറേഷനല്ല. verify-client-cert none സർട്ടിഫിക്കറ്റ് ആവശ്യകത നീക്കം ചെയ്യുന്നു, അതേസമയം username-as-common-name അക്കൗണ്ടിന്റെ പേരിനെ പിന്നീടുള്ള കോൾബാക്കുകളും ഓരോ ക്ലയന്റിന്റെയും ഫയലുകളും കാണുന്ന ഐഡന്റിറ്റിയാക്കുന്നു. ഒരു വരിയും പാസ്വേഡ് പരിശോധിക്കുന്നില്ല, അതിനാൽ ഒരു സ്ഥിരീകരണക്കാരൻ ഇപ്പോഴും ഉണ്ടായിരിക്കണം.

verify-client-cert none
username-as-common-name

ആ സ്ഥിരീകരണക്കാരൻ auth-user-pass-verify നിയന്ത്രിക്കുന്ന ഒരു പ്ലഗിൻ അല്ലെങ്കിൽ സ്ക്രിപ്റ്റാണ്, മുകളിലെ ഏതെങ്കിലും വരിക്ക് അർത്ഥമുണ്ടാകുന്നതിന് മുമ്പ് അത് അതിന്റെ സ്ഥാനത്ത് ഉണ്ടായിരിക്കണം. ക്രമം തിരിച്ചിട്ടാൽ സർവർ സർട്ടിഫിക്കറ്റ് ആവശ്യപ്പെടാത്തതും അക്കൗണ്ട് പരിശോധിക്കാത്തതുമായ ഒരു ജാലകം ലഭിക്കും.

സർവറിനെ ഇപ്പോഴും എന്ത് സ്ഥിരീകരിക്കുന്നു

ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് ഒഴിവാക്കുന്നത് TLS ഒഴിവാക്കുന്നതല്ല. സർവർ അതിന്റെ സർട്ടിഫിക്കറ്റും കീയും സൂക്ഷിക്കുന്നു, ക്ലയന്റ് CA വിശ്വാസവും ഹോസ്റ്റ്നാമ പരിശോധനകളും സൂക്ഷിക്കുന്നു, അവ ഒരു വ്യാജനുമായി സംസാരിക്കുന്നതിൽ നിന്ന് അതിനെ തടയുന്നു. ക്ലയന്റിന് ഇനി സർട്ടിഫിക്കറ്റില്ല എന്ന കാരണത്താൽ remote-cert-tls server അല്ലെങ്കിൽ CA ബണ്ടിൽ നീക്കം ചെയ്യുന്നത് സാധാരണവും ഗുരുതരവുമായ തെറ്റായ വായനയാണ്, രണ്ട് ദിശകളും സ്വതന്ത്രമാണെന്ന് 2.6 റഫറൻസ് വ്യക്തമാക്കുന്നു. ഒന്ന് സർവറിനെ ക്ലയന്റിന് തെളിയിക്കുന്നു; മറ്റൊന്ന് ക്ലയന്റിനെ സർവറിന് തെളിയിക്കുന്നു.

പ്രൊഫൈലിന് tls-auth അല്ലെങ്കിൽ tls-crypt ബ്ലോക്കും ഉണ്ടായിരിക്കാം. അത് സ്വന്തം വിതരണ, ഭ്രമണ ചക്രമുള്ള പങ്കിട്ട നിയന്ത്രണ ചാനൽ കീയാണ്, അതിനാൽ സർട്ടിഫിക്കറ്റോ കീ വരികളോ ഇല്ലാത്ത ഫയൽ പ്രസിദ്ധീകരിക്കാൻ സ്വയമേവ സുരക്ഷിതമല്ല. നിങ്ങൾ അത് വായിക്കുന്നതുവരെ രഹസ്യമായി കണക്കാക്കുക.

പ്രവർത്തിക്കുന്ന പ്രൊഫൈലിൽ നിന്ന് പകർത്തിയ സർട്ടിഫിക്കറ്റ് ഫയൽ അതിൽത്തന്നെ ഒന്നും തെളിയിക്കുന്നില്ല; ഉടമസ്ഥത എന്നാൽ അതിന് യോജിക്കുന്ന സ്വകാര്യ കീ കൈവശം വയ്ക്കുക എന്നതാണ്, അത് സർട്ടിഫിക്കറ്റ് പ്രാമാണീകരണമുള്ള വിന്യാസം പരിശോധിക്കുന്നു. സർട്ടിഫിക്കറ്റ് അടങ്ങിയ ഫയൽ അതുകൊണ്ട് പ്രാമാണീകരിക്കാവുന്ന ഫയലല്ല.

സ്ഥിരീകരണക്കാരൻ എന്ത് ചെയ്യണം

സർട്ടിഫിക്കറ്റ് ആവശ്യകത നീക്കിയാൽ എല്ലാം സ്ഥിരീകരണക്കാരനെ ആശ്രയിച്ചിരിക്കുന്നു: ഒരു പ്ലഗിൻ, അല്ലെങ്കിൽ auth-user-pass-verify നിയന്ത്രിക്കുന്ന ഒരു സ്ക്രിപ്റ്റ്. അസാധുവായ ക്രെഡൻഷ്യലുകൾ നിരസിക്കണം, നിഷ്ക്രിയമോ അയോഗ്യമോ ആയ അക്കൗണ്ടുകൾ നിരസിക്കണം, അതിന്റെ ബാക്കെൻഡിൽ എത്താൻ കഴിയാത്തപ്പോൾ അടഞ്ഞ നിലയിൽ പരാജയപ്പെടണം. username-as-common-name പലപ്പോഴും കൂടെ സജീവമാക്കുന്നു, അത് പിന്നീടുള്ള കോൾബാക്കുകളും ഓരോ ക്ലയന്റിന്റെയും കോൺഫിഗറേഷൻ ഫയലുകളും കാണുന്ന ഐഡന്റിറ്റി മാറ്റുന്നു. അത് പാസ്വേഡ് പരിശോധിക്കുന്നില്ല, അയോഗ്യമായ അക്കൗണ്ടിനെ യോഗ്യമാക്കുന്നുമില്ല. അവ വെവ്വേറെ ജോലികളാണ്, അവ കൂട്ടിക്കലർത്തുന്നതാണ് ഒരു മൈഗ്രേഷൻ സന്തുഷ്ട പാതയുടെ പരീക്ഷയിൽ വിജയിച്ച് അതിന്റെ ആദ്യ യഥാർത്ഥ സംഭവത്തിൽ പരാജയപ്പെടുന്ന രീതി.

നെഗറ്റീവ് കേസുകൾ പോസിറ്റീവ് കേസിനോളം ശ്രദ്ധയോടെ പരിശോധിക്കുക. പാസ്വേഡ് അഭ്യർത്ഥന കാണിക്കുന്ന പ്രൊഫൈൽ ക്ലയന്റിന് അഭ്യർത്ഥന വരയ്ക്കാമെന്ന് മാത്രം തെളിയിക്കുന്നു, അതേസമയം തെറ്റായ പാസ്വേഡ് സ്വീകരിക്കുന്ന സർവർ വളരെ മോശമായ എന്തോ തെളിയിക്കുന്നു. പരീക്ഷണ ഗണത്തിൽ മോശം പാസ്വേഡ് മാത്രമല്ല, നിഷ്ക്രിയ അക്കൗണ്ടും കാലഹരണപ്പെട്ട ക്രെഡൻഷ്യലും ചേർക്കുക.

നയവും പ്രൊഫൈലും മാപ്പിംഗും ഒരുമിച്ച് മാറ്റുക

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

ഈ പാതയ്ക്ക് രണ്ട് പരീക്ഷണ അക്കൗണ്ടുകൾ സൂക്ഷിക്കുക, ഒന്ന് സാധുവും ഒന്ന് അറിയപ്പെടുന്ന മോശവും, സ്ഥിരീകരണക്കാരനിൽ ഏതെങ്കിലും മാറ്റത്തിന് ശേഷം രണ്ടും ഉപയോഗിക്കുക. സാധുവായ അക്കൗണ്ട് സന്തുഷ്ട പാതയും ഐഡന്റിറ്റി മാപ്പിംഗും തെളിയിക്കുന്നു; മോശമായത് നിരസിക്കൽ ഇപ്പോഴും പ്രവർത്തിക്കുന്നു എന്ന് തെളിയിക്കുന്നു. ഒരു പരീക്ഷയും യോഗ്യതാ നിയമങ്ങളെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, അതിനാൽ വിന്യാസത്തിൽ അത്തരം നിയമങ്ങളുണ്ടെങ്കിൽ നയപരമായ കാരണങ്ങളാൽ നിരസിക്കേണ്ട അക്കൗണ്ട് ചേർക്കുക. ഓരോ മാറ്റത്തിനും ശേഷം മൂന്നും പ്രവർത്തിപ്പിക്കുക, കാരണം എല്ലാം സ്വീകരിക്കാൻ തുടങ്ങുന്ന സ്ഥിരീകരണക്കാരൻ പ്രവർത്തിക്കുന്ന ലോഗിൻ പോലെ തന്നെ കാണപ്പെടുന്നു.

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