OpenVPN ലോഗിനിൽ സ്റ്റാറ്റിക് ചലഞ്ച് കോഡ് എവിടെ പോകുന്നു

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

നിങ്ങളുടെ ക്ലയന്റ് യഥാർത്ഥത്തിൽ കാണിക്കുന്ന പ്രോംപ്റ്റിൽ നിന്ന് തുടങ്ങുക

ഒരു പ്രൊഫൈലിന് പ്രോംപ്റ്റ് സ്ട്രിംഗും നിങ്ങൾ ടൈപ്പ് ചെയ്യുമ്പോൾ ഉത്തരം കാണിക്കണോ എന്ന് നിയന്ത്രിക്കുന്ന ഫ്ലാഗും ഉള്ള സ്റ്റാറ്റിക് ചലഞ്ച് നിർദ്ദേശം വഹിക്കാം. ഡയലോഗിൽ നിങ്ങൾ കാണുന്നതാണ് പ്രോംപ്റ്റ്; അതേ ഇൻപുട്ടിനുള്ള പ്രദർശന മുൻഗണനയാണ് ഫ്ലാഗ്. രണ്ടും സെർവറിനോട് എന്തെങ്കിലും എങ്ങനെ പരിശോധിക്കണമെന്ന് പറയുന്നില്ല.

യഥാർത്ഥത്തിൽ നിങ്ങൾക്ക് നൽകിയ ഫീൽഡുകൾ എണ്ണുക. ഉപയോക്തൃനാമത്തിന് ഒരു ഫീൽഡും ഒരു മറച്ച ഫീൽഡും ചേർന്നത് ഒരു ചലഞ്ചും ഇല്ലാത്ത സാധാരണ പാസ്‌വേർഡ് ലോഗിനാണ്. പാസ്‌വേർഡിന് ശേഷം സ്വന്തം ലേബലോടെ വരുന്ന രണ്ടാമത്തെ ഫീൽഡ് ക്ലയന്റ് ചലഞ്ച് ഇടപെടൽ നടപ്പിലാക്കുന്നതാണ്.

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

സെർവർ ഇതിനകം പിന്തുണയ്ക്കേണ്ടത്

ക്ലയന്റ് എന്ത് ശേഖരിക്കണമെന്ന് പ്രൊഫൈൽ വിവരിക്കുന്നു. അത് സെർവറിൽ പരിശോധന പ്രവർത്തനക്ഷമമാക്കുന്നില്ല, ബന്ധപ്പെട്ട പ്രാമാണീകരണ സംയോജനം ഇല്ലാത്ത സെർവർ തിരിച്ചറിയാത്ത ഒരു പാസ്‌വേർഡ് മാത്രം സ്വീകരിക്കും. അതുകൊണ്ടാണ് ചില വിന്യാസങ്ങൾ പ്രോംപ്റ്റ് കാണിച്ച് ഓരോ കോഡും നിരസിക്കുന്നത്, ഏത് സംവിധാനമാണ് പരിശോധന നടത്തുന്നതെന്ന ഓപ്പറേറ്ററുടെ ഉത്തരമാണ് പ്രധാനമെന്നതും അതുകൊണ്ടാണ്.

ഏത് സംവിധാനമാണ് പരിശോധന നടത്തുന്നതെന്ന് ഓപ്പറേറ്ററോട് ചോദിക്കുക. PAM-മായി സംസാരിക്കുന്ന ഒരു പ്ലഗിൻ, ടോക്കൺ സേവനത്തിനെതിരെ ഉത്തരം സാധൂകരിക്കുന്ന ഒരു സ്ക്രിപ്റ്റ് ഹുക്ക്, അല്ലെങ്കിൽ ഒതുക്കിയ മൂല്യം സ്വയം വിശകലനം ചെയ്യുന്ന ഒരു മാനേജ്മെന്റ് അധിഷ്ഠിത സംയോജനം ആകാം. ഓരോന്നും അൽപ്പം വ്യത്യസ്തമായ ഇൻപുട്ട് പ്രതീക്ഷിക്കുന്നു.

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

മാനേജ്മെന്റ് ഇന്റർഫേസ് അയയ്ക്കുന്ന എൻകോഡ് ചെയ്ത ഫീൽഡ്

ഒരു ഫ്രണ്ട് എൻഡ് മാനേജ്മെന്റ് ഇന്റർഫേസ് വഴി കണക്ഷൻ നയിക്കുമ്പോൾ, സമർപ്പിക്കുന്നതിന് മുൻപ് പാസ്‌വേർഡും ചലഞ്ച് ഉത്തരവും ഒരു മൂല്യത്തിൽ ഒതുക്കുന്നു. മാനേജ്മെന്റ് ഇന്റർഫേസ് റഫറൻസ് ഫോർമാറ്റ് രേഖപ്പെടുത്തുന്നു: ഒരു പ്രിഫിക്സ്, തുടർന്ന് വേർതിരിച്ച Base64 ഘടകങ്ങളായി പാസ്‌വേർഡും ഉത്തരവും.

Base64 ഒരു എൻകോഡിംഗാണ്, സംരക്ഷണമല്ല. ഫീൽഡ് വായിക്കാൻ കഴിയുന്ന ആരിൽ നിന്നും അത് ഒന്നും മറയ്ക്കുന്നില്ല, ഒരു തവണത്തെ കോഡിനെ വീണ്ടും ഉപയോഗിക്കാവുന്നതാക്കി മാറ്റുന്നുമില്ല. ഒതുക്കിയ മൂല്യം പാസ്‌വേർഡിന് അർഹമായ അതേ പെരുമാറ്റത്തിന് അർഹമാണ്: പങ്കിട്ട പ്രൊഫൈലുകളിൽ നിന്ന് പുറത്ത്, കമാൻഡ് ലൈനുകളിൽ നിന്ന് പുറത്ത്, ഡയഗ്നോസ്റ്റിക് ലോഗുകളിൽ നിന്ന് പുറത്ത്.

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

സ്റ്റാറ്റിക്, ഡൈനാമിക്: വ്യത്യസ്ത സമയം

ആദ്യ ക്രെഡൻഷ്യൽ സമർപ്പിക്കുന്നതിന് മുൻപേ സ്റ്റാറ്റിക് ചലഞ്ച് അറിയാം, അതിനാൽ ക്ലയന്റിന് അത് മുൻകൂട്ടി ചോദിക്കാം. ഡൈനാമിക് ചലഞ്ച് പിന്നീട് വരുന്നു, കൈമാറ്റം ഇതിനകം തുടങ്ങിയ ശേഷം പ്രാമാണീകരണ പ്രവാഹം അത് അയയ്ക്കുന്നു, സംഭാഷണത്തിന് നടുവിൽ വരുന്ന അഭ്യർത്ഥന കൈകാര്യം ചെയ്യാൻ കഴിയുന്ന ക്ലയന്റ് അതിന് ആവശ്യമാണ്.

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

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

വിജയവും പരാജയവും പരിശോധിക്കുക, ഡയലോഗ് മാത്രമല്ല

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

തുടർന്ന് വീണ്ടും ബന്ധിപ്പിച്ചതിന് ശേഷം, രജിസ്റ്റർ ചെയ്യാത്ത അക്കൗണ്ടോടെ, നിങ്ങളുടെ ഉപയോക്താക്കൾ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന ക്ലയന്റിലൂടെ കണക്ഷൻ ആവർത്തിക്കുക. പ്രോംപ്റ്റ് കാണുന്നത് ക്ലയന്റിന്റെ സ്വഭാവമാണ്; തെറ്റായ കോഡ് നിരസിക്കപ്പെടുന്നത് സെർവർ എന്തോ നടപ്പിലാക്കുന്നതാണ്.