IKEv2 കൈമാറ്റം പ്രവർത്തിക്കുന്നു, പിന്നീട് പ്രമാണീകരണം പരാജയപ്പെടുന്നു: എവിടെ നോക്കണം

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

പരിശോധന 1: സന്ദേശമല്ല, ഘട്ടം വായിക്കുക

നിരസിക്കൽ മൂന്ന് സ്ഥലങ്ങളിൽ നിന്ന് വരാം: സെർവറിന്റെ ഐഡന്റിറ്റി നിരസിക്കുന്ന ക്ലയന്റ്, ക്ലയന്റിന്റെ തെളിവ് നിരസിക്കുന്ന ഗേറ്റ്വേ, അക്കൗണ്ട് നിരസിക്കുന്ന ബാഹ്യ പ്രമാണീകരണ സേവനം.

ഓരോന്നും വ്യത്യസ്ത യന്ത്രത്തിൽ വ്യത്യസ്ത ലോഗ് വരി ഉണ്ടാക്കുന്നു, ഓരോന്നിനും വ്യത്യസ്ത പരിഹാരമുണ്ട്. ക്ലയന്റ് ഭാഗത്ത് സെർവർ സർട്ടിഫിക്കറ്റ് നിരസിക്കുന്നത് ക്ലയന്റിലെ വിശ്വാസമോ നാമകരണമോ പ്രശ്നമാണ്; ഗേറ്റ്വേ ഭാഗത്ത് ക്ലയന്റ് സർട്ടിഫിക്കറ്റ് നിരസിക്കുന്നത് ഗേറ്റ്വേയിലെ വിശ്വാസ പ്രശ്നമാണ്; EAP പരാജയം അക്കൗണ്ടോ ബാക്ക്എൻഡോ പ്രശ്നമാണ്. നിങ്ങൾ കാണുന്ന സന്ദേശം സാധാരണയായി അവയിലൊന്നിനെക്കുറിച്ചുള്ള ക്ലയന്റിന്റെ സംഗ്രഹമാണ്, അതുകൊണ്ടാണ് ഗേറ്റ്വേ ലോഗ് ക്ലയന്റിന്റെ ലോഗിനോളം പ്രധാനമായിരിക്കുന്നത്.

പരിശോധന 2: ഏത് ഐഡന്റിറ്റിയാണ് പരിശോധിച്ചത്

ഉപയോക്തൃ ക്രെഡൻഷ്യലുകൾ വാഗ്ദാനം ചെയ്യുന്നതിന് മുമ്പ് തന്നെ ക്ലയന്റിന് സെർവറിന്റെ സർട്ടിഫിക്കറ്റോ പ്രതീക്ഷിക്കുന്ന ഐഡന്റിറ്റിയോ നിരസിക്കാം, പ്രവർത്തിക്കുന്ന സെർവർ വിലാസം ആ പരിശോധനയ്ക്ക് പകരമല്ല. ക്ലയന്റ് പ്രതീക്ഷിക്കുന്ന ഐഡന്റിഫയർ ഗേറ്റ്വേ അവതരിപ്പിക്കുന്നതുമായി പൊരുത്തപ്പെടണം, ഇത് നെറ്റ്വർക്ക് വസ്തുതയല്ല, കോൺഫിഗറേഷൻ വസ്തുതയാണ്.

strongSwan പദങ്ങളിൽ അത് ക്ലയന്റിൽ rightid ഉം മറുവശത്ത് ഗേറ്റ്വേയുടെ സ്വന്തം ഐഡന്റിറ്റിയും ആണ്, EAP ചർച്ച ചെയ്യുന്നതിന് മുമ്പ് തന്നെ പൊരുത്തക്കേട് പരാജയപ്പെടുന്നു.

ഗേറ്റ്വേക്ക് വെവ്വേറെ ക്ലയന്റിന്റെ സർട്ടിഫിക്കറ്റോ അതിന്റെ കീ തെളിവോ അതിന്റെ അക്കൗണ്ട് പ്രമാണീകരണമോ നിരസിക്കാം, ഈ മൂന്നും പരസ്പരം മാറ്റാനാവില്ല. ഉപയോക്താവിന്റെ പാസ്വേഡ് പുനഃസജ്ജമാക്കുന്നത് ഉപകരണ സർട്ടിഫിക്കറ്റ് പുതുക്കുന്നില്ല, ഉപകരണ സർട്ടിഫിക്കറ്റ് വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നത് തെറ്റായ സെർവർ ഐഡന്റിറ്റി ശരിയാക്കുന്നുമില്ല. സർട്ടിഫിക്കറ്റ് പരാജയങ്ങൾക്ക് ആദ്യം ക്ലോക്ക്, പിന്നീട് വിശ്വാസ ശൃംഖല, ഒടുവിൽ പ്രതീക്ഷിക്കുന്ന ഐഡന്റിഫയർ എന്നിവ പരിശോധിക്കുക; ഏതാനും മിനിറ്റ് വ്യത്യാസമുള്ള ക്ലോക്കുള്ള ക്ലയന്റ് വിശ്വാസ പരാജയമായി തോന്നുന്ന സാധുതാ പരിശോധനയിൽ പരാജയപ്പെടുന്നു. swanctl --list-certs ഇരുവശത്തും ഓരോ വശവും യഥാർത്ഥത്തിൽ എന്താണ് കൈവശം വയ്ക്കുന്നതെന്ന് കാണിക്കുന്നു.

പരിശോധന 3: EAP ഉൾപ്പെട്ടിട്ടുണ്ടെങ്കിൽ

ക്ലയന്റും സെർവറും പിന്തുണയ്ക്കുന്ന ഒരു രീതിയിൽ യോജിക്കണം, ബാക്ക്എൻഡ് നൽകിയ ഐഡന്റിറ്റി സ്വീകരിക്കണം.

ഉപയോക്തൃനാമത്തിന് ഡൊമെയ്ൻ സഫിക്സോ വിന്യാസം ആവശ്യപ്പെടുന്ന ഒരു നിർദ്ദിഷ്ട അക്കൗണ്ട് ഫോർമാറ്റോ ആവശ്യമായേക്കാം, ഫോർമാറ്റ് ഊഹിക്കാവുന്നതല്ല, രേഖപ്പെടുത്തിയിട്ടുള്ളതാണ്. ഓപ്പറേറ്ററുടെ രേഖപ്പെടുത്തിയ ഫീൽഡുകൾ നൽകുന്നത് വ്യതിയാനങ്ങൾ പരീക്ഷിക്കുന്നതിനേക്കാൾ വേഗമേറിയതാണ്, രണ്ടാമത്തെ പ്രശ്നവും ഒഴിവാക്കുന്നു: ആവർത്തിച്ചുള്ള ശ്രമങ്ങൾ അക്കൗണ്ട് ലോക്കൗട്ട് ഉണ്ടാക്കാം, അത് പിന്നീട് യഥാർത്ഥ ഘട്ടത്തെ പുതിയ പരാജയത്തിന് പിന്നിൽ മറയ്ക്കുന്നു. രീതി ഒരു ഡയറക്ടറിക്കെതിരെ EAP-MSCHAPv2 ആണെങ്കിൽ, പരാജയം VPNന്റേതല്ല, ഡയറക്ടറിയുടേതായിരിക്കാം.

ഐഡന്റിറ്റി പരിശോധനകൾ അപ്രാപ്തമാക്കി ഐഡന്റിറ്റി പ്രശ്നങ്ങൾ പരിശോധിക്കരുത്. അത് രോഗനിർണയം ചെയ്യാവുന്ന പരാജയത്തെ രോഗനിർണയം ചെയ്യാനാവാത്തതാക്കി മാറ്റുകയും കണക്ഷൻ മുമ്പത്തേക്കാൾ ദുർബലമായി വിടുകയും ചെയ്യുന്നു.

പരിശോധന 4: വിജയകരമായ ലോഗിൻ കഴിഞ്ഞ് എന്ത് സംഭവിക്കുന്നു

IKE_AUTH പൂർത്തിയായാൽ, ഏത് ട്രാഫിക് സെലക്ടറുകൾ ഇൻസ്റ്റാൾ ചെയ്യണമെന്ന് CHILD_SA ചർച്ച തീരുമാനിക്കുന്നു, അവിടെയാണ് കണക്ഷൻ വിജയിച്ചിട്ടും ഒന്നും കടത്തിവിടാതിരിക്കാവുന്നത്.

പുതുതായി പ്രവർത്തിക്കുന്ന ലോഗിൻ മുമ്പ് പ്രമാണീകരണ പരാജയത്തിന് പിന്നിൽ മറഞ്ഞിരുന്ന സെലക്ടർ അല്ലെങ്കിൽ റൂട്ട് പ്രശ്നം പലപ്പോഴും വെളിപ്പെടുത്തുന്നു. ടണൽ ഉയർന്നിട്ടും ഒരു ആപ്ലിക്കേഷൻ അതിന്റെ ലക്ഷ്യത്തിൽ എത്തുന്നില്ലെങ്കിൽ, വീണ്ടും ഐഡന്റിറ്റിയല്ല, ചർച്ച ചെയ്ത സെലക്ടറുകളും റൂട്ടുകളും നോക്കുക. അപ്പോൾ ഐഡന്റിറ്റി ക്രമീകരണങ്ങൾ മാറ്റുന്നത് തെറ്റായ ഘട്ടത്തെ ലക്ഷ്യം വയ്ക്കുന്നു, സാധാരണയായി പ്രവർത്തിക്കുന്ന ലോഗിൻ തകർക്കുന്നു. swanctl --list-sas ഉപയോഗിച്ച് സ്ഥിരീകരിക്കുക, ഇത് IKE SAയിൽ നിന്ന് വേറിട്ട് ചിൽഡ്രനെയും അവയുടെ സെലക്ടറുകളെയും കാണിക്കുന്നു.

പരിശോധന 5: പിന്തുണയ്ക്ക് എന്ത് നൽകണം

വൃത്തിയാക്കിയ സമയരേഖയും കൃത്യമായ നിരസിക്കലും പൂർണ്ണ രോഗനിർണയ കയറ്റുമതിയേക്കാൾ മൂല്യമുള്ളതാണ്, കയറ്റുമതിയിൽ പങ്കിടരുതാത്ത സ്വകാര്യ കീകളോ ക്രെഡൻഷ്യലുകളോ ഉണ്ടായിരിക്കാം.

സമയ മേഖലയോടെ സമയം, ക്ലയന്റ്, ഗേറ്റ്വേ പതിപ്പുകൾ, രീതി, പാസ്വേഡിന് പകരം നൽകിയ ഐഡന്റിറ്റി സ്ട്രിംഗ്, അത് നിരസിച്ച കൃത്യമായ ഘട്ടം എന്നിവ രേഖപ്പെടുത്തുക. strongSwan IKEv2 കോൺഫിഗറേഷൻ ഡോക്യുമെന്റേഷൻ ഈ ഫലങ്ങൾ തീരുമാനിക്കുന്ന ഐഡന്റിറ്റി, EAP ക്രമീകരണങ്ങൾ വിവരിക്കുന്നു, ഒരു ഫീൽഡ് മാറ്റുന്നതിന് മുമ്പ് വായിക്കേണ്ട റഫറൻസ് അതാണ്. പിന്നീട് ഒരു കാര്യം മാറ്റി പുതിയ കണക്ഷൻ വീണ്ടും പരിശോധിക്കുക, കാരണം കാഷ് ചെയ്ത സെഷൻ പഴയ കോൺഫിഗറേഷനെക്കുറിച്ച് നിങ്ങളോട് പറയും.