NetworkManager-ൽ OpenConnect-ന്റെ TOTP അഭ്യർത്ഥന കാണുന്നില്ല: നാല് പരിശോധനകൾ

ഗേറ്റ്വേ പാസ്വേഡ് സ്വീകരിക്കുന്നു, കോഡ് ആവശ്യപ്പെടുന്നു, എന്നാൽ ഡയലോഗിൽ അതിന് ഒരു ഫീൽഡുമില്ല. ഒന്നും തെറ്റായി ടൈപ്പ് ചെയ്തിട്ടില്ല: NetworkManager പ്ലഗിൻ ആറ് അക്ക മൂല്യം ആവശ്യപ്പെടാതെ രഹസ്യ കൈമാറ്റം പൂർത്തിയാക്കി. താഴെയുള്ള നാല് പരിശോധനകൾ ക്രമത്തിൽ ചെയ്യുക, കാരണം അവയിൽ ഒന്ന് മാത്രമാണ് ക്ലയന്റിനെ മാറ്റുന്നത്. ബാക്കി പട്ടിക ഗേറ്റ്വേ, അക്കൗണ്ട്, പ്ലഗിൻ ബിൽഡ് എന്നിവ ഒഴിവാക്കുന്നു.

ആദ്യ പരിശോധന: പ്രാമാണീകരണം എവിടെ നിന്നുവെന്ന് വായിക്കുക

തെറ്റായ പാസ്വേഡ് ഉടനടി പരാജയപ്പെടുന്നു. ഇല്ലാത്ത രണ്ടാം ഘടകം ക്രെഡൻഷ്യൽ ഘട്ടത്തിന് ശേഷം പരാജയപ്പെടുന്നു, സാധാരണയായി ആവർത്തിച്ചുള്ള അഭ്യർത്ഥനയോടെയോ ഗേറ്റ്വേ വശത്ത് സമയപരിധി കഴിഞ്ഞോ. സമയവും ഗേറ്റ്വേ ലോഗും ഏത് റൗണ്ട് ഉത്തരമില്ലാതെ തുടർന്നുവെന്ന് കാണിക്കുന്നു.

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

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

രണ്ടാം പരിശോധന: വെല്ലുവിളി ഉള്ള ക്ലയന്റ് ഉപയോഗിക്കുക

OpenConnect തന്നെ വെല്ലുവിളി റൗണ്ട് ഉൾപ്പെടെ മുഴുവൻ സംഭാഷണവും നടപ്പാക്കുന്നു. അത് നേരിട്ട് പ്രവർത്തിപ്പിക്കുന്നതാണ് അക്കൗണ്ടും ഗേറ്റ്വേയും പ്രവർത്തിക്കുന്നുവെന്ന് ഉറപ്പാക്കാനുള്ള ഏറ്റവും പ്രവചനാത്മകമായ വഴി:

sudo openconnect --protocol=anyconnect --useragent=AnyConnect vpn.example.net

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

കമാൻഡ് ലൈൻ ശരിയായി ചോദിച്ചാൽ, അക്കൗണ്ട്, ഗേറ്റ്വേ, രണ്ടാം ഘടകം എന്നിവ കൃത്യമാണ്. ബാക്കിയുള്ള പ്രശ്നം പ്ലഗിന്റെ ഡയലോഗാണ്, പ്രാമാണീകരണ സേവനമല്ല. ഇത് സർവറിനെ തൊടാതെ കേടായ ഘടകത്തെ വേർതിരിക്കുന്നു. കമാൻഡിന്റെ ഔട്ട്പുട്ട് സംഭവ രേഖയോടൊപ്പം സൂക്ഷിക്കുക.

കമാൻഡ് ലൈനും അഭ്യർത്ഥന ഒഴിവാക്കിയാൽ, നിർത്തി ഗേറ്റ്വേ കോൺഫിഗറേഷൻ അതിന്റെ ഉടമയോടൊപ്പം പരിശോധിക്കുക. സർവർ ഒരിക്കലും അയക്കാത്ത വെല്ലുവിളിക്ക് ഏത് ഡെസ്ക്ടോപ്പ് ക്ലയന്റും ഉത്തരം നൽകാനാവില്ല.

മൂന്നാം പരിശോധന: നിങ്ങളുടെ പ്ലഗിൻ TOTP മോഡ് നൽകുന്നുണ്ടോയെന്ന് നോക്കുക

ചില NetworkManager OpenConnect ബിൽഡുകൾ കണക്ഷന്റെ Identity ടാബിൽ ടോക്കൺ മോഡും ഉപയോക്തൃ ഏജന്റ് ഫീൽഡും നൽകുന്നു. ഉപയോക്തൃ ഏജന്റ് ഗേറ്റ്വേ പ്രതീക്ഷിക്കുന്ന മൂല്യത്തിൽ സജ്ജമാക്കുക, സ്വമേധയാ TOTP ഇൻപുട്ട് തിരഞ്ഞെടുക്കുക, കണക്ഷൻ സംരക്ഷിക്കുക.

ഈ ഫീൽഡുകൾ ഉണ്ടോയെന്നത് പ്ലഗിൻ പതിപ്പും ഡെസ്ക്ടോപ്പ് ഏത് കണക്ഷൻ എഡിറ്റർ ഉപയോഗിക്കുന്നു എന്നതും അനുസരിച്ചിരിക്കുന്നു. സ്വതന്ത്ര എഡിറ്റർ GNOME പാനൽ മറയ്ക്കുന്ന ഓപ്ഷനുകൾ കാണിച്ചേക്കാം, അല്ലെങ്കിൽ നേരെ മറിച്ചും. മറഞ്ഞ ക്രമീകരണം തിരയുന്നതിന് മുമ്പ് ഇൻസ്റ്റാൾ ചെയ്ത പാക്കേജിന്റെ പതിപ്പ് പരിശോധിക്കുക.

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

നാലാം പരിശോധന: സൃഷ്ടിച്ച കോഡിനെ ഒരു വിട്ടുവീഴ്ചയായി കാണുക

നിലവിലെ കോഡിനായി ഒരു സ്ക്രിപ്റ്റ് oathtool വിളിക്കുകയും ഉപയോക്തൃനാമം, പാസ്വേഡ്, കോഡ് എന്നിവ nmcli connection up --ask ലേക്ക് കൈമാറുകയും ചെയ്യാം. ക്രമം പ്രവർത്തിക്കുന്നു, പക്ഷേ പങ്കിട്ട രഹസ്യം സ്ക്രിപ്റ്റ് തുറക്കാൻ കഴിയുന്ന ആർക്കും വായിക്കാവുന്ന ഇടത്ത് സംഭരിക്കപ്പെടുന്നു, ആ വായനക്കാരന് എന്നെന്നേക്കുമായി കോഡുകൾ സൃഷ്ടിക്കാം. ഇത് ക്രെഡൻഷ്യൽ ഉപരിതലത്തിന്റെ സ്ഥിരമായ വികാസമാണ്, ക്ലയന്റ് പരിഹാരമല്ല.

ഇത് തിരഞ്ഞെടുക്കുന്ന ആൾ രഹസ്യ ഫയൽ root-ലേക്ക് പരിമിതപ്പെടുത്തണം, സൃഷ്ടിച്ച മൂല്യങ്ങൾ ഷെൽ ചരിത്രത്തിന് പുറത്ത് സൂക്ഷിക്കണം, സ്ക്രിപ്റ്റിനെ ക്രെഡൻഷ്യൽ വസ്തുവായി കാണണം. കോഡ് ടെർമിനലിലേക്ക് പ്രതിധ്വനിപ്പിക്കുന്ന റാപ്പർ രണ്ടാം ഘടകം വലിച്ചെറിയുന്നു. ആദ്യം താൽക്കാലിക അക്കൗണ്ടുപയോഗിച്ച് റാപ്പർ പരീക്ഷിക്കുക.

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

അതേ ഗേറ്റ്വേയും അക്കൗണ്ടും ഉറപ്പാക്കുക

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

പ്രവർത്തിച്ച ക്ലയന്റ്, അതിന്റെ പതിപ്പ്, ഉപയോക്തൃ ഏജന്റ്, അഭ്യർത്ഥന ക്രമം എന്നിവ രേഖപ്പെടുത്തുക. ആ രേഖ അടുത്ത വ്യക്തിക്ക് പ്രശ്നം പ്ലഗിൻ ബിൽഡിലാണോ, ഗേറ്റ്വേ ഒഴുക്കിലാണോ, അക്കൗണ്ട് നയത്തിലാണോ എന്ന് പാസ്വേഡ് റീസെറ്റിന്റെ മറ്റൊരു റൗണ്ട് കൂടാതെ പറയുന്നു.

പൂർണ്ണ ലോഗൗട്ടിന് ശേഷം ഒരിക്കൽ വീണ്ടും കണക്ട് ചെയ്ത് അവസാനിപ്പിക്കുക. കാഷ് ചെയ്ത രഹസ്യം തകർന്ന ഒഴുക്കിനെ അടുത്ത സെഷൻ വരെ ശരിയാക്കിയതായി കാണിച്ചേക്കാം, രണ്ടാം കണക്ഷനിലാണ് കാണാതായ അഭ്യർത്ഥന സാധാരണയായി മടങ്ങുന്നത്.