FortiGate Azure റീകീ: peer SA നിർദ്ദേശം പ്രാദേശിക നയവുമായി പൊരുത്തപ്പെടുന്നില്ല

ടണൽ ഉയർന്നു, ട്രാഫിക് ഒഴുകി, പിന്നീട് ലോഗ് പറയുന്നു peer SA proposal not match local policy. രണ്ട് കോൺഫിഗറേഷനുകളും ഒരിക്കലും പൊരുത്തപ്പെട്ടിട്ടില്ല എന്നതിന്റെ തെളിവായാണ് മിക്കവരും ആ വരി വായിക്കുന്നത്. സാധാരണയായി അത് കൂടുതൽ ഇടുങ്ങിയ എന്തോ അർത്ഥമാക്കുന്നു: ആദ്യ CHILD SA-യ്ക്ക് അവ പൊരുത്തപ്പെട്ടു, ആദ്യ പുതുക്കലിൽ പൊരുത്തപ്പെടുന്നത് നിർത്തി, കാരണം ആദ്യ അസോസിയേഷന് പിന്നീടുള്ളവ ചെയ്യുന്ന കൈമാറ്റം ഒരിക്കലും ആവശ്യമായിരുന്നില്ല. ആ വ്യത്യാസമാണ് എവിടെ നോക്കണമെന്ന് തീരുമാനിക്കുന്നത്.

ആദ്യ CHILD SA പാരമ്പര്യമായി നേടുന്നു, പിന്നീടുള്ളവ ചർച്ച ചെയ്യുന്നു

IKEv2-ൽ പ്രാരംഭ CHILD SA IKE_AUTH സമയത്ത് സൃഷ്ടിക്കപ്പെടുന്നു, അതിന്റെ കീകൾ IKE SA-യുടെ കീ മെറ്റീരിയലിൽ നിന്ന് ഉരുത്തിരിഞ്ഞതാണ്. ആ നിമിഷത്തിൽ പ്രത്യേക Diffie-Hellman കൈമാറ്റമില്ല, അതിനാൽ ഒരു peer സ്വീകരിക്കാൻ കഴിയാത്ത PFS ഗ്രൂപ്പ് ഇതുവരെ പരീക്ഷിക്കുന്നില്ല. ടണൽ ആരോഗ്യകരമായി കാണുന്നത് നിങ്ങൾ പിന്നീട് പരാജയപ്പെടുന്ന ആവശ്യകത ഒരിക്കലും പരീക്ഷിച്ചിട്ടില്ലാത്തതിനാലാണ്.

CHILD_SA റീകീ മറ്റൊരു സന്ദേശ ക്രമമാണ്. PFS കോൺഫിഗർ ചെയ്തിരിക്കുമ്പോൾ, peer-കൾ പുതിയ കീ കൈമാറ്റം നടത്തുകയും ഇരുവശവും സ്വീകരിക്കുന്ന ഗ്രൂപ്പിലും പുതിയ അസോസിയേഷനുവേണ്ടിയുള്ള ESP നിർദ്ദേശത്തിലും യോജിക്കണം. അപ്പോഴാണ് പൊരുത്തക്കേട് ദൃശ്യമാകുന്നത്, അതുകൊണ്ടാണ് പിശക് റൂട്ടിനെക്കാൾ നിർദ്ദേശത്തെ പേരിടുന്നത്.

അതിനാൽ “ഇന്നലെ അത് പ്രവർത്തിച്ചു” എന്നത് നിർദ്ദേശത്തെക്കുറിച്ച് നിങ്ങളോട് ഒന്നും പറയുന്നില്ല. പ്രാരംഭ കൈമാറ്റം വിജയിച്ചു എന്ന് പറയുന്നു, അത് നിങ്ങൾക്ക് ഇതിനകം അറിയാമായിരുന്നു.

പരാജയപ്പെട്ട കൈമാറ്റം വായിക്കുക, ആദ്യ ping അല്ല

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് ഇരുവശത്തുനിന്നും വിജയകരമായ IKE പ്രാമാണീകരണം, പ്രാരംഭ CHILD SA, പരാജയപ്പെട്ട പകരം എന്നിവ ശേഖരിക്കുക. തുടർന്ന് പ്രവർത്തനത്തെ കൃത്യമായി പേരിടുക: IKE SA റീകീ, IKE പുനഃപ്രാമാണീകരണം, CHILD SA റീകീ എന്നിവ മൂന്ന് വ്യത്യസ്ത സംഭവങ്ങളാണ്, “ഘട്ടം 2” സാധാരണ സംഭാഷണത്തിൽ അവയെല്ലാം ഉൾക്കൊള്ളുന്നു.

ചുവടെയുള്ള ഫീൽഡുകൾ പരാജയപ്പെട്ട കണക്ഷനുവേണ്ടി താരതമ്യം ചെയ്യുക, ടണലിന് പൊതുവായി അല്ല.

FortiGate-ൽ ആ ടണലിന്റെ ഘട്ടം-2 നിർദ്ദേശം, PFS ക്രമീകരണം, സ്വീകരിച്ച DH ഗ്രൂപ്പുകൾ എന്നിവ തുറക്കുക. മുമ്പ് സ്ഥാപിച്ച കണക്ഷനിൽ നിന്ന് അനുമാനിക്കുന്നതിനുപകരം ലോഡ് ചെയ്ത മൂല്യങ്ങൾ വായിക്കുക. GUI പേജിന്റെ സ്ക്രീൻഷോട്ട് പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷനെക്കാൾ ദുർബല തെളിവാണ്, അപ്ഗ്രേഡിന് ശേഷം രണ്ടും വ്യത്യാസപ്പെടാം. നിങ്ങൾ മാറ്റിയ വിഭാഗം കയറ്റുമതി ചെയ്ത് ടിക്കറ്റിനൊപ്പം സൂക്ഷിക്കുക.

Azure-ന്റെ സ്ഥിരസ്ഥിതി നയവും ഒരു നയമാണ്

കണക്ഷനോട് ഇഷ്ടാനുസൃത നയം അറ്റാച്ച് ചെയ്തിട്ടില്ലെന്നത് Azure ഒന്നും പ്രയോഗിക്കുന്നില്ലെന്ന് അർത്ഥമാക്കുന്നില്ല. കണക്ഷൻ ഗേറ്റ്‌വേയുടെ സ്ഥിരസ്ഥിതി നിർദ്ദേശ സെറ്റിലേക്ക് മടങ്ങുന്നു, അത് നിങ്ങളുടെ FortiGate വാഗ്ദാനം ചെയ്യുന്നതിനേക്കാൾ വിശാലമോ ഇടുങ്ങിയതോ ആകാം. രണ്ട് സെറ്റുകളും IKE-യ്ക്ക് ഓവർലാപ്പ് ചെയ്യുന്നുവെങ്കിൽ, PFS-ഉള്ള ESP-യ്ക്കല്ലെങ്കിൽ, കൃത്യമായി ഈ പരാജയ മാതൃക ലഭിക്കും.

ഈ വായന-മാത്ര കാഴ്ച രഹസ്യങ്ങൾ വെളിപ്പെടുത്താതെ യഥാർത്ഥത്തിൽ അറ്റാച്ച് ചെയ്ത നയം കാണിക്കുന്നു:

Get-AzVirtualNetworkGatewayConnection -Name 'Branch' -ResourceGroupName 'NetworkRG' |
Select-Object Name, ConnectionStatus, IpsecPolicies

നിങ്ങളുടെ യഥാർത്ഥ റിസോഴ്സ് നാമങ്ങൾ ഉപയോഗിക്കുക. വ്യക്തമായ നയം ആവശ്യമാകുമ്പോൾ അത് കണക്ഷൻ റിസോഴ്സിൽ സെറ്റ് ചെയ്യുക. ഇത് മുഴുവൻ ഗേറ്റ്‌വേയുടെയും സ്വിച്ചല്ല, അതേ ഗേറ്റ്‌വേയിലെ മറ്റ് ടണലുകൾക്ക് നിശബ്ദമായി ബാധകമാകുന്നുമില്ല.

പോർട്ടലിൽ, ആ കണക്ഷന്റെ Configuration പേജാണ് ഇഷ്ടാനുസൃത IPsec/IKE നയം പോകുന്ന സ്ഥലം. Microsoft-ന്റെ ഇഷ്ടാനുസൃത നയ ഗൈഡ് പിന്തുണയ്ക്കുന്ന പാരാമീറ്ററുകളും SKU ആവശ്യകതകളും ലിസ്റ്റ് ചെയ്യുന്നു. Azure ഓരോ കണക്ഷനും ഒരു പൂർണ്ണ സംയോജനം എടുക്കുന്നു, അതിനാൽ IKE ഫീൽഡുകളും IPsec ഫീൽഡുകളും ഒരുമിച്ച് വ്യക്തമാക്കുന്നു, ഒന്നൊന്നായി അല്ല.

PFS ഒരു ആവശ്യകതയാണ്, തിരിക്കാനുള്ള സ്വിച്ചല്ല

നിങ്ങളുടെ സുരക്ഷാ അടിസ്ഥാനരേഖ PFS ആവശ്യപ്പെടുന്നുവെങ്കിൽ, പരിഹാരം ഇരുവശത്തുമുള്ള രണ്ട് peer-കളും സ്വീകരിക്കുന്ന ഒരു ഗ്രൂപ്പാണ്, പൊരുത്തമുള്ള നയത്തിലൂടെ പ്രകടിപ്പിക്കുന്നു. പിശക് മാഞ്ഞുപോകാൻ PFS ഓഫ് ചെയ്യുന്നത് നിങ്ങൾ നിലനിർത്താൻ ശ്രമിച്ച സുരക്ഷാ സ്വഭാവം മാറ്റുന്നു, അത് സാധാരണയായി പിന്നീട് മറ്റൊരു പൊരുത്തക്കേടായി തിരികെ വരുന്നു.

Azure-ന് പ്രത്യേകമായ ഒരു കെണി: ESP-യ്ക്ക് GCM തിരഞ്ഞെടുക്കുമ്പോൾ, എൻക്രിപ്ഷൻ, സമഗ്രത തിരഞ്ഞെടുപ്പുകൾ ഒരേ GCM അൽഗോരിതവും ഒരേ കീ നീളവും പേരിടണം. GCM സൈഫർ വേറിട്ട സമഗ്രത അൽഗോരിതവുമായി കലർത്തുന്നത് സേവനം നിരസിക്കുന്ന സംയോജനം ഉണ്ടാക്കുന്നു, നയം ശ്രദ്ധാപൂർവ്വം വായിക്കുന്നതുവരെ അത് peer പൊരുത്തക്കേടായി തോന്നും.

ഇരുവശവും പിന്തുണയ്ക്കുന്നതും നിങ്ങളുടെ ആവശ്യകത അനുവദിക്കുന്നതുമായ ഏറ്റവും ശക്തമായ സംയോജനം തിരഞ്ഞെടുത്ത്, അത് മാറ്റരേഖയിൽ എഴുതുക. അടുത്ത വ്യക്തി ആ രേഖയുമായി താരതമ്യം ചെയ്യും, പ്രവർത്തിച്ചിരുന്ന ടണലിന്റെ ഓർമ്മയുമായി അല്ല. അതിൽ PFS ഗ്രൂപ്പും ESP നിർദ്ദേശവും ചേർക്കുക, നയത്തിന്റെ പേര് മാത്രമല്ല. പിന്നീട് ആരെങ്കിലും ഓഡിറ്റ് എന്തുകൊണ്ട് പരാജയപ്പെട്ടു അല്ലെങ്കിൽ റീകീ എന്തുകൊണ്ട് സാവധാനമാണ് എന്ന് ചോദിച്ചാൽ, ആ വരി രണ്ട് ചോദ്യങ്ങൾക്കും ഉത്തരം നൽകുന്നു.

പരാജയപ്പെട്ട കൈമാറ്റം പരിശോധിക്കുക

മാറ്റം വീണ്ടെടുക്കൽ പാതയോടെ ഷെഡ്യൂൾ ചെയ്യുക, കാരണം നയം എഡിറ്റ് ചെയ്യുന്നത് നിങ്ങൾ ശരിയാക്കാൻ ശ്രമിക്കുന്ന ടണലിനെ തടസ്സപ്പെടുത്താം. ട്രാഫിക് തിരികെ വന്നതിന് ശേഷം CHILD_SA പുതുക്കലിനായി കാത്തിരിക്കുകയോ അത് പ്രവർത്തിപ്പിക്കുകയോ ചെയ്ത്, പുതിയ അസോസിയേഷൻ ഉദ്ദേശിച്ച PFS ഗ്രൂപ്പിനൊപ്പം സ്ഥാപിക്കപ്പെട്ടെന്ന് സ്ഥിരീകരിക്കുക. തുടർന്ന് അപ്ലിക്കേഷൻ ട്രാഫിക് അതിലൂടെ തുടരുന്നുവെന്ന് സ്ഥിരീകരിക്കുക.

രണ്ട് തെറ്റായ സൂചനകൾ പേരിടേണ്ടതുണ്ട്. SA ആയുസ്സുകൾ പ്രാദേശിക സ്പെസിഫിക്കേഷനുകളാണ്, അതിനാൽ അസമമായ മൂല്യങ്ങൾ സാധാരണമാണ്, അവ മാറ്റുന്നത് പ്രശ്നം എപ്പോൾ പ്രത്യക്ഷപ്പെടുന്നു എന്നത് മാത്രം മാറ്റുന്നു. DPD ഒരു peer ജീവിച്ചിരിക്കുന്നുണ്ടോ എന്ന് കണ്ടെത്തുന്നു; അതിന്റെ സമയപരിധി ഉയർത്തുന്നത് ESP അല്ലെങ്കിൽ PFS തിരഞ്ഞെടുപ്പുകൾ വിന്യസിക്കുന്നില്ല.

മാറ്റത്തിന് ശേഷം ചർച്ച ചെയ്ത ഫലവും അടുത്ത സംഭവവും രേഖപ്പെടുത്തുക. കണക്ഷൻ ഇപ്പോൾ IKE പ്രാമാണീകരണം പൂർത്തിയാകുന്നതിന് മുമ്പ് പരാജയപ്പെടുന്നുവെങ്കിൽ, നിങ്ങൾ ഇപ്പോൾ എഡിറ്റ് ചെയ്ത IKE ക്രമീകരണങ്ങളെ നോക്കുന്നു, യഥാർത്ഥ CHILD പുതുക്കൽ പരാജയത്തെയല്ല.