ഒരു IKEv2 ലോഗിനിൽ രണ്ട് ഐഡന്റിറ്റികൾ: ആദ്യം മെഷീൻ, പിന്നെ ഉപയോക്താവ്

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

ലക്ഷണം: വിജയകരമായ ആദ്യ തെളിവിന് ശേഷമുള്ള പരാജയം

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

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

എക്സ്റ്റെൻഷൻ എന്ത് ചേർക്കുന്നു, എന്ത് ചേർക്കുന്നില്ല

ഒരു സെഷനിൽ ഒന്നിലധികം ഓതന്റിക്കേഷൻ കൈമാറ്റങ്ങൾ നടത്താൻ IKEv2 ഒരു എക്സ്റ്റെൻഷൻ വഹിക്കുന്നു. RFC 4739 മറ്റ് ക്രമങ്ങൾക്കൊപ്പം, സർട്ടിഫിക്കറ്റ് ഐഡന്റിറ്റി തെളിയിച്ചതിന് ശേഷം EAP വഴി ഒരു വ്യക്തിയെ ഓതന്റിക്കേറ്റ് ചെയ്യുന്ന ക്ലൈന്റിനെ രേഖപ്പെടുത്തുന്നു. രേഖയുടെ നില Experimental ആണ്, അതായത് ഏതെങ്കിലും ഇംപ്ലിമെന്റേഷനും ഈ സവിശേഷത നൽകാൻ ബാധ്യസ്ഥമല്ല. എതിർകക്ഷി അതിൽ ചർച്ച ചെയ്യുന്നതുവരെ പിന്തുണയെക്കുറിച്ച് ഒന്നും അനുമാനിക്കരുത്.

ഇരുവശങ്ങളും എക്സ്റ്റെൻഷൻ പിന്തുണയ്ക്കുകയും കൈമാറ്റത്തിനിടയിൽ അതിൽ യോജിക്കുകയും വേണം. രണ്ടാം റൗണ്ടിനായി ക്രമീകരിച്ച ഗേറ്റ്വേയ്ക്ക് ക്ലൈന്റിനെ അത് ചെയ്യാൻ നിർബന്ധിക്കാനാവില്ല, അത് പിന്തുണയ്ക്കുന്ന ക്ലൈന്റ് സെർവർ ആവശ്യപ്പെട്ടില്ലെങ്കിൽ അത് ഉപയോഗിക്കുകയുമില്ല. ഈ അസമത്വമാണ് പരാജയം സാധാരണയായി കഴിവിനെക്കുറിച്ചുള്ള വ്യക്തമായ പ്രസ്താവനയ്ക്ക് പകരം ഒരു ടൈംഔട്ട് അല്ലെങ്കിൽ പ്രോട്ടോക്കോൾ പിശകായി പ്രത്യക്ഷപ്പെടാനുള്ള കാരണം. ഒരു വശത്തിന്റെ കോൺഫിഗറേഷൻ വായിക്കുന്നത് എന്ത് സംഭവിക്കുമെന്നതിന്റെ പകുതി മാത്രം പറയുന്നു.

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

EAP-TLS മൂന്നാം രൂപമാണ്, അതും ഇതല്ല. അവിടെ ഒരു ക്ലൈന്റ് സർട്ടിഫിക്കറ്റ് EAP രീതിക്കുള്ളിൽ അവതരിപ്പിക്കപ്പെടുന്നു, അതിനാൽ ക്ലൈന്റ് ഇപ്പോഴും ഒരു IKE ഓതന്റിക്കേഷൻ പൂർത്തിയാക്കുന്നു. ഒന്നിലധികം റൗണ്ടുകളുള്ള സന്ദർഭത്തോട് സമാനമായി ക്രെഡൻഷ്യലുകൾ കാണാം, എന്നാൽ പ്രോട്ടോക്കോൾ രണ്ടിനുപകരം ഒരു റൗണ്ട് മാത്രം വഹിക്കുന്നു. അതുകൊണ്ടാണ് EAP-TLS വിന്യാസത്തിൽ നിന്ന് പകർത്തിയ രൂപകൽപ്പന രണ്ടാം തെളിവ് പ്രതീക്ഷിക്കുന്നിടത്ത് തന്നെ പരാജയപ്പെടുന്നത്.

അതേ ഫയൽ ഗേറ്റ്വേയിൽ വ്യത്യസ്തമായി വായിക്കപ്പെടുന്നു

അതേ swanctl ഫയൽ എവിടെ പ്രവർത്തിക്കുന്നു എന്നതനുസരിച്ച് വ്യത്യസ്തമായി വായിക്കപ്പെടുന്നു, ഇതാണ് ആളുകളെ വീഴ്ത്തുന്ന ഭാഗം. ലാപ്ടോപ്പിൽ ഗേറ്റ്വേയാണ് എതിർകക്ഷി, ഗേറ്റ്വേയിൽ ലാപ്ടോപ്പാണ് എതിർകക്ഷി, അതിനാൽ local വശം ഞാൻ ആരാണ് എന്നും remote വശം ഞാൻ ആരെ സ്വീകരിക്കും എന്നും എഴുതുക. local ബ്ലോക്ക് ഈ എൻഡ്പോയിന്റ് സ്വയം എങ്ങനെ ഓതന്റിക്കേറ്റ് ചെയ്യുന്നു എന്ന് വിവരിക്കുന്നു, remote ബ്ലോക്ക് മറ്റേ അറ്റത്തുനിന്ന് എന്ത് ആവശ്യപ്പെടുന്നു എന്ന് പറയുന്നു. രണ്ട് ഫയലുകൾക്കിടയിൽ ഒരു ബ്ലോക്ക് പകർത്തുന്നത് ഒരു അക്ഷരവും മാറ്റാതെ അതിന്റെ അർഥം തലകീഴാക്കുന്നു. രണ്ട് ഫയലുകളും താരതമ്യം ചെയ്യുന്നത് ഏതാണ്ട് ഒന്നും പറയുന്നില്ല, കാരണം ഒരേ വാക്കുകൾ ഓരോന്നിലും വിപരീതാർഥം നൽകുന്നു.

ഒരു വിഭാഗത്തിന്റെ സ്ഥാനം അതിന്റെ ക്രമം നിർണ്ണയിക്കുന്നു, റൗണ്ട് നമ്പർ അതിനെ മറികടക്കുന്നില്ലെങ്കിൽ. അതിനാൽ അധിക local അല്ലെങ്കിൽ remote വിഭാഗങ്ങൾ ബദലുകളല്ല, അധിക റൗണ്ടുകളാണ് വിവരിക്കുന്നത്, swanctl.conf റഫറൻസ് ലെ വ്യക്തമായ റൗണ്ട് നമ്പർ ആ ക്രമം ബോധപൂർവ്വമാക്കാൻ വേണ്ടിയാണ്. അതില്ലാതെ ഒരു ബ്ലോക്ക് നീക്കുന്നത് പെരുമാറ്റം മാറ്റുന്നു. കടലാസിൽ തുല്യമായി തോന്നുന്ന രണ്ട് കോൺഫിഗറേഷനുകൾ വിപരീത ക്രമത്തിൽ പെരുമാറാനും അതുതന്നെ കാരണം.

ആ ക്രമനിയമം ഓർത്തിരിക്കേണ്ട പരാജയരീതി സൃഷ്ടിക്കുന്നു. രണ്ടാം remote ബ്ലോക്ക് മറ്റൊരു സ്വീകാര്യമായ ഓപ്ഷനല്ല, അത് രണ്ടാം ആവശ്യമാണ്, അതുകൊണ്ടാണ് ഒന്നുകിൽ/അല്ലെങ്കിൽ എന്ന് വായിക്കുന്ന നയം കൂടാതെ-പിന്നെ എന്നപോലെ പെരുമാറുന്നത്. ഗേറ്റ്വേ നയത്തിന് രജിസ്റ്റർ ചെയ്ത മെഷീന്റെ സർട്ടിഫിക്കറ്റ് സ്വീകരിച്ച് പിന്നീട് ആ ഉപയോക്താവിന്റെ EAP കൈമാറ്റം അതേ ക്രമത്തിൽ ആവശ്യപ്പെടാനാകും.

റൗണ്ടുകളെ സ്വതന്ത്ര ഘടകങ്ങളിൽ നിന്ന് വേർതിരിക്കുക

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

മെഷീൻ സർട്ടിഫിക്കറ്റ് അതിന്റെ സ്വീകൃത കീയുടെ ഉടമസ്ഥത തെളിയിക്കുന്നു, അതിൽ കൂടുതലൊന്നുമില്ല. അത് ഹാർഡ്വെയർ അറ്റസ്റ്റേഷനല്ല, ഉപകരണ ആരോഗ്യ റിപ്പോർട്ടുമല്ല, അതിനാൽ സ്ഥിതി വിവരങ്ങൾ ആവശ്യമുള്ള നയത്തിന് മറ്റൊരു സംവിധാനം വേണം. subject ഫീൽഡും വിശ്വസനീയമായ ഇൻവെന്ററി ടാഗല്ല, കാരണം subject സർട്ടിഫിക്കറ്റ് നൽകിയോ രജിസ്റ്റർ ചെയ്തതോ ആയ ആളാണ് തിരഞ്ഞെടുക്കുന്നത്. മെഷീൻ ആരോഗ്യവതിയാണെന്ന തെളിവ് രൂപകൽപ്പനയ്ക്ക് ആവശ്യമെങ്കിൽ, ആ തെളിവ് മെഷീനെ അളക്കുന്ന ഘടകത്തിൽ നിന്ന് വരണം.

ഓരോ റൗണ്ടും യഥാർഥത്തിൽ എന്ത് തെളിയിക്കുന്നു എന്ന് ചേർക്കുന്നതിന് മുമ്പ് എഴുതിവെക്കുക. രണ്ട് റൗണ്ടുകൾ ഒരേ കാര്യം രണ്ടുതവണ തെളിയിക്കുമ്പോൾ, രണ്ടാമത്തേത് ഉറപ്പിനുപകരം കാലതാമസവും സപ്പോർട്ട് ടിക്കറ്റുകളും ചേർക്കുന്നു. ആ കുറിപ്പാണ് അധിക റൗണ്ട് അതിന്റെ ചെലവിന് അർഹമാണോ എന്ന തർക്കം നിർത്തുന്നതും.

ജോടിയാക്കൽ നിയമം എഴുതി നിരസിക്കലുകൾ പരിശോധിക്കുക

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

പിന്നീട് പരാജയപ്പെടേണ്ടത് പരിശോധിക്കുക: അംഗീകരിക്കാത്ത മെഷീനിൽ സ്വീകരിച്ച ഉപയോക്താവ്, മെഷീന്റെ ക്രെഡൻഷ്യൽ കൈവശമുള്ള അംഗീകരിക്കാത്ത ഉപയോക്താവ്, അധിക റൗണ്ട് നടത്താനാകാത്ത എതിർകക്ഷി. മൂന്നും നിശ്ശബ്ദമായി ഒരേ പ്രവേശനം നേടുന്നുവെങ്കിൽ, നയം നടപ്പാക്കുന്നതിനുപകരം ഒരു ഉദ്ദേശ്യം വിവരിക്കുന്നു. പ്രഖ്യാപിത കോൺഫിഗറേഷനെ ഡീമൺ റിപ്പോർട്ട് ചെയ്യുന്നതുമായി താരതമ്യം ചെയ്യുക, കാരണം ഒരിക്കലും പൊരുത്തപ്പെടാത്ത ഒരു കണക്ഷൻ കടന്നുപോയ നിയമത്തോട് സമാനമായി കാണപ്പെടുന്നു:

swanctl --list-conns
swanctl --list-sas

വിജയകരമായ ലോഗിൻ മാത്രമല്ല, ചർച്ച ചെയ്ത റൗണ്ടുകളും അവയിൽ നിന്ന് ഉണ്ടാകുന്ന അധികാരവും പരിശോധിക്കുക. ഒപ്പം ചുരുക്കവഴിയായി പഴയ IKEv1 XAuth ക്രമീകരണങ്ങളിലേക്ക് കൈയിടരുത്: കണക്ഷൻ വിജയിക്കുന്നതുവരെ ആവശ്യമായ ഒരു റൗണ്ട് ഇല്ലാതാക്കുന്നതിനുപകരം പ്രോട്ടോക്കോൾ, റോളുകൾ, ക്രമം, ക്ലൈന്റിന്റെ യഥാർഥ പെരുമാറ്റം എന്നിവ ഒത്തുനോക്കുക. പരാജയപ്പെടുന്ന റൗണ്ട് ഇല്ലാതാക്കുന്നതാണ് രണ്ട് തെളിവുള്ള രൂപകൽപ്പന ആരും അവലോകനം ചെയ്യാത്ത ഒരു തെളിവുള്ള രൂപകല്പനയായി നിശ്ശബ്ദമായി മാറുന്ന വഴി. ഇല്ലാതാക്കൽ മാറ്റരേഖയിൽ സൂക്ഷിക്കുക.