നിങ്ങളുടെ IPsec ടണൽ ആദ്യ CHILD SA കീ പുതുക്കൽ വരെ മാത്രം പ്രവർത്തിക്കുന്നത് എന്തുകൊണ്ട്

ടണൽ ഉയർന്നു, ping മറുപടി നൽകി, എല്ലാവരും ഒപ്പിട്ടു. നാല് മണിക്കൂർ കഴിഞ്ഞ് സെഷൻ വീഴുന്നു, ഇരുവശവും നിർദ്ദേശ അല്ലെങ്കിൽ കീ-കൈമാറ്റ പിശക് രേഖപ്പെടുത്തുന്നു, ആദ്യ ഊഹം നെറ്റ്വർക്കിൽ എന്തോ മാറി എന്നാണ്. ഒന്നും മാറിയില്ല. ട്രാഫിക് കടത്തിക്കൊണ്ടുപോകുന്ന ടണൽ രണ്ട് വശങ്ങളും എങ്ങനെ പ്രാമാണീകരിക്കണം, ആദ്യത്തെ ചൈൽഡ് അസോസിയേഷൻ എങ്ങനെ സംരക്ഷിക്കണം എന്നിവയിൽ യോജിക്കുന്നു എന്ന് തെളിയിച്ചു, പുതുക്കലിൽ അവർ ആവശ്യപ്പെടുന്ന കീ കൈമാറ്റത്തെക്കുറിച്ച് ഒന്നും തെളിയിച്ചിട്ടില്ല. പൊരുത്തക്കേട് ആ രണ്ട് സംഭവങ്ങൾക്കിടയിലെ വിടവിൽ കിടക്കുന്നു.

ബന്ധിപ്പിച്ചിരിക്കുന്നു എന്നത് PFS ക്രമീകരണങ്ങൾ യോജിക്കുന്നു എന്നല്ല

IKEv2-ൽ, ആദ്യത്തെ ചൈൽഡ് അസോസിയേഷൻ പ്രാമാണീകരണ കൈമാറ്റത്തിനിടയിൽ സൃഷ്ടിക്കപ്പെടുന്നു, അതിന്റെ കീകൾ IKE അസോസിയേഷൻ ഇതിനകം നിർമ്മിച്ച വസ്തുവിൽ നിന്ന് ഉരുത്തിരിയുന്നു. ആ ചൈൽഡിനായി പ്രത്യേക Diffie-Hellman കൈമാറ്റം നടക്കുന്നില്ല, അതിനാൽ പുതുക്കലിൽ അത് ആവശ്യപ്പെടുന്ന നയം ഉയർത്തുമ്പോൾ പരിശോധിക്കപ്പെടുന്നില്ല.

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

നിർദ്ദേശ സ്ട്രിംഗിൽ പൊരുത്തക്കേട് എവിടെ ഒളിഞ്ഞിരിക്കുന്നു

strongSwan-ൽ ഗ്രൂപ്പ് ചൈൽഡ് നിർദ്ദേശത്തോട് ചേർക്കുന്നു, അതുകൊണ്ടാണ് aes256gcm16-prfsha256-ecp256 പോലുള്ള ഒരു സ്ട്രിംഗ് എൻക്രിപ്ഷൻ തിരഞ്ഞെടുപ്പായി തോന്നുന്നത്, പക്ഷേ അത് കീ കൈമാറ്റ ആവശ്യകതയും വഹിക്കുന്നു. കേവലം aes256gcm16-prfsha256 മാത്രം വാഗ്ദാനം ചെയ്യുന്ന വശത്തിന് അത്തരം ആവശ്യകതയില്ല, രണ്ട് പട്ടികകളും എൻക്രിപ്ഷനിൽ കൂടിച്ചേരുന്നു, കൈമാറ്റത്തിൽ വ്യത്യാസപ്പെടുന്നു.

ചൈൽഡ് നിർദ്ദേശവും IKE നിർദ്ദേശവും വെവ്വേറെ പട്ടികകളായി വായിക്കുക. IKE പട്ടികയിൽ കാണുന്ന ഗ്രൂപ്പ് ചൈൽഡ് പട്ടികയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, ഒന്ന് വായിക്കുമ്പോൾ മറ്റൊന്ന് തിരുത്തുന്നതാണ് ഇത് വിട്ടുപോകുന്ന സാധാരണ വഴി.

പരാജയം വായിക്കുക, തിരുത്തിയ ഫയലല്ല

കൈമാറ്റം അവസാനിപ്പിച്ച notify കണ്ടെത്തുക. സ്വീകാര്യമായ നിർദ്ദേശമില്ല എന്ന് തിരികെ നൽകുന്ന ചൈൽഡ് കീ പുതുക്കൽ നിർദ്ദേശ പട്ടികകളിലേക്ക് വിരൽ ചൂണ്ടുന്നു; ഒരിക്കലും മറുപടി ലഭിക്കാത്ത പുതുക്കൽ അഭ്യർത്ഥന പാതയിലേക്കോ കേൾക്കുന്നത് നിർത്തിയ വശത്തിലേക്കോ ചൂണ്ടുന്നു. ഇവ രണ്ടിനും വ്യത്യസ്ത പരിഹാരങ്ങൾ വേണം, ലോഗ് വരിയുടെ പദപ്രയോഗം അവയെ വേർതിരിക്കുന്നു.

ഡിസ്കിലുള്ളതല്ല, പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷൻ ഉറപ്പാക്കുക. സേവ് ചെയ്തെങ്കിലും ലോഡ് ചെയ്യാത്ത ഫയൽ, അല്ലെങ്കിൽ മറ്റൊരു include-ൽ നിന്ന് വീണ്ടും വായിച്ച കണക്ഷൻ, കാണുന്ന ഫയൽ എത്ര തിരുത്തിയാലും ശരിയാകാത്ത പൊരുത്തക്കേട് ഉണ്ടാക്കും.

എല്ലാം കീ പുതുക്കൽ എന്ന് വിളിക്കുന്ന മൂന്ന് സംഭവങ്ങൾ

IKE അസോസിയേഷന്റെ കീ പുതുക്കൽ, IKE വീണ്ടും പ്രാമാണീകരണം, ചൈൽഡ് അസോസിയേഷന്റെ കീ പുതുക്കൽ എന്നിവ വെവ്വേറെ നിർദ്ദേശ നിയമങ്ങളുള്ള വെവ്വേറെ പ്രവർത്തനങ്ങളാണ്. അവയിലൊന്നിൽ റിപ്പോർട്ട് ചെയ്യുന്ന പരാജയം മറ്റുള്ളവയെക്കുറിച്ച് നേരിട്ട് ഒന്നും പറയുന്നില്ല, അവയെ കലർത്തുന്ന ലോഗ് മൂന്നെണ്ണമുള്ളപ്പോഴും ഒരു ആവർത്തിച്ചുള്ള തകരാറായി വായിക്കപ്പെടുന്നു.

വശം ഏത് സംഭവത്തെ പേരിടുന്നു എന്ന് ശ്രദ്ധിക്കുക, എന്നിട്ട് ആ സംഭവത്തിന് മാത്രം നിർദ്ദേശങ്ങൾ പരിശോധിക്കുക. ഒരു പട്ടിക മാറ്റി, വീണ്ടും ലോഡ് ചെയ്ത്, അതേ സംഭവം വീണ്ടും നിർബന്ധിക്കുക. ലോഗ് വീണ്ടും പ്രാമാണീകരണം പേരിടുന്നുവെങ്കിൽ വായിക്കേണ്ടത് IKE നിർദ്ദേശമാണ്. ചൈൽഡ് കീ പുതുക്കൽ പേരിടുന്നുവെങ്കിൽ പ്രധാന ഗ്രൂപ്പ് ചൈൽഡ് നിർദ്ദേശം വഹിക്കുന്നു.

പുതുക്കൽ ഓഫ് ചെയ്യുന്നത് പരിഹാരമല്ല

കീ പുതുക്കൽ സമയം പൂജ്യമാക്കുന്നത് പരാജയപ്പെടുന്ന കൈമാറ്റം അടക്കിവെക്കുന്നു, ടണൽ പിന്നീട് പൊളിച്ചുമാറ്റുന്നതുവരെയോ വശം പുനരാരംഭിക്കുന്നതുവരെയോ നിലനിൽക്കുന്നു. നിങ്ങൾ വാങ്ങിയത് ദീർഘായുസ്സുള്ള ഒരു കീയും, കുടിയേറ്റത്തിലോ ഓഡിറ്റിലോ വെണ്ടർ അപ്ഡേറ്റിലോ വീണ്ടും നേരിടുന്ന പൊരുത്തക്കേടുമാണ്. മറുവശം പ്രതീക്ഷിക്കുന്ന നയത്തിന് എത്രയോ അപ്പുറം നീട്ടിയ ആയുസ്സുകൾക്കും ഇത് ബാധകമാണ്.

പകരം നിർദ്ദേശങ്ങൾ ഒരുപോലെയാക്കുക. ഇരുവശവും നടപ്പിലാക്കുന്ന ഒരു ഗ്രൂപ്പ് തിരഞ്ഞെടുത്ത്, ഇരുവശത്തും ചൈൽഡ് നിർദ്ദേശത്തിൽ ഇടുക, പുതുക്കൽ നയം സംഘടന യഥാർത്ഥത്തിൽ ആവശ്യപ്പെടുന്ന പരിധിക്കുള്ളിൽ നിർത്തുക.

പരാജയപ്പെട്ട കൈമാറ്റം കൊണ്ട് അത് തെളിയിക്കുക

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

അതിനുശേഷം സാധാരണ ആയുസ്സ് പുനഃസ്ഥാപിച്ച്, പരാജയപ്പെട്ടതും വിജയിച്ചതുമായ രണ്ട് സംഭവ രേഖകളും സൂക്ഷിക്കുക. നിങ്ങൾ ആഗ്രഹിക്കുന്ന തെളിവ്, കണക്ഷൻ അതിന്റെ സ്വന്തം ജീവിതചക്രം അതിജീവിക്കുന്നു എന്നതാണ്, ping അതിജീവിച്ചു എന്നല്ല.