RADIUS Access-Challenge-ന് ശേഷം VPN ലോഗിൻ നിലയ്ക്കുന്നു

നിങ്ങളുടെ പാസ്‌വേഡ് ശരിയാണ്, എന്നിട്ടും VPN ലോഗിൻ പരാജയപ്പെടുന്നു, RADIUS സെർവർ തന്നോട് പറഞ്ഞത് കൃത്യമായി ചെയ്തിരിക്കാം. ഗേറ്റ്‌വേ ഒരു Access-Challenge സ്വീകരിച്ചു, ഉപയോഗപ്രദമായി ഒന്നും കാണിച്ചില്ല, തുടർന്ന് സമയം കഴിഞ്ഞു അല്ലെങ്കിൽ ആ ഉത്തരം നിരസനമായി കണക്കാക്കി. ക്ലയന്റ് വശത്തുനിന്ന് ഇത് തെറ്റായ ക്രെഡൻഷ്യലുകൾ അല്ലെങ്കിൽ തകർന്ന ടണൽ പോലെ തോന്നുന്നു. കാരണം സാധാരണയായി ആരും പകർത്താത്ത സംഭാഷണത്തിന്റെ മധ്യത്തിലാണ്.

ഒരു ലോഗിൻ, രണ്ട് RADIUS കൈമാറ്റങ്ങൾ

ബാക്കെൻഡിന് രണ്ടാമത്തെ ഘടകം വേണമ്പോൾ, അത് ആദ്യ അഭ്യർത്ഥനയ്ക്ക് സ്വീകാര്യതയോ നിരസനമോ നൽകി ഉത്തരം നൽകുന്നില്ല. അത് കോഡ് 11 നൽകി ഉത്തരം നൽകുകയും ഉപയോക്താവിന്റെ അടുത്ത പ്രതികരണത്തിനായി കാത്തിരിക്കുകയും ചെയ്യുന്നു; ഗേറ്റ്‌വേ അത് തുടർച്ചാ അഭ്യർത്ഥനയിൽ തിരികെ അയയ്ക്കണം. ആ തുടർച്ചാ അഭ്യർത്ഥന അതേ പ്രാമാണീകരണ സംഭാഷണത്തിന്റെതാണ്, പുതിയ ലോഗിൻ ശ്രമത്തിന്റെതല്ല.

പ്രവർത്തിക്കുന്ന ക്രമീകരണത്തിൽ ഉപയോക്താവിന് രണ്ടാമത്തെ പ്രോംപ്റ്റ് കാണാം: ആദ്യം പാസ്‌വേഡ്, പിന്നെ ഒരു തവണ മാത്രം ഉപയോഗിക്കുന്ന കോഡ്, അല്ലെങ്കിൽ ഓപ്പറേറ്റർ രേഖപ്പെടുത്തിയിട്ടുണ്ടെങ്കിൽ ഒരു സംയുക്ത പ്രോംപ്റ്റ്. തകർന്ന ക്രമീകരണത്തിൽ രണ്ടാമത്തെ പ്രോംപ്റ്റ് ഒരിക്കലും വരുന്നില്ല, ലോഗിൻ വെറുതെ പരാജയപ്പെടുന്നു.

ഇതാണ് പിന്തുടരേണ്ട ലക്ഷണം, ക്ലയന്റ് വശത്തുനിന്ന് മാത്രം ഇത് സ്ഥിരീകരിക്കാൻ എളുപ്പമാണ്: VPN ക്ലയന്റ് കൃത്യം ഒരു രഹസ്യം മാത്രം ചോദിച്ച്, നിങ്ങൾക്ക് സാധുവെന്ന് അറിയാവുന്ന പാസ്‌വേഡ് നിരസിക്കുന്നുവെങ്കിൽ, കൈമാറ്റം ചലഞ്ചിൽ അവസാനിച്ചിരിക്കാം.

ചലഞ്ച് യഥാർത്ഥത്തിൽ എന്താണ് വഹിക്കുന്നത്

RADIUS സ്പെസിഫിക്കേഷൻ വിഭാഗം 4.4-ൽ കോഡ് 11 വിവരിക്കുകയും ഇവിടെ പ്രധാനമായ രണ്ട് ആട്രിബ്യൂട്ടുകൾ അനുവദിക്കുകയും ചെയ്യുന്നു. Reply-Message ഉപയോക്താവിനുള്ള ടെക്സ്റ്റ് സൂക്ഷിക്കുന്നു, State സെർവർ തിരികെ ലഭിക്കാൻ ആഗ്രഹിക്കുന്ന അതാര്യമായ മൂല്യം സൂക്ഷിക്കുന്നു. NAS State വ്യാഖ്യാനിക്കരുത്, മാറ്റമില്ലാതെ തിരികെ നൽകണം.

തുടർച്ചാ അഭ്യർത്ഥന പുതിയ Identifier-ഉം പുതിയ Request Authenticator-ഉം ഉപയോഗിക്കുന്നു, അതേ State മൂല്യവും ഉപയോക്താവിന്റെ പ്രതികരണവും വഹിക്കണം. സെർവർ അതിനെ ആ State വഴി കാത്തിരിക്കുന്ന ചലഞ്ചുമായി ചേർക്കുന്നു, അതുകൊണ്ടാണ് ആട്രിബ്യൂട്ട് വീണ്ടും സൃഷ്ടിക്കുന്നതോ ഒഴിവാക്കുന്നതോ ആയ ഗേറ്റ്‌വേ ഈ ചടങ്ങ് പൂർത്തിയാക്കാൻ കഴിയാത്തത്. ഓരോ ഉത്തരത്തിലെയും response authenticator സാധുവാക്കണം, അല്ലെങ്കിൽ NAS പാക്കറ്റ് വലിച്ചെറിയണം.

വിഭാഗം 4.4 മിക്ക നിശബ്ദ പരാജയങ്ങളും വിശദീകരിക്കുന്ന വിവരം ചേർക്കുന്നു: ചലഞ്ചുകൾ പിന്തുണയ്ക്കാൻ കഴിയാത്ത NAS Access-Challenge-നെ നിരസനമായി കണക്കാക്കുന്നു. നിങ്ങളുടെ ഗേറ്റ്‌വേയുടെ VPN സേവനം ആ പിന്തുണയേക്കാൾ പഴയതാണെങ്കിൽ അല്ലെങ്കിൽ അത് ഒഴിവാക്കുന്നുവെങ്കിൽ, ബാക്കെൻഡിന്റെ രണ്ടാം ഘടക അഭ്യർത്ഥന ഒരു പ്രോംപ്റ്റുമില്ലാതെ തൽക്ഷണ «പ്രാമാണീകരണം പരാജയപ്പെട്ടു» ആയി മാറുന്നു.

ചങ്ങലയായ അഭ്യർത്ഥന എവിടെ നഷ്ടപ്പെടുന്നു

ആദ്യ സംശയം ക്രെഡൻഷ്യലുകളല്ല, പ്രോംപ്റ്റിന്റെ പാതയാണ്. വെബ് ലോഗിനുകൾക്ക് OTP ഫീൽഡ് കാണിക്കുന്ന പോർട്ടൽ VPN സേവനത്തിന് സ്വയമേവ അത് ചെയ്യുന്നില്ല, ചില ഗേറ്റ്‌വേകൾ ആ കഴിവ് പ്രഖ്യാപിക്കുന്ന ക്ലയന്റുകൾക്ക് മാത്രം ചലഞ്ച് കൈമാറുന്നു. അതേ അക്കൗണ്ട് രണ്ട് പ്രവേശന കേന്ദ്രങ്ങളിലും പരീക്ഷിക്കുക; പോർട്ടൽ പ്രവർത്തിക്കുകയും VPN പ്രവർത്തിക്കാതിരിക്കുകയും ചെയ്യുന്നുവെങ്കിൽ, നിങ്ങൾ കൈമാറ്റമാണ് കാണുന്നത്, ടോക്കൺ അല്ല.

ഇൻപുട്ട് ഫോർമാറ്റാണ് രണ്ടാമത്തെ സംശയം. വിൽപ്പനക്കാരൻ രേഖപ്പെടുത്തിയ വേർതിരിക്കൽ ഇല്ലാതെ പാസ്‌വേഡും കോഡും ചേർക്കുന്നതോ സംഭരിച്ച ക്രെഡൻഷ്യലുകളെ പഴയ കോഡ് വീണ്ടും പ്ലേ ചെയ്യാൻ അനുവദിക്കുന്നതോ തെറ്റായ പാസ്‌വേഡിനോട് സമാനമായി തോന്നുന്ന പരാജയമാണ്. ഓപ്പറേറ്റർ രേഖപ്പെടുത്തിയ വേർതിരിച്ച പ്രോംപ്റ്റോ സംയുക്ത ഫോർമാറ്റോ ഉപയോഗിക്കുക, സ്വയം ഒരു വേർതിരിക്കൽ കണ്ടുപിടിക്കരുത്.

റിലീസ്-നിർദ്ദിഷ്ട തകരാറുകൾ നിലവിലുണ്ട്, എന്നാൽ വർഷങ്ങൾക്ക് മുമ്പ് പരിഹരിച്ച പതിപ്പുകളുടെ പട്ടിക ഇന്നത്തെ വിന്യാസത്തിനുള്ള രോഗനിർണയമല്ല. നിങ്ങൾ യഥാർത്ഥത്തിൽ പ്രവർത്തിപ്പിക്കുന്ന സോഫ്റ്റ്‌വെയറിന്റെ റിലീസ് കുറിപ്പുകൾ വായിക്കുക, നിരീക്ഷിച്ച കൈമാറ്റ ഘട്ടം തെളിവായി സൂക്ഷിക്കുക.

ഒരു ശ്രമം ആദ്യം മുതൽ അവസാനം വരെ ട്രേസ് ചെയ്യുക

സെർവർ-സൈഡ് ഡീബഗ്ഗിംഗ് ഓണാക്കി ഒരിക്കൽ പുനർനിർമ്മിക്കുക, മറ്റെല്ലാ സെഷനുകളും ക്യാപ്ചർ വിൻഡോയ്ക്ക് പുറത്ത് നിർത്തുക:

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

ഔട്ട്പുട്ടിൽ ഒരു വരിയല്ല, സംഭാഷണത്തിന്റെ ആകൃതി തിരയുക. Identifier 3-ഉള്ള ആദ്യ Access-Request, State വഹിക്കുന്ന Access-Challenge, തുടർന്ന് ആ State ആവർത്തിച്ച് ഉപയോക്താവിന്റെ പ്രതികരണം ഉൾക്കൊള്ളുന്ന Identifier 4-ഉള്ള രണ്ടാമത്തെ Access-Request. രണ്ടാമത്തെ അഭ്യർത്ഥന ഇല്ലെങ്കിൽ, ഗേറ്റ്‌വേ ഒരിക്കലും തുടർന്നിട്ടില്ല. State ഇല്ലാതെ വന്നാൽ, സെർവർക്ക് അതിനെ കാത്തിരിക്കുന്ന ചലഞ്ചുമായി ചേർക്കാൻ കഴിയില്ല, സാധാരണയായി നിരസിക്കും.

ട്രേസ് പങ്കുവയ്ക്കുമ്പോൾ ക്രെഡൻഷ്യലുകൾ, ടോക്കണുകൾ, അനാവശ്യമായ ഐഡന്റിറ്റി ഡാറ്റ എന്നിവ മറയ്ക്കുക, നിരവധി ബ്രൗസർ ടാബുകളിലെ വീണ്ടും ശ്രമങ്ങൾ കലർത്തുന്നതിനുപകരം ഒരു ശ്രമത്തിലെ സംഭവങ്ങൾ പരസ്പരം ബന്ധിപ്പിക്കുക. ടൈംസ്റ്റാമ്പുകൾ ഇവിടെ നിങ്ങളുടെ സുഹൃത്താണ്; ക്ലയന്റ് കൈവിട്ടതിനുശേഷം വരുന്ന ചലഞ്ച് ഉപയോക്താവിന് നിരസനമായും ലോഗിൽ സാവധാന ഉത്തരമായും തോന്നുന്നു.

നിങ്ങൾ ആഗ്രഹിക്കുന്ന അന്തിമ അവസ്ഥ പൂർത്തിയായ, അംഗീകരിക്കപ്പെട്ട സംഭാഷണവും തുടർന്നുള്ള ഉദ്ദേശിത സേവന പ്രവേശനവുമാണ്. RADIUS സെർവറിൽ നിന്ന് വരുന്ന ഒരു ഉത്തരം അതിനേക്കാൾ വളരെ കുറച്ചേ തെളിയിക്കുന്നുള്ളൂ.