Windows-ലും FortiGate-ലും IKEv2: ആളുകൾ കൂട്ടിച്ചേർക്കുന്ന മൂന്ന് ക്രമീകരണങ്ങൾ
IKE കീ കൈമാറ്റം, CHILD SA സംരക്ഷണം, പിയർ പ്രാമാണീകരണം എന്നിവ മൂന്ന് വെവ്വേറെ വരികളാണ്. രണ്ട് സംഭാഷണങ്ങളിൽ ഗ്രൂപ്പ് നമ്പറുകൾ ഒത്തുപോയാലും അവ കൂടിച്ചേരുന്നില്ല.
Windows ക്ലയന്റും FortiGate ഗേറ്റ്വേയും തമ്മിലുള്ള IKEv2 കരാർ തുടർച്ചയായി പരാജയപ്പെടുന്നു, ഒത്തുപോകാത്ത നമ്പർ തിരയുന്തോറും നമ്പറുകളുടെ പട്ടിക കൂടുതൽ നീളുന്നു. സ്വതന്ത്രമായി പരാജയപ്പെടുന്ന മൂന്ന് വരികളായി വിഭജിക്കുമ്പോൾ മാത്രമേ പട്ടിക കൈകാര്യം ചെയ്യാനാകൂ: IKE-യെ സംരക്ഷിക്കുന്ന കീ കൈമാറ്റം, CHILD SA-യിൽ പ്രയോഗിക്കുന്ന സംരക്ഷണം, ഓരോ വശവും ആരാണെന്ന് തെളിയിക്കുന്ന പ്രാമാണീകരണം. ഗ്രൂപ്പ് നമ്പറുകൾ ആ വരികളിൽ രണ്ടെണ്ണത്തിൽ പ്രത്യക്ഷപ്പെടുന്നു, വ്യത്യസ്ത അർത്ഥങ്ങൾ നൽകുന്നു.
സ്വതന്ത്രമായി പരാജയപ്പെടുന്ന മൂന്ന് വരികൾ
ആദ്യ വരി IKE-യുടെ ഉള്ളിലെ കീ കൈമാറ്റമാണ്, അത് ചർച്ചകളെ സംരക്ഷിക്കുന്ന കീകൾ സൃഷ്ടിക്കുന്നു. രണ്ടാമത്തേത് CHILD SA-യ്ക്കുള്ള നിർദ്ദേശമാണ്, അത് ടണൽ വഹിക്കുന്ന ട്രാഫിക്കിനെ സംരക്ഷിക്കുന്നു. മൂന്നാമത്തേത് പ്രാമാണീകരണമാണ്, ഓരോ വശവും എന്താണ് അവതരിപ്പിക്കുന്നതെന്നും മറുവശം അത് എങ്ങനെ സാധൂകരിക്കുന്നുവെന്നും അത് തീരുമാനിക്കുന്നു.
പരാജയങ്ങൾ വ്യത്യസ്ത സ്ഥലങ്ങളിൽ സംഭവിക്കുന്നു. കൈമാറ്റത്തിന്റെ പരാജയം ഒരു ടണൽ ഉണ്ടാകുന്നതിന് മുമ്പുതന്നെ ചർച്ചകൾ നിർത്തുന്നു. CHILD SA-യുടെ പരാജയം പ്രാമാണീകരണം വിജയിച്ചതിന് ശേഷം സംഭവിക്കുന്നു, ചിലപ്പോൾ കീ പുതുക്കുമ്പോൾ മാത്രം. പ്രാമാണീകരണത്തിന്റെ പരാജയം ലോഗുകളിൽ കൈമാറ്റത്തിന്റെ പരാജയം പോലെ തോന്നാം, ആദ്യ പിശക് മാത്രം വായിച്ചാൽ.
വരികൾ വേർതിരിക്കുന്നത് കണക്കെഴുത്തല്ല. ഏത് ക്രമീകരണം മാറ്റാൻ യോഗ്യമെന്ന് അത് മാറ്റുന്നു, ഈ മേഖലയിലെ ഏറ്റവും ചെലവേറിയ നീക്കം തടയുന്നു, അതായത് നിർദ്ദേശത്തിലെ പൊരുത്തക്കേട് പരിഹരിക്കാൻ പ്രവർത്തിക്കുന്ന സർട്ടിഫിക്കറ്റുകൾ പുനർനിർമ്മിക്കുന്നത്. ഒരു വരിയുടെ മാറ്റം മറ്റ് രണ്ടിനെയും കൂടെ മാറാൻ നിർബന്ധിക്കരുത്. ആ സ്വാതന്ത്ര്യമാണ് അവ വെവ്വേറെ എഴുതുന്നതിന്റെ മുഴുവൻ ഉദ്ദേശ്യം.
Windows-ലെ രണ്ട് ഫീൽഡുകൾ എന്താണ് നിയന്ത്രിക്കുന്നത്
Windows രണ്ട് ഫീൽഡുകൾ വേറിട്ട് സൂക്ഷിക്കുന്നു: DHGroup IKE കൈമാറ്റം തന്നെ ക്രമീകരിക്കുന്നു, PfsGroup ടണലിനുള്ളിലെ ട്രാഫിക്കിനെ സംരക്ഷിക്കുന്ന IPsec നയം ക്രമീകരിക്കുന്നു. അവ വ്യത്യസ്ത ഘട്ടങ്ങളിൽ പെടുന്നു. Windows-ലെ IKE ഫീൽഡിനെ FortiGate-ലെ ഘട്ടം 2 മൂല്യവുമായി താരതമ്യം ചെയ്യുന്നത് തെറ്റായ ജോഡിയെ പരിശോധിക്കുന്നു, നമ്പറുകൾ ഒത്തുപോയാലും അടിസ്ഥാന കൈമാറ്റം ഇപ്പോഴും പരാജയപ്പെടുന്നു.
Get-VpnConnection -Name "Corp-IKEv2"
Get-NetIPsecMainModeSA
Get-NetIPsecQuickModeSAരണ്ടാമത്തെയും മൂന്നാമത്തെയും കമാൻഡുകൾ യഥാർത്ഥത്തിൽ നിലനിൽക്കുന്ന സുരക്ഷാ അസോസിയേഷനുകൾ റിപ്പോർട്ട് ചെയ്യുന്നു, ഒരു ക്ലയന്റിന് നിങ്ങൾക്ക് നൽകാനാകുന്ന ഉത്തരത്തിന് ഏറ്റവും അടുത്തത് അതാണ്. പ്രധാന മോഡ് അസോസിയേഷൻ ഉണ്ടായിട്ടും വേഗ മോഡ് അസോസിയേഷൻ ഇല്ലാതിരിക്കുന്നത് CHILD SA പ്രശ്നമാണ്, അത് സർട്ടിഫിക്കറ്റ് പ്രശ്നമല്ല, ഘട്ടം 2-ലെ പൊരുത്തക്കേടിന്റെ അടയാളമാണ്.
ഒരു ശ്രമത്തിൽ എന്താണ് നിർദ്ദേശിച്ചതെന്നും എന്താണ് തിരഞ്ഞെടുത്തതെന്നും രേഖപ്പെടുത്തുക. സ്വീകാര്യമായ നിർദ്ദേശം അടങ്ങിയ നിർദ്ദേശ പട്ടികയും ഗേറ്റ്വേ നയവുമായി പൊരുത്തപ്പെടാത്ത തിരഞ്ഞെടുത്ത നിർദ്ദേശവും കോൺഫിഗറേഷൻ വിയോജിപ്പാണ്, പരസ്പര പ്രവർത്തനക്ഷമതയുടെ രഹസ്യമല്ല.
| Agreement row | Where it is configured in Windows | What it does not decide |
|---|---|---|
| IKE key exchange | DHGroup on the VPN connection IPsec settings | The protection used for tunneled traffic |
| CHILD SA protection | PfsGroup in the same policy object | Which certificate the peer presents |
| Peer authentication | Machine or user certificate, or a supported EAP method | Any group number used for key exchange |
| Certificate validation | Trusted CA store on the validating side | The private key of the certificate being presented |
ദീർഘവൃത്താകൃതിയിലുള്ള വക്ര ഗ്രൂപ്പ് നിങ്ങളുടെ ഒപ്പ് കീ തിരഞ്ഞെടുക്കുന്നില്ല
ഈ മേഖലയിലെ ഏറ്റവും സ്ഥിരമായ തെറ്റായ അനുമാനം, ദീർഘവൃത്താകൃതിയിലുള്ള വക്ര DH ഗ്രൂപ്പ് തിരഞ്ഞെടുക്കാൻ ദീർഘവൃത്താകൃതിയിലുള്ള വക്ര സർട്ടിഫിക്കറ്റ് ആവശ്യമാണ് എന്നതാണ്. DH ഗ്രൂപ്പ് കീ കൈമാറ്റ വസ്തു നൽകുന്നു; ഒപ്പ് അൽഗോരിതം പ്രാമാണീകരണ ചട്ടക്കൂട് ചർച്ച ചെയ്യുന്നു, IKEv2-ൽ ഇവ രണ്ട് വെവ്വേറെ തീരുമാനങ്ങളാണ്.
ആ തീരുമാനങ്ങൾ മുമ്പ് കൂടിക്കുഴഞ്ഞിരുന്നതുകൊണ്ടാണ് RFC 7427 നിലനിൽക്കുന്നത്, ഒപ്പ് അൽഗോരിതങ്ങൾ കീ കൈമാറ്റത്തിൽ നിന്ന് സ്വതന്ത്രമായി എങ്ങനെ പ്രഖ്യാപിക്കുകയും തിരഞ്ഞെടുക്കുകയും ചെയ്യുന്നു എന്ന് അത് നിർവചിക്കുന്നു. ഒരു ഗേറ്റ്വേക്ക് ഒരേ സമയം വക്ര ഗ്രൂപ്പും ഒപ്പ് സ്കീമകളുടെ തിരഞ്ഞെടുപ്പും പിന്തുണയ്ക്കാനാകും.
അതിനാൽ ഗ്രൂപ്പ് മാറ്റത്തിന് ശേഷം ചർച്ചകൾ പരാജയപ്പെട്ടാൽ, സർട്ടിഫിക്കറ്റിന്റെ കീ തരം നോക്കുന്നതിന് മുമ്പ് പ്രാമാണീകരണ രീതി നോക്കുക. സർട്ടിഫിക്കറ്റ് മാറ്റുന്നത് സാവധാനവും അപകടകരവുമായ പ്രവർത്തനമാണ്, അത് അപൂർവ്വമായേ ഉത്തരമാകൂ, അത് ആദ്യം ചെയ്യുന്നത് ഏത് മാറ്റമാണ് യഥാർത്ഥത്തിൽ സഹായിച്ചതെന്ന് അറിയാനുള്ള നിങ്ങളുടെ കഴിവ് നശിപ്പിക്കുന്നു. സർട്ടിഫിക്കറ്റ് സ്റ്റോർ സ്പർശിക്കുന്നതിന് മുമ്പ് പ്രാമാണീകരണ വരി വായിക്കുക.
രണ്ടും കരാർ ഷീറ്റിന്റെ വെവ്വേറെ വരികളിൽ സൂക്ഷിക്കുക, പിശക് പ്രലോഭിപ്പിക്കുന്നത് നിർത്തും. ഒരു വരി ഗ്രൂപ്പുകൾ പട്ടികപ്പെടുത്തുന്നു, മറ്റേത് ഒപ്പ് സ്കീമകളും ഐഡന്റിറ്റികളും, ഒന്നും മറ്റേതിനെക്കുറിച്ചുള്ള തെളിവല്ല.
ഓരോ സ്വകാര്യ കീയും അതിന്റെ യഥാർത്ഥ ഉടമയുടെ അടുത്ത് വയ്ക്കുക
സ്വന്തം സർട്ടിഫിക്കറ്റ് അവതരിപ്പിക്കുന്ന ഗേറ്റ്വേക്ക് അതിന് യോജിക്കുന്ന സ്വകാര്യ കീ വേണം. ചങ്ങല സാധൂകരിക്കുന്ന പിയറിന് CA സർട്ടിഫിക്കറ്റ് വേണം, CA-യുടെ ഒപ്പ് കീ പ്രത്യേകിച്ച് വേണ്ടതില്ല. ഈ മൂന്ന് ഘടകങ്ങൾ കൂട്ടിക്കുഴയ്ക്കുന്നതാണ് സർട്ടിഫിക്കറ്റ് മറ്റൊരു വിഭാഗത്തിൽ കാണിക്കാൻ ആളുകൾ VPN ഉപകരണത്തിൽ CA-യുടെ സ്വകാര്യ കീ ഇറക്കുമതി ചെയ്യാനുള്ള കാരണം.
FortiOS-ൽ റോളുകൾ വേറിട്ടതാണ്: അതിന്റെ കീയുള്ള പ്രാദേശിക സർട്ടിഫിക്കറ്റ്, പിയറിനെ തിരിച്ചറിയാൻ ഉപയോഗിക്കുന്ന ദൂര സർട്ടിഫിക്കറ്റ്, ആ CA ഒപ്പിട്ട സർട്ടിഫിക്കറ്റുകളിൽ വിശ്വാസം സ്ഥാപിക്കുന്ന ദൂര CA എൻട്രി. സ്വകാര്യ കീ ഇല്ലാത്ത ദൂര CA എൻട്രി അപൂർണ്ണമല്ല; അതിന്റെ ഉദ്ദേശ്യത്തിന് അത് ശരിയാണ്.
ഇറക്കുമതി ചെയ്ത CA ഒപ്പ് കീകൾ ആ ഉപകരണം വായിക്കാൻ കഴിയുന്ന ഏതൊരാളുടെയും അധികാരം വിശാലമാക്കുന്നു. സാധാരണ പിയർ സാധൂകരണവും അവ പരിഹരിക്കുന്നില്ല, കാരണം സാധൂകരണത്തിന് പൊതു സർട്ടിഫിക്കറ്റും വിശ്വാസ തീരുമാനവും വേണം, പുതിയ സർട്ടിഫിക്കറ്റുകൾ പുറപ്പെടുവിക്കാനുള്ള കഴിവല്ല.
CA-യുടെ ഒപ്പ് കീ ഇഷ്യൂ ചെയ്യുന്നവരുടെ സ്വന്തം പ്രക്രിയയുടെ അടുത്ത് സൂക്ഷിക്കുക, ഏത് ഉപകരണം ഏത് കീ കൈവശം വയ്ക്കുന്നു എന്ന് രേഖപ്പെടുത്തുക. ആരെ ആര് അനുകരിക്കാമായിരുന്നു എന്ന് ഓഡിറ്റ് ചോദിക്കുമ്പോൾ ഉടമകളുടെ ചെറിയ പട്ടിക അൽഗോരിതങ്ങളുടെ നീളമുള്ള പട്ടികയേക്കാൾ മൂല്യമുള്ളതാണ്. ഇൻവെന്ററിക്ക് മാത്രമുള്ളതെന്ന് അറിയുന്ന കീ ആരും ഇറക്കുമതി ചെയ്യുന്നില്ല. സംഭവത്തിന് ശേഷമല്ല, മുമ്പ് ഇൻവെന്ററി എഴുതുക.