IKEv2 NO_PROPOSAL_CHOSEN: ഏത് ഘട്ടമാണ് സ്യൂട്ട് നിരസിച്ചത്?

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

ആദ്യം: ഏത് വിനിമയമാണ് നിരസിക്കപ്പെട്ടത്

IKEv2 രണ്ട് തരത്തിലുള്ള അസോസിയേഷനുകൾ ചർച്ച ചെയ്യുന്നു. IKE SA ചർച്ചയെത്തന്നെ സംരക്ഷിക്കുന്നു, CHILD SA ട്രാഫിക്ക് സംരക്ഷിക്കുന്നു. ഓരോന്നിനും സ്വന്തം നിർദ്ദേശ ഗണമുണ്ട്, ഓരോന്നും ഒരേ അറിയിപ്പോടെ പരാജയപ്പെടാം. പ്രാരംഭ IKE ചർച്ചയിലെ നിരസിക്കലും CHILD ചർച്ചയിലെ നിരസിക്കലും വ്യത്യസ്ത പരിഹാരങ്ങൾ ആവശ്യപ്പെടുന്നു, കൂടാതെ അറിയിപ്പിന് ഒന്നോ രണ്ടോ വരി മുകളിൽ ലോഗ് സാധാരണയായി വിനിമയത്തിന്റെ പേര് നൽകുന്നു. ആ രണ്ട് വരികളും ഒരുമിച്ച് വായിക്കുക, അല്ലെങ്കിൽ തെറ്റായ നിർദ്ദേശ പട്ടിക തിരുത്തും.

അറിയിപ്പ് മാത്രം വിനിമയത്തെ തിരിച്ചറിയുന്നില്ല. അതിന് മുകളിലുള്ള വരി ചർച്ച ചെയ്യുന്ന SAയുടെ പേര് നൽകുന്നു, ആ പേര് പരിശോധിക്കേണ്ട നിർദ്ദേശ പട്ടികയിലേക്ക് വിരൽ ചൂണ്ടുന്നു.

പൂർണ്ണ ഗണങ്ങൾ താരതമ്യം ചെയ്യുക, വ്യക്തിഗത കീവേഡുകളല്ല

ഒരു നിർദ്ദേശം ഒരു സംയോജനമാണ്: എൻക്രിപ്ഷൻ അൽഗോരിതം, സമഗ്രത അല്ലെങ്കിൽ AEAD, കീ-കൈമാറ്റ ഗ്രൂപ്പ്, ഏതെങ്കിലും സ്യൂഡോ-റാൻഡം ഫംഗ്ഷൻ. എൻക്രിപ്ഷന്റെ പേര് മാത്രം താരതമ്യം ചെയ്യുന്നത് സാധാരണ തെറ്റാണ്, കാരണം രണ്ട് സമപ്രായക്കാർക്ക് AES-256ൽ യോജിക്കാം, എന്നിട്ടും SHA-1നും SHA-256നും ഇടയിൽ അഭിപ്രായവ്യത്യാസം നിലനിർത്താം. പരാജയപ്പെട്ട ഘട്ടത്തിൽ നൽകിയതും അനുവദിച്ചതുമായ സ്യൂട്ടുകൾ അടുത്തടുത്തായി എഴുതുക, തുടർന്ന് ശൂന്യമായ ഛേദം തിരയുക.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

ഒപ്പം രണ്ട് നടപ്പാക്കലുകളും നിങ്ങൾ കോൺഫിഗർ ചെയ്തത് പിന്തുണയ്ക്കുന്നുണ്ടെന്ന് പരിശോധിക്കുക. മറ്റൊരു പ്ലാറ്റ്ഫോമിൽ നിന്ന് പകർത്തിയ പേര് വാക്യഘടനപരമായി പരിചിതമായി തോന്നാം എന്നാൽ പ്ലഗിൻ അല്ലെങ്കിൽ നടപ്പാക്കൽ പൂർണ്ണമായും ഇല്ല.

IKE സ്യൂട്ടും ESP സ്യൂട്ടും വ്യത്യസ്ത വസ്തുക്കളാണ്

IKE നിർദ്ദേശം തിരുത്തുന്നത് നിരസിക്കപ്പെട്ട CHILD നിർദ്ദേശം പരിഹരിക്കില്ല, തിരിച്ചും ശരിയാണ്. strongSwanൽ ഇവ വെവ്വേറെ ക്രമീകരണങ്ങളാണ്, ഏകദേശം IKE SAയ്ക്ക് proposals = aes256-sha256-modp2048, CHILD SAയ്ക്ക് വേറിട്ട ESP പട്ടിക. പരാജയപ്പെട്ട വിനിമയത്തിന് യോജിക്കുന്ന പട്ടിക മാറ്റുക, തുടർന്ന് പരിഹാരം പ്രവർത്തിച്ചുവെന്ന് കരുതാതെ ലോഗ് വീണ്ടും വായിക്കുക.

CHILD SAയ്ക്ക് പ്രസക്തമായ ക്രമീകരണം ESP നിർദ്ദേശ പട്ടികയാണ്, IKE പട്ടികയല്ല. അതിലേക്ക് IKE വരി പകർത്തുന്നത് പാഴ്സ് ചെയ്യുന്നതും എന്നാൽ തെറ്റായ വസ്തുവിനെ ചർച്ച ചെയ്യുന്നതുമായ കോൺഫിഗറേഷൻ സൃഷ്ടിക്കുന്നു.

പ്രവർത്തിക്കുന്ന ടണൽ കീ പുതുക്കലിൽ പരാജയപ്പെടുന്നു

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

ipsec statusall ഓരോ അസോസിയേഷനും യഥാർത്ഥത്തിൽ ചർച്ച ചെയ്ത അൽഗോരിതങ്ങളും കാണിക്കുന്നു. ആ ഔട്ട്പുട്ട് ഏത് പട്ടിക ഉപയോഗിച്ചുവെന്ന് സ്ഥിരീകരിക്കാനുള്ള വേഗത്തിലുള്ള മാർഗമാണ്, കൂടാതെ കോൺഫിഗറേഷൻ പിശകിനെ വീണ്ടും ചർച്ച ചെയ്യാത്ത പഴയ ടണലിൽ നിന്ന് വേർതിരിക്കുന്നു.

ipsec statusall | grep -E "IKE:|ESP:"

ഒരു ഛേദം തിരഞ്ഞെടുക്കുക, തുടർന്ന് രണ്ട് ഘട്ടങ്ങളും സ്ഥിരീകരിക്കുക

ഇരു സമപ്രായക്കാരും പിന്തുണയ്ക്കുന്ന രേഖപ്പെടുത്തിയ ആധുനിക ഛേദം തിരഞ്ഞെടുക്കാനും അത് എഴുതിവയ്ക്കാനും അഡ്മിനിസ്ട്രേറ്ററിനോട് ആവശ്യപ്പെടുക. എല്ലാ പഴയ അൽഗോരിതങ്ങളും പ്രവർത്തനക്ഷമമാക്കിയോ ഐഡന്റിറ്റി പരിശോധന നിർത്തലാക്കിയോ പിശക് പരിഹരിക്കരുത്, കാരണം രണ്ടും നിരസിക്കലിൽ നിന്ന് ഉരുത്തിരിയുന്നതല്ല. മാറ്റത്തിന് ശേഷം പുതിയ കണക്ഷൻ സ്ഥാപിക്കുക, തുടർന്ന് കീ പുതുക്കൽ നിർബന്ധമാക്കുക. ആദ്യ കണക്ഷൻ മാത്രം പുതുക്കൽ പാത പ്രവർത്തിക്കുന്നുവെന്ന് തെളിയിക്കുന്നില്ല.

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