IKEv2 സെർവർ വിലാസം vs ഐഡൻ്റിറ്റി: ക്ലയൻ്റ് യഥാർത്ഥത്തിൽ എന്താണ് പരിശോധിക്കുന്നത്

വിലാസം മാറ്റുന്ന ഒരു ഗേറ്റ്വേയ്ക്ക് പ്രവർത്തിക്കുന്നത് തുടരാം, ഒരു പുതിയ സർട്ടിഫിക്കറ്റിന് പിന്നിലുള്ള അതേ ഗേറ്റ്വേ നിർത്തുന്നു, വിപരീതവും സംഭവിക്കുന്നു. പാക്കറ്റുകൾ എവിടെ അയയ്ക്കണമെന്ന് വിലാസം ക്ലയൻ്റിനോട് പറയുന്നു; ആധികാരിക ഐഡൻ്റിറ്റി ക്ലയൻ്റിനോട് ഉത്തരം പറയുന്നയാളാണോ വിശ്വസിക്കേണ്ടത് എന്ന് പറയുന്നു. IKEv2 അവയെ രണ്ട് വ്യത്യസ്ത ഫീൽഡുകളായി നിലനിർത്തുന്നു, നിങ്ങൾ അവയെ ഒരു സ്ട്രിംഗായി കണക്കാക്കുന്നത് നിർത്തിയാൽ ഇത് ഉപയോഗപ്രദമാകും. അവയും വ്യത്യസ്ത സ്ഥലങ്ങളിൽ ക്രമീകരിച്ചിരിക്കുന്നു, അതിനാൽ ഒന്ന് ശരിയാകുമ്പോൾ മറ്റൊന്ന് തെറ്റാണ്.

ഈ ക്രമത്തിൽ അവ പരിശോധിക്കുകയും ആദ്യ പൊരുത്തക്കേടിൽ നിർത്തുകയും ചെയ്യുക, കാരണം പിന്നീടുള്ള പരിശോധനകൾ മുമ്പത്തെവ പാസായതായി അനുമാനിക്കുന്നു.

ആദ്യം, ഏത് മൂല്യമാണ് വിലാസം

ക്ലയൻ്റ് ഡയൽ ചെയ്യുന്നതെന്തും കണക്ഷൻ വിലാസമാണ്: ഒരു ഐപി, ഒന്നിലേക്ക് പരിഹരിക്കുന്ന ഒരു DNS പേര് അല്ലെങ്കിൽ ഒരു ലോഡ്-ബാലൻസ്ഡ് ഫ്രണ്ട് എൻഡ്. അത് ഗതാഗത വിവരങ്ങളാണ്, അതിൽ കൂടുതലൊന്നുമില്ല. IKEv2 ഐഡി പേലോഡിൽ ഐഡൻ്റിറ്റി റൈഡ് ചെയ്യുകയും പിന്നീട് പിയർ സർട്ടിഫിക്കറ്റുമായി പൊരുത്തപ്പെടുകയും ചെയ്യുന്നു. വിലാസ ബോക്സിലെ ഒരു DNS പേര് പ്രതീക്ഷിക്കുന്ന ഐഡൻ്റിറ്റിയായി മാറുന്നില്ല, കൂടാതെ സോക്കറ്റ് കണക്റ്റുചെയ്തിരിക്കുന്നതിനാൽ ഒരു റോ ഐപി ഐഡൻ്റിറ്റിയായി മാറുന്നില്ല.

strongSwan നിബന്ധനകളിൽ, വിലാസം right അല്ലെങ്കിൽ left ആണ്, പ്രതീക്ഷിക്കുന്ന ഐഡൻ്റിറ്റി rightid അല്ലെങ്കിൽ leftid ആണ്, അതാണ് IKEv2 കോൺഫിഗറേഷൻ ഡോക്യുമെൻ്റേഷൻ വിവരിക്കുന്നത്. നിങ്ങൾ എപ്പോഴെങ്കിലും വിലാസം എഡിറ്റ് ചെയ്തിട്ടുണ്ടെങ്കിൽ, ജോഡിയുടെ പകുതി നിങ്ങൾ ക്രമീകരിച്ചു.

രണ്ടാമതായി, സർട്ടിഫിക്കറ്റിന് എന്ത് തെളിയിക്കാനാകും

ഐഡൻ്റിറ്റിക്ക് ഒരു തരം ഉണ്ട്, സർട്ടിഫിക്കറ്റിൽ പൊരുത്തപ്പെടുന്ന പേര് ഉണ്ടായിരിക്കണം. ഒരു DNS ഐഡൻ്റിറ്റി, സബ്ജക്റ്റ് ഇതര നാമ വിപുലീകരണത്തിലെ ഒരു dNSName എൻട്രി വഴി തൃപ്തിപ്പെടുത്തുന്നു; ഒരു IP ഐഡൻ്റിറ്റിക്ക് ഒരു iPAddress എൻട്രി ആവശ്യമാണ്. vpn.example.com എന്നതിനായി നൽകിയ ഒരു സർട്ടിഫിക്കറ്റ് അക്ഷരീയ വിലാസത്തെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല 203.0.113.10, കൂടാതെ ആ വിലാസത്തിനായി നൽകിയത് പേരിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. അതിനാൽ ഒരേ കീയും CA ഉം വീണ്ടും ഉപയോഗിക്കുമ്പോൾ പോലും, മറ്റൊരു പേരിനായി വീണ്ടും ഇഷ്യൂ ചെയ്യുന്നത് ഡ്രോപ്പ്-ഇൻ പകരം വയ്ക്കലല്ല.

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

മൂന്നാമതായി, ഓരോ ക്ലയൻ്റും പ്രതീക്ഷകൾ എങ്ങനെ പ്രസ്താവിക്കുന്നു

Windows നിങ്ങൾ ടൈപ്പ് ചെയ്ത സെർവറിൻ്റെ പേരോ വിലാസമോ എടുക്കുന്നു, അതിനോട് പൊരുത്തപ്പെടുന്നതിന് സർട്ടിഫിക്കറ്റ് ആവശ്യമാണ്, അതിനാൽ ഒരു IP ടൈപ്പുചെയ്യുന്നത് ഒരു IP പ്രതീക്ഷ സൃഷ്ടിക്കുന്നു. Android ൻ്റെ IKEv2 ക്ലയൻ്റ് ഒരേ രീതിയിൽ പെരുമാറുന്നു, കൂടാതെ മറ്റൊരു ഹോസ്റ്റിനെ പേരുനൽകുന്ന സാധുവായ, പൊതുവായി വിശ്വസനീയമായ ഒരു സർട്ടിഫിക്കറ്റ് ഇരുവരും നിരസിക്കുന്നു. ഒരു മൈഗ്രേഷൻ സമയത്ത് ആരെങ്കിലും ഹോസ്റ്റ് നെയിം അതിൻ്റെ വിലാസം ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിച്ചതിനാൽ ഒരു പ്രൊഫൈൽ പരാജയപ്പെടാൻ തുടങ്ങും. സർട്ടിഫിക്കറ്റിൽ എന്താണ് അടങ്ങിയിരിക്കുന്നതെന്ന് നോക്കുന്നതിന് മുമ്പ് ക്ലയൻ്റ് എന്താണ് ആവശ്യപ്പെട്ടതെന്ന് നോക്കുക.

strongSwan-ൽ പ്രതീക്ഷ വ്യക്തമാണ്: സെർവർ യഥാർത്ഥത്തിൽ അവതരിപ്പിക്കുന്ന ഐഡൻ്റിറ്റിയിലേക്ക് rightid സജ്ജീകരിക്കുക, അത് വലതുവശത്ത് നിന്ന് വ്യത്യസ്തമായിരിക്കാം. ഇത് %any ആയി സജ്ജീകരിക്കുന്നത് പിയർ ഓഫർ ചെയ്യുന്നതെന്തും സ്വീകരിക്കുകയും നിങ്ങൾ സൂക്ഷിക്കാൻ ശ്രമിക്കുന്ന ചെക്ക് കൃത്യമായി നീക്കം ചെയ്യുകയും ചെയ്യുന്നു.

നാലാമതായി, പിയർ ഐഡൻ്റിറ്റിയിൽ നിന്ന് ഉപയോക്തൃ ലോഗിൻ വേർതിരിക്കുക

EAP പ്രാമാണീകരണവും സെർവർ ഐഡൻ്റിറ്റിയും വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു. സെർവറാണ് ശരിയെന്ന് ക്ലയൻ്റ് തീരുമാനിച്ചതിന് ശേഷം, [email protected] പോലെയുള്ള ഒരു EAP ഐഡൻ്റിറ്റി, ഉപയോക്താവ് ആരാണെന്ന് പറയുന്നു. ആ പാസ്വേഡ് തിരിക്കുന്നതിലൂടെ പിയർ ഐഡൻ്റിറ്റി പൊരുത്തക്കേട് പരിഹരിക്കാൻ കഴിയില്ല, കാരണം കണക്ഷൻ ഒരിക്കലും ഉപയോക്തൃ-ലോഗിൻ ഘട്ടത്തിൽ എത്തില്ല.

ഒരു സാനിറ്റൈസ്ഡ് റിപ്പോർട്ട് രണ്ടിനും പേരിടണം: ക്ലയൻ്റ് പ്രതീക്ഷിച്ച ഐഡൻ്റിറ്റി, സെർവർ അവതരിപ്പിച്ച ഐഡൻ്റിറ്റി, സർട്ടിഫിക്കറ്റിൻ്റെ SAN എൻട്രികൾ.

അഞ്ചാമതായി, പരിശോധിച്ചുറപ്പിച്ച ചാനലിലൂടെ അത് മാറ്റുക

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

പ്രൊഫൈൽ കുറിപ്പുകളിൽ അവസാന വിലാസം, ഐഡൻ്റിറ്റി, SAN ലിസ്റ്റ് എന്നിവ ഒരുമിച്ച് രേഖപ്പെടുത്തുക. അടുത്തതായി സർട്ടിഫിക്കറ്റിൽ തൊടുന്നയാൾ മൂവരിൽ ആരെയാണ് നീക്കാൻ അനുവദിക്കുന്നതെന്ന് കാണും.