IKEv1 ന്റെ ഹൈബ്രിഡ് പ്രാമാണീകരണം IKEv2 ന്റെ ഉപയോക്തൃ പ്രാമാണീകരണത്തിലേക്ക് എങ്ങനെ മാറുന്നു
ഹൈബ്രിഡ് മോഡ് ഗേറ്റ്വേയുടെ തെളിവിനെ ഉപയോക്താവിന്റെ തെളിവിൽ നിന്ന് വേർതിരിച്ചു. IKEv2 ലേക്ക് മാറുമ്പോൾ ആ വേർതിരിവ് നിലനിൽക്കുന്നു, പക്ഷേ കൈമാറ്റവും EAP രീതിയും സർട്ടിഫിക്കറ്റ് പരിശോധനകളും മാറുന്നു.
ആദ്യം സെർവർ സർട്ടിഫിക്കറ്റും പിന്നീട് ഉപയോക്തൃനാമവും ആവശ്യപ്പെടുന്ന ഓരോ പഴയ VPN പ്രൊഫൈലും ഒരേ കൈമാറ്റത്തിൽ പ്രാമാണീകരണത്തിന്റെ രണ്ട് സംഭവങ്ങൾ വഹിക്കുന്നു, ഈ രൂപം അതിനെ കൊണ്ടുവന്ന പ്രോട്ടോക്കോളിനെക്കാൾ കൂടുതൽ കാലം ജീവിക്കുന്നു. IKEv1 ന്റെ ഹൈബ്രിഡ് മോഡ് കൃത്യമായി ഇതിനുവേണ്ടിയാണ് നിർമ്മിച്ചത്: ഗേറ്റ്വേ സ്വയം പൊതു കീ കൊണ്ട് തെളിയിക്കുന്നു, ഉപയോക്താവ് പിന്നീട് XAuth വഴി സ്വയം തെളിയിക്കുന്നു. IKEv2 അതേ രണ്ട് ഘട്ട ആശയം മറ്റൊരു യന്ത്രവ്യവസ്ഥ കൊണ്ട് പ്രകടിപ്പിക്കുന്നു, ഈ വ്യത്യാസങ്ങളിലാണ് കൈമാറ്റങ്ങൾ പരാജയപ്പെടുന്നത്. ഏത് പതിപ്പ് നമ്പറും ഒന്നിനെ മറ്റൊന്നാക്കി മാറ്റുന്നില്ല, പഴയ ഓപ്ഷൻ പേരുകൾ പുതിയ പ്രൊഫൈലിൽ പകർത്തുന്നത് ചർച്ച നടത്തി പിന്നീട് ഒന്നും പ്രാമാണീകരിക്കാത്ത ക്ലയന്റ് നൽകുന്നു.
ഹൈബ്രിഡ് മോഡ് IKEv1 നുള്ളിൽ എന്ത് ചെയ്തു
ഹൈബ്രിഡ് പ്രൊഫൈലിൽ പ്രതികരിക്കുന്ന കക്ഷി ആദ്യ ഘട്ട കൈമാറ്റത്തിൽ സ്വന്തം സർട്ടിഫിക്കറ്റ് കൊണ്ട് ഒപ്പിടുന്നു, ആരംഭിക്കുന്നയാൾ ബോധപൂർവ്വം ഒരു സർട്ടിഫിക്കറ്റും കാണിക്കുന്നില്ല. അതിനാൽ ഐഡന്റിറ്റി തെളിവ് അസമമിതമാണ്, ഇതാണ് ഗേറ്റ്വേയ്ക്ക് അതിന്റെ നിലവിലുള്ള PKI നിലനിർത്താനും ഉപയോക്താക്കൾക്ക് അവരുടെ ഡയറക്ടറി പാസ്വേഡുകൾ നിലനിർത്താനും അനുവദിച്ചത്. ആദ്യ ഘട്ടം പൂർത്തിയായാൽ XAuth അഭ്യർത്ഥനയും മറുപടിയുമായി പ്രവർത്തിക്കുന്നു, അവ ഇപ്പോൾ എൻക്രിപ്റ്റ് ചെയ്ത ISAKMP ചാനലിനുള്ളിൽ ഉപയോക്തൃനാമവും പാസ്വേഡും സവിശേഷതകൾ വഹിക്കുന്നു.
വിശ്വാസം എവിടെ വീഴുന്നു എന്ന് ശ്രദ്ധിക്കുക. ക്ലയന്റ് ഏത് ഗേറ്റ്വേയിൽ എത്തി എന്ന് സർട്ടിഫിക്കറ്റ് മറുപടി നൽകുന്നു; ഏത് ഉപയോക്താവിന് പ്രവേശനം വേണം എന്ന് XAuth മറുപടി നൽകുന്നു. ഒന്ന് മറ്റൊന്നിന് പകരമാകുന്നില്ല, ഏത് സെർവർ സർട്ടിഫിക്കറ്റും സ്വീകരിക്കാൻ ക്രമീകരിച്ച ക്ലയന്റ് ആദ്യ മറുപടി നിശ്ശബ്ദമായി വലിച്ചെറിഞ്ഞു. ഹൈബ്രിഡ് എന്ന ലേബൽ മുൻകൂട്ടി പങ്കിട്ട കീയോടു കൂടിയ ആക്രമണ മോഡിനും XAuth നും കൂടി ഉപയോഗിക്കുന്നു, അത് അതേ ഉപയോക്തൃാനുഭവമുള്ള മറ്റൊരു ക്രമീകരണമാണ്, അതിനാൽ പേരല്ല, പ്രൊഫൈൽ വായിക്കുക. രണ്ട് രൂപങ്ങളും ഒരിക്കലും മാനദണ്ഡമാകാത്ത കരടുകളിൽ നിന്ന് വരുന്നു, അതുകൊണ്ടാണ് രണ്ട് നിർമ്മാതാക്കൾക്ക് ഹൈബ്രിഡ് മോഡ് നടപ്പിലാക്കാനും ആരുമായും പരസ്പര പ്രവർത്തനം ഇല്ലാതിരിക്കാനും കഴിയുന്നത്.
IKEv2 അതേ രണ്ട് തെളിവുകളിൽ എങ്ങനെ എത്തുന്നു
IKEv2 ജോലി IKE_SA_INIT നും IKE_AUTH നും ഇടയിൽ വിഭജിക്കുന്നു. ആദ്യ കൈമാറ്റം ഒരു ഐഡന്റിറ്റിയും ഇല്ലാതെ നിർദ്ദേശങ്ങളും കീകളും സമ്മതിക്കുന്നു; രണ്ടാമത്തേത് IDi, IDr, AUTH പേലോഡുകൾ വഹിക്കുന്നു. EAP പ്രകാരം ആരംഭിക്കുന്നയാളുടെ ആദ്യ AUTH പേലോഡ് ശൂന്യമായി പോകുന്നു, പ്രതികരിക്കുന്ന കക്ഷി ആദ്യം സ്വന്തം സർട്ടിഫിക്കറ്റും ഒപ്പും കൊണ്ട് പ്രാമാണീകരിക്കപ്പെടുന്നു, പിന്നീട് EAP സംഭാഷണം IKE_AUTH സന്ദേശങ്ങൾക്കുള്ളിൽ നടക്കുന്നു.
ഇതിനെ സുരക്ഷിതമാക്കുന്ന യന്ത്രവ്യവസ്ഥ കീ മെറ്റീരിയലാണ്. വിജയകരമായ EAP രീതി ഒരു സെഷൻ കീ കയറ്റുമതി ചെയ്യുന്നു, ആരംഭിക്കുന്നയാളുടെ അവസാന AUTH പേലോഡ് അതിൽ നിന്ന് കണക്കാക്കുന്നു, അതിനാൽ ഉപയോക്താവിന്റെ തെളിവും ടണലിന്റെ കീകളും പരസ്പരം ബന്ധിക്കപ്പെടുന്നു. XAuth ന് അത്തരം തുല്യതയില്ല: അതിന്റെ സവിശേഷതകൾ ആദ്യ ഘട്ടത്തിന് ശേഷം വരുന്നു, കീകളിലേക്ക് ഒന്നും ചേർക്കുന്നില്ല. ഈ വിടവ് നികത്താനാണ് IKEv2 ചട്ടക്കൂട് രൂപകൽപ്പന ചെയ്തത്, അതുകൊണ്ടാണ് പ്രവർത്തിക്കുന്ന IKEv2 ലോഗിൻ എന്തെങ്കിലും ചോദിക്കുന്നതിന് മുൻപ് സെർവർ സർട്ടിഫിക്കറ്റ് സാധൂകരിക്കുന്നത്.
ഈ ക്രമം ഉപയോഗപ്രദമായ രോഗനിർണ്ണയവുമാണ്. ക്ലയന്റ് നിങ്ങൾക്ക് സർട്ടിഫിക്കറ്റ് കാണിക്കുന്നതിന് മുൻപ് തന്നെ ക്രെഡൻഷ്യലുകളെക്കുറിച്ച് പരാതിപ്പെട്ടാൽ, അത് IKEv2 EAP കൈമാറ്റം തന്നെ ചെയ്യുന്നില്ല.
മൂന്ന് ഐഡന്റിറ്റികൾ വെവ്വേറെ സൂക്ഷിക്കുക
മൂന്ന് ഐഡന്റിറ്റികൾ ഒരേ ഫീൽഡിൽ വീണാൽ കൈമാറ്റം തെറ്റാകുന്നു. ക്ലയന്റ് സാധൂകരിക്കുന്ന ഗേറ്റ്വേ ഐഡന്റിറ്റിയുണ്ട്, സാധാരണയായി സർട്ടിഫിക്കറ്റിന്റെ subject അല്ലെങ്കിൽ SAN ൽ ഒരു DNS നാമം. EAP ൽ അവതരിപ്പിക്കുന്ന ഉപയോക്തൃ ഐഡന്റിറ്റിയുണ്ട്, ഡൊമെയിൻ ലോഗിൻ, വിലാസം അല്ലെങ്കിൽ വ്യക്തമായ EAP ഐഡന്റിറ്റി സ്ട്രിംഗ് ആകാം. കൂടാതെ ആ ഉപയോക്താവിനെ നെറ്റ്വർക്കുകളിലേക്കും റൂട്ടുകളിലേക്കും മാപ്പ് ചെയ്യുന്ന അധികാര സ്രോതസ്സുണ്ട്.
strongSwan ന്റെ swanctl വാക്യഘടന വിഭജനം ദൃശ്യമാക്കുന്നു: കണക്ഷൻ ഗേറ്റ്വേയ്ക്ക് remote { auth = pubkey } ഉം ഉപയോക്താവിന് local { auth = eap-mschapv2 } ഉം സെറ്റ് ചെയ്യുന്നു, EAP ഐഡന്റിറ്റി വെവ്വേറെ കൊണ്ടുപോകുന്നു.
പുതിയ പ്രൊഫൈലിലെ ഉപയോക്തൃ ഐഡന്റിറ്റി പഴയ XAuth സവിശേഷതകളിൽ നിന്ന് വ്യത്യസ്തമാണെങ്കിൽ, ഉദാഹരണത്തിന് ചെറിയ പേരിന് പകരം UPN, പ്രാമാണീകരണ സെർവർ അപരിചിതനായ ഉപയോക്താവിനെ കാണുന്നു, പരാജയം തെറ്റായ പാസ്വേഡ് പോലെ തോന്നുന്നു. ക്രെഡൻഷ്യലുകൾ പരിശോധിക്കുന്നതിന് മുൻപ് ഐഡന്റിറ്റി സ്ട്രിംഗ് പരിശോധിക്കുക.
ഓപ്ഷനുകൾ മാപ്പ് ചെയ്ത് പിന്നീട് കെണികൾ പ്രതീക്ഷിക്കുക
മാപ്പിംഗ് ചെറുതാണ്, ഓരോ വരിയിലും പ്രാമാണീകരണ സമയത്ത് മാത്രം പ്രത്യക്ഷപ്പെടുന്ന ഒരു കെണിയുണ്ട്.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
ആ വരികളിൽ ഒന്നും വെറും പേരുമാറ്റമല്ല. കോൺഫിഗറേഷൻ പേലോഡ് വിലാസങ്ങളും റിസോൾവറുകളും ടൈപ്പ് ചെയ്ത സവിശേഷത പട്ടികയിലൂടെ എത്തിക്കുന്നു, XAuth ന്റെ സവിശേഷത മണ്ഡലം അതിന്റെ സ്വന്തം കണ്ടുപിടിത്തമായിരുന്നു; അവയെ പരസ്പരം മാറ്റാവുന്നതായി കാണുന്നതാണ് പ്രൊഫൈൽ ഗേറ്റ്വേ ഒരിക്കലും അയയ്ക്കാത്ത ക്രമീകരണം ആവശ്യപ്പെടുന്ന വഴി.
ട്രാഫിക് സെലക്ടർമാർ അവരുടേതായ മുന്നറിയിപ്പിന് അർഹരാണ്. IKEv1 താൽപ്പര്യമുള്ള ട്രാഫിക് quick mode കൈമാറ്റത്തോട് ബന്ധിപ്പിച്ച പ്രോക്സി ഐഡികളിലൂടെ പ്രകടിപ്പിച്ചു, IKEv2 IKE_AUTH സമയത്ത് സെലക്ടർമാരെ ചർച്ച ചെയ്യുന്നു, പ്രതികരിക്കുന്ന കക്ഷിക്ക് അവ ഇടുങ്ങിയതാക്കാം. പൊരുത്തക്കേട് child SA ഇല്ലാത്ത സ്ഥാപിത IKE SA സൃഷ്ടിക്കുന്നു, ചില ക്ലയന്റുകൾ അത് സന്തോഷത്തോടെ ബന്ധിപ്പിച്ചതായി കാണിക്കുന്നു.
പഴയ കണക്ഷനെ ഒരു അതിർത്തിയായി കാണുക
RFC 9395 IKEv1 നെ കാലഹരണപ്പെട്ടതായി പ്രഖ്യാപിക്കുന്നു, അതിനാൽ പഴയ ഹൈബ്രിഡ് കണക്ഷൻ തീയതിയുള്ള അനുയോജ്യത അതിർത്തിയാണ്, അടിത്തറയല്ല. മാറ്റത്തിനിടയിൽ രണ്ട് പ്രൊഫൈലുകളും ഒപ്പം പ്രവർത്തിപ്പിക്കുക, കാരണം പ്രധാന പരീക്ഷ പുതിയ പ്രൊഫൈൽ ഉയരുന്നുണ്ടോ എന്നതല്ല, അതേ ഉപയോക്താവ് അതേ ഉപകരണത്തിൽ അതേ വിഭവങ്ങളിൽ എത്തുന്നുണ്ടോ എന്നതാണ്.
സർട്ടിഫിക്കറ്റ് സാധൂകരണം തുടക്കം മുതൽ അവസാനം വരെ കർശനമായി സൂക്ഷിക്കുക. ക്ലയന്റ് സ്വന്തം സർട്ടിഫിക്കറ്റ് കാണിക്കുന്നത് നിർത്തിയാൽ, ഹാൻഡ്ഷേക്ക് പൂർത്തിയാകുന്നതുവരെ സെർവർ പരിശോധന അയച്ചുകൊടുക്കാനുള്ള പ്രലോഭനം വരുന്നു, അത് ബാക്കിയുള്ള ഏക തെളിവിനെ പച്ച ചിഹ്നം കൊണ്ട് മാറ്റുന്നു.
പഴയ പ്രൊഫൈൽ വിരമിക്കുന്നതിന് മുൻപ് നാല് കാര്യങ്ങൾ എഴുതുക: EAP രീതി, ഐഡന്റിറ്റി സ്ട്രിംഗ്, അധികാര സ്രോതസ്സ്, പിന്തുണ അവസാനിക്കുന്ന തീയതി.