.ovpn ഫയൽ എഡിറ്റ് ചെയ്യുന്നത് സെർവറിൽ MFA ഓണാക്കാൻ കഴിയാത്തത് എന്തുകൊണ്ട്

ഒരു പ്രൊഫൈലിൽ auth-user-pass ചേർത്ത് വീണ്ടും കണക്ട് ചെയ്യുമ്പോൾ ക്ലയന്റ് ഉപയോക്തൃനാമവും പാസ്വേഡും ആവശ്യപ്പെടുന്നു. MFA ഓണായതുപോലെ തോന്നുന്നു. പിന്നെ തെറ്റായ അക്കൗണ്ടിലെ കോഡോ, പത്ത് മിനിറ്റ് മുമ്പ് കാലഹരണപ്പെട്ട കോഡോ നൽകിയാലും ടണൽ ഉയരുന്നു. ഇതാണ് ലക്ഷണം: ക്ലയന്റ് മാറി, സെർവർ മാറിയില്ല. സെർവറിലെ ഒരു സ്ഥിരീകരണക്കാരൻ അത് ആവശ്യപ്പെടുന്ന ഐഡന്റിറ്റിക്ക് സാധുവാണോ എന്ന് തീരുമാനിക്കുമ്പോൾ മാത്രമാണ് ഒറ്റത്തവണ പാസ്വേഡ് ഒരു ഘടകമാകുന്നത്.

ക്ലയന്റ് ചോദിച്ചു എന്ന് മാത്രമാണ് അഭ്യർത്ഥന തെളിയിക്കുന്നത്, അതിൽ കൂടുതലില്ല

.ovpn ഫയൽ ക്ലയന്റ് വശത്തെ രേഖയാണ്. ക്ലയന്റിനോട് ക്രെഡൻഷ്യലുകൾ ആവശ്യപ്പെടാനും, അവ കാഷ് ചെയ്യാനും, അല്ലെങ്കിൽ അത് നിർത്താനും അതിന് പറയാം. എന്നാൽ ഉപയോക്താവിനെ രജിസ്റ്റർ ചെയ്യാനോ, PAM മൊഡ്യൂൾ ഇൻസ്റ്റാൾ ചെയ്യാനോ, സെർവർ ഇപ്പോൾ പരിശോധിക്കാത്ത രണ്ടാം ഘടകം ആവശ്യപ്പെടാൻ പ്രേരിപ്പിക്കാനോ അതിന് കഴിയില്ല.

ഫോണിൽ ഒരു ഓതന്റിക്കേഷൻ ആപ്പ് ഇൻസ്റ്റാൾ ചെയ്യുന്നതും ആ ബന്ധം സൃഷ്ടിക്കുന്നില്ല. Google Authenticator PAM പ്രോജക്ട് OTP സ്ഥിരീകരണ ഘടകമാണ്, അത് OpenVPN ന്റെ പിന്നിൽ ഇരിക്കാം; ഇറക്കുമതി ചെയ്ത പ്രൊഫൈലിൽ Google അക്കൗണ്ട് ലോഗിൻ ഒട്ടിക്കാനുള്ള വഴിയല്ല അത്.

ഒരു പ്രൊഫൈലിന് ചെയ്യാൻ കഴിയാത്ത ഭാഗമാണ് രജിസ്ട്രേഷൻ

TOTP-ക്ക് ഓതന്റിക്കേഷൻ ആപ്പും അതിന്റെ സ്ഥിരീകരണക്കാരനും ഇടയിൽ പങ്കിടുന്ന രജിസ്ട്രേഷൻ വസ്തു ആവശ്യമാണ്. ഫോണിലെ ആറ് അക്കങ്ങൾ ഔട്ട്പുട്ടാണ്; അവയ്ക്ക് പിന്നിലെ വിത്താണ് രഹസ്യം, അത് ഒരു ഐഡന്റിറ്റിയുടേതാണ്.

അതിനാൽ ഓപ്പറേറ്റർക്ക് ശരിയായ വിത്തിനെ ശരിയായ VPN ഐഡന്റിറ്റിയുമായി ബന്ധിപ്പിക്കുന്ന രജിസ്ട്രേഷൻ പ്രക്രിയ ആവശ്യമാണ്, കൂടാതെ നഷ്ടപ്പെട്ട ഫോണിനുള്ള സ്ഥിരീകരിച്ച പകരം വഴി യും വേണം. ഉപയോക്താക്കളെ അവരുടെ പേരിലുള്ള ഫയൽ അപ്ലോഡ് ചെയ്യാൻ അനുവദിക്കുന്നത് രജിസ്ട്രേഷനെ അക്കൗണ്ട് കൈയടക്കാനുള്ള അവസരമാക്കി മാറ്റുന്നു, അപ്ലോഡ് എൻക്രിപ്റ്റ് ചെയ്യുന്നത് അത് മാറ്റുന്നില്ല.

PAM അടിസ്ഥാനമാക്കിയുള്ള രൂപകൽപ്പന ഓരോ VPN ഉപയോക്താവിനും പ്രത്യേക Unix അക്കൗണ്ട് സൃഷ്ടിക്കേണ്ടതില്ല. മൊഡ്യൂളിന്റെ ഡോക്യുമെന്റേഷൻ ഇതര രഹസ്യ പാതകളും ഫയൽ പ്രവേശനത്തിനായി സമർപ്പിച്ച അക്കൗണ്ടും പിന്തുണയ്ക്കുന്നു, അത് ഫയൽസിസ്റ്റം ഐഡന്റിറ്റിയാണ്, പരിശോധിക്കുന്ന ലോഗിൻ ഐഡന്റിറ്റിയല്ല.

സാധാരണ തെറ്റ് ഒരു ഉപയോക്താവിന്റെ ഉദാഹരണത്തിൽ നിന്ന് പകർത്തിയ, ഒരു ഉപയോക്തൃനാമത്തിൽ അവസാനിക്കുന്ന സ്ഥിര രഹസ്യ പാതയാണ്. അത് ഒരു ഐഡന്റിറ്റിയുടെ പ്രദർശനമാണ്, ഓരോ ഉപയോക്താവിനുമുള്ള തിരയലല്ല, ഓരോ അഭ്യർത്ഥനയ്ക്കും അത് ഉപയോഗിക്കുന്നത് ആർക്കും സ്വതന്ത്രമായി രജിസ്റ്റർ ചെയ്ത ഓതന്റിക്കേഷൻ ആപ്പ് നൽകുന്നില്ല. ഐഡന്റിറ്റി മാപ്പിംഗ് എഴുതി വയ്ക്കുക, വിത്ത് ഫയലുകൾ സംരക്ഷിക്കുക, പാസ്വേഡ്, സർട്ടിഫിക്കറ്റ്, അക്കൗണ്ട് പരിശോധനകൾ ഒരേ ഓതന്റിക്കേഷൻ സ്റ്റാക്കിൽ നിർത്തുക.

PAM സ്റ്റാക്ക് വായിച്ച് യഥാർത്ഥത്തിൽ എന്താണ് ആവശ്യമെന്ന് നോക്കുക

account required pam_permit.so പോലുള്ള ഒരു വരി അക്കൗണ്ട് യോഗ്യത നടപ്പാക്കുന്നില്ല, ഘടകം ചേർക്കുന്നുമില്ല. അത് ആ PAM അക്കൗണ്ട് മാനേജ്മെന്റ് ഘട്ടം അനുവദിക്കുന്നു, അത് ഘട്ടത്തെക്കുറിച്ചുള്ള പ്രസ്താവനയാണ്, നിങ്ങളുടെ ഉപയോക്താക്കളെക്കുറിച്ചല്ല.

അനുവദനീയമായ രജിസ്ട്രേഷൻ ഓപ്ഷനുകൾക്കും ഇത് ബാധകമാണ്. രജിസ്റ്റർ ചെയ്ത രഹസ്യമില്ലാത്ത ഉപയോക്താക്കളെ സ്വീകരിക്കുന്നത് ബോധപൂർവമായ വിന്യാസ തീരുമാനമാകാം, പക്ഷേ അത് MFA നിർബന്ധമാണെന്നതിന്റെ തെളിവല്ല, അവസാന തീയതിയോടെ താൽക്കാലിക ഒഴിവാക്കലായി അത് രേഖപ്പെടുത്തണം.

ക്ലയന്റിന്റെ ഇടപെടൽ സെർവറിന്റെ രൂപകൽപ്പനയുമായി യോജിപ്പിക്കുക

auth-user-pass

ആ നിർദ്ദേശം ഉപയോക്തൃനാമവും പാസ്വേഡും ഇൻപുട്ട് ആവശ്യപ്പെടുന്നു. അത് PAM കോൺഫിഗർ ചെയ്യുന്നില്ല, രജിസ്ട്രേഷൻ റെക്കോർഡ് സൃഷ്ടിക്കുന്നില്ല, പാസ്വേഡ് ഫീൽഡിൽ TOTP മൂല്യമുണ്ടെന്ന് സെർവറിനോട് പറയുന്നുമില്ല. സെർവർ സംയോജനവും ക്ലയന്റും വിന്യാസം യഥാർത്ഥത്തിൽ പിന്തുണയ്ക്കുന്ന ഇടപെടലിൽ യോജിക്കണം: ഒരു ചലഞ്ച്, രേഖപ്പെടുത്തിയ സംയുക്ത ക്രെഡൻഷ്യൽ ഫോർമാറ്റ്, അല്ലെങ്കിൽ ഉൽപ്പന്ന-നിർദ്ദിഷ്ട ഫ്ലോ.

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

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

വീണ്ടും കണക്ട് ചെയ്യൽ, ടോക്കണുകൾ, വിഷയം തീർക്കുന്ന പരീക്ഷണം

ആദ്യ വിജയകരമായ ലോഗിനിന് ശേഷം എന്ത് സംഭവിക്കുമെന്ന് ആസൂത്രണം ചെയ്യുക. മുമ്പ് സ്വീകരിച്ച കോഡ് അടുത്ത ഓതന്റിക്കേഷനിൽ കാലഹരണപ്പെട്ടതോ ആവർത്തനമായി നിരസിക്കപ്പെട്ടതോ ആകാം. auth-nocache ക്രെഡൻഷ്യലുകൾ നിലനിർത്തുന്നത് നിയന്ത്രിക്കുന്നു, MFA ഇൻസ്റ്റാൾ ചെയ്യുന്നില്ല, reneg-sec 0 ഫോറം ത്രെഡുകളിൽ എത്ര തവണ കണ്ടാലും TOTP പിന്തുണയുടെ നിർവചനമല്ല.

ചില വിന്യാസങ്ങൾ പ്രാരംഭ പരിശോധനയ്ക്ക് ശേഷം ഓതന്റിക്കേഷൻ ടോക്കണുകൾ നൽകുന്നു, അതുവഴി വീണ്ടും കണക്ട് ചെയ്യുമ്പോൾ വീണ്ടും ചോദിക്കില്ല. അത് സ്വന്തം സാധുതാ വിൻഡോയും റദ്ദാക്കൽ കഥയുമുള്ള രൂപകൽപ്പന തീരുമാനമാണ്, നിങ്ങൾ പാരമ്പര്യമായി കിട്ടുന്ന ഡിഫോൾട്ടല്ല.

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