ഗേറ്റ്വേ സർട്ടിഫിക്കറ്റ് കുഴപ്പമില്ല: IKEv2 PEAP ലോഗിൻ ഇപ്പോഴും പരാജയപ്പെടുന്നത് എന്തുകൊണ്ട്

നിങ്ങളുടെ VPN ഗേറ്റ്വേയുടെ സർട്ടിഫിക്കറ്റ് സാധുവാണ്, ചെയിൻ സാധൂകരിക്കപ്പെടുന്നു, എന്നിട്ടും IKEv2 ക്ലയന്റ് സർട്ടിഫിക്കറ്റിന്റെ സാധുതാ കാലയളവിനെക്കുറിച്ചുള്ള സന്ദേശത്തോടെ ലോഗിൻ നിരസിക്കുന്നു. ആദ്യ പ്രവണത ഗേറ്റ്വേ സർട്ടിഫിക്കറ്റ് വീണ്ടും നൽകുകയോ EAP രീതി മാറ്റുകയോ ചെയ്യുകയാണ്, രണ്ടും സാധാരണയായി തെറ്റാണ്. ലോഗിൻ ശ്രമം രണ്ട് വേറിട്ട സെർവർ ഐഡന്റിറ്റികൾ വഹിക്കുന്നു: IKE ഉപയോഗിക്കുന്ന ഗേറ്റ്വേ സർട്ടിഫിക്കറ്റും, PEAP അവസാനിപ്പിക്കുന്നത് അവതരിപ്പിക്കുന്ന സർട്ടിഫിക്കറ്റും. അവയിൽ ഒന്ന് കുഴപ്പമില്ല, മറ്റൊന്നാണ് ക്ലയന്റ് നിന്നതിന്റെ കാരണം.

രണ്ട് ഐഡന്റിറ്റികൾ, ഒരു ലോഗിൻ ശ്രമം

VPN പ്രൊഫൈലിലെ സർട്ടിഫിക്കറ്റ് IKE കൈമാറ്റത്തിനുള്ളതാണ്: കോൺഫിഗർ ചെയ്ത IKE നയപ്രകാരം ഗേറ്റ്വേ പ്രൊഫൈൽ പേരിടുന്ന പങ്കാളിയാണെന്ന് അത് തെളിയിക്കുന്നു. ഇവിടെ പരാജയപ്പെടുന്ന സർട്ടിഫിക്കറ്റ് മറ്റൊരു സംഭാഷണത്തിനുള്ളതാണ്, അതായത് ഉപയോക്താവിനെ പ്രാമാണീകരിക്കുന്നയാളുമായി PEAP തുറക്കുന്ന TLS സെഷന്, അത് പലപ്പോഴും ഗേറ്റ്വേ തന്നെയല്ല, NPS പോലുള്ള RADIUS സെർവറാണ്. മൂന്നാമത്തെ പരിശോധനയായ ഉപയോക്തൃ ക്രെഡൻഷ്യലുകൾ ആ സെഷനുള്ളിൽ നടക്കുന്നു. സാധുവായ ഒരു പാസ്വേഡിന് കാലഹരണപ്പെട്ട സെർവർ സർട്ടിഫിക്കറ്റ് നന്നാക്കാനാവില്ല, സാധുവായ ഗേറ്റ്വേ സർട്ടിഫിക്കറ്റിന് PEAP അന്തിമ ബിന്ദുവിന് ഉറപ്പ് നൽകാനാവില്ല.

ഈ പാളിവിന്യാസം, ആരും കോൺഫിഗർ ചെയ്ത ഒരേയൊരു സർട്ടിഫിക്കറ്റ് ഗേറ്റ്വേയുടേത് മാത്രമായിരുന്നിടത്ത് സർട്ടിഫിക്കറ്റ് പിശക് എന്തുകൊണ്ട് പ്രത്യക്ഷപ്പെടുന്നു എന്ന് വിശദീകരിക്കുന്നു. അതേ സർട്ടിഫിക്കറ്റ് വീണ്ടും നൽകുന്നത് എന്തുകൊണ്ട് ഒന്നും മാറ്റുന്നില്ല എന്നും വിശദീകരിക്കുന്നു.

ലോഗ് വരി ഘട്ടവുമായി ചേർത്ത് വായിക്കുക

കാരണവും തീയതികളും പേരിടുന്ന സന്ദേശം കണ്ടെത്തുക. വിഷയ പിശകിന് അരികിൽ സാധുതാ കാലയളവിനെക്കുറിച്ചുള്ള പരാതി എന്നാൽ സെർവർ തനിക്ക് നൽകിയ സർട്ടിഫിക്കറ്റ് നിരസിച്ചു, ഉപയോക്താവ് ലോഗിൻ നിരസിച്ചു എന്നല്ല. പിന്നീട് ഘട്ടം കണ്ടെത്തുക: strongSwan ന്റെ charon ലോഗ് EAP കൈമാറ്റം ആരംഭിക്കുന്നതിന് മുമ്പ് IKE_SA .* established കാണിക്കുന്നു, അതിനാൽ ആ വരിക്ക് ശേഷമുള്ള സർട്ടിഫിക്കറ്റ് പിശക് EAP ഐഡന്റിറ്റിയുടേതാണ്, അതിന് മുമ്പുള്ള പിശക് ഗേറ്റ്വേയെ ചൂണ്ടുന്നു. Windows ക്ലയന്റിന്റെ കണക്ഷൻ പാനലിലെ ഘട്ട പാഠവും അതുതന്നെ പറയുന്നു.

ഏതെങ്കിലും സർട്ടിഫിക്കറ്റിൽ തൊടുന്നതിന് മുമ്പ് ക്ലയന്റിന്റെ ഘടികാരം പരിശോധിക്കുക. മണിക്കൂറുകൾ വ്യതിചലിച്ച ഉപകരണം യഥാർത്ഥത്തിൽ കാലഹരണപ്പെട്ട സർട്ടിഫിക്കറ്റിന്റെ അതേ സാധുതാ പിശക് നൽകുന്നു. ഘടികാരം ശരിയാക്കുന്നത് അഞ്ച് സെക്കൻഡ് തിരുത്തലാണ്, ഒരിക്കലും പ്രശ്നമല്ലാതിരുന്ന സർട്ടിഫിക്കറ്റ് മാറ്റുന്നത് തടസ്സമാണ്.

PEAP അവസാനിപ്പിക്കുന്നത് ഏത് അന്തിമ ബിന്ദുവാണെന്ന് കണ്ടെത്തുക

ഗേറ്റ്വേയും RADIUS ഉം ഉള്ള രൂപകൽപ്പനയിൽ ഗേറ്റ്വേ EAP കൈമാറുന്നു, അത് അവസാനിപ്പിക്കുന്നില്ല. strongSwan ന്റെ eap-radius പ്ലഗിൻ കൈമാറ്റം RADIUS സെർവറിന് നൽകുന്നു, PEAP TLS സെഷനും അതിന്റെ സർട്ടിഫിക്കറ്റും അതിനാണ്. രണ്ട് ലോഗുകളിലും ഒരു പരാജയ ശ്രമം ബന്ധിപ്പിച്ച്, ആ സെഷന് യഥാർത്ഥത്തിൽ ഏത് പ്രക്രിയ സർട്ടിഫിക്കറ്റ് തിരഞ്ഞെടുത്തു എന്ന് സ്ഥിരീകരിക്കുക.

NPS ന് സർട്ടിഫിക്കറ്റ് ലോക്കൽ കമ്പ്യൂട്ടർ സ്റ്റോറിൽ ഉണ്ടായിരിക്കണം, സെർവർ പ്രാമാണീകരണ ഉദ്ദേശ്യം വഹിക്കണം, ക്ലയന്റുകൾ പ്രതീക്ഷിക്കുന്ന പേരുമായി പൊരുത്തപ്പെടണം, സേവന അക്കൗണ്ടിന് വായിക്കാനാകണം. NPS നുള്ള Microsoft ന്റെ സർട്ടിഫിക്കറ്റ് ആവശ്യകതകൾ ആ വ്യവസ്ഥകൾ പട്ടികപ്പെടുത്തുന്നു. മറ്റ് EAP സെർവറുകൾക്ക് സ്വന്തം തിരഞ്ഞെടുപ്പ് നിയമങ്ങളുണ്ട്, അതിനാൽ NPS ന്റെ പ്രത്യേകതകൾ FreeRADIUS വിന്യാസത്തിലേക്കോ തിരിച്ചോ പകർത്തരുത്. രണ്ട് സാഹചര്യങ്ങളിലും നിലനിൽക്കുന്ന നിയമം, PEAP അവസാനിപ്പിക്കുന്ന അന്തിമ ബിന്ദു നിങ്ങൾ മാറ്റാൻ പോകുന്ന സർട്ടിഫിക്കറ്റിന്റെ ഉടമയാണ് എന്നതാണ്.

EAP അവസാനിക്കുന്നിടത്ത് സർട്ടിഫിക്കറ്റ് മാറ്റുക

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

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

ഒരു ഡയറക്ടറിയിലെ ഏറ്റവും പുതിയ ഫയലാണ് ഉപയോഗിക്കുന്നതെന്ന് കരുതരുത്. ശരിയായ പേരും തെറ്റായ അനുമതികളും ഉള്ള പകർപ്പ് ഒന്നും മാറ്റുന്നില്ല. മാറ്റം ഫയലിന്റെ ടൈംസ്റ്റാമ്പ് കൊണ്ടല്ല, അവതരിപ്പിച്ച ഐഡന്റിറ്റി കൊണ്ട് വിലയിരുത്തുക.

എന്ത് ചെയ്യരുത്

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

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