പല സബ്‌നെറ്റുകളുള്ള IPsec തിരിച്ചുള്ള ട്രാഫിക് നഷ്ടപ്പെടുത്തുന്നുവോ? reqid എണ്ണുക

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

എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് ലക്ഷണം വേർതിരിക്കുക

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

MTU-യിൽ തുടങ്ങരുത്. തെറ്റായ MTU കുരുക്കും ശകലന ലക്ഷണങ്ങളും ഉണ്ടാക്കുന്നു, ഉയരുന്ന പുറത്തേക്കുള്ള കൗണ്ടറുകളോടെ വ്യക്തമായ ദിശാ വിഭജനമല്ല.

നയ ഡാറ്റാബേസും അവസ്ഥാ ഡാറ്റാബേസും വായിക്കുക

Linux-ൽ എൻക്രിപ്ഷൻ നിർണ്ണയിക്കുന്നത് നയ രേഖകളാണ്, അതിനാൽ പൊരുത്തപ്പെടുന്ന നയം, റൂട്ടല്ല, പാക്കറ്റിനെ ടണലിലേക്ക് കടത്തുന്നു. ഓരോ രേഖയുടെയും സെലക്ടറുകൾ, ദിശ, മുൻഗണന, ടെംപ്ലേറ്റ് എന്നിവ കാണാൻ ip xfrm policy പ്രവർത്തിപ്പിക്കുക, സ്ഥാപിത അസോസിയേഷനുകൾ അവയുടെ reqid-കളോടെ കാണാൻ ip xfrm state പ്രവർത്തിപ്പിക്കുക. നയവും അസോസിയേഷനും ആ reqid-യാൽ ബന്ധിപ്പിക്കപ്പെടുന്നു.

മൂന്ന് ദിശകളും നോക്കുക. പുറത്തേക്കും അകത്തേക്കുമുള്ളത് ഈ ഹോസ്റ്റിലേക്കും ഇവിടെ നിന്നുമുള്ള ട്രാഫിക് ഉൾക്കൊള്ളുന്നു; ഫോർവേഡ് ദിശ ഹോസ്റ്റ് മറ്റുള്ളവർക്കായി റൂട്ട് ചെയ്യുമ്പോൾ പ്രധാനമാണ്. ഒരു ദിശയിൽ ഇല്ലാത്തതോ പൊരുത്തപ്പെടാത്തതോ ആയ രേഖ ഒരു ക്രിപ്റ്റോഗ്രാഫിക് തകരാറും കൂടാതെ ഏകദിശാ ഫലം വിശദീകരിക്കുന്നു.

ക്ലാസിക് അസമത്വം: പല സബ്‌നെറ്റുകൾക്ക് ഒരു reqid

സാധാരണ പരാജയം, ചർച്ച ചെയ്ത എല്ലാ സബ്‌നെറ്റുകളുടെയും നയങ്ങൾ ഒരൊറ്റ reqid-ക്ക് കീഴിൽ ഇൻസ്റ്റാൾ ചെയ്യുന്ന പങ്കാളിയിൽ നിന്ന് വരുന്നു, ഇത് racoon-ന്റെ generate_policy require സമയത്ത് സംഭവിക്കുന്നു. ട്രാഫിക് പിന്നീട് അവസാനം സ്ഥാപിതമായ അസോസിയേഷനിലൂടെ പുറത്തുപോകുന്നു, മറുവശം ഓരോ സബ്‌നെറ്റിനും പ്രത്യേക അസോസിയേഷൻ സൂക്ഷിക്കുന്നു. മറുപടികൾ അവയെ സ്വീകരിക്കേണ്ട നയം reqid സൂചിപ്പിക്കാത്ത അസോസിയേഷനിൽ എത്തുന്നു, കേർണൽ ഡീക്രിപ്ഷന് ശേഷം അവ വലിച്ചെറിയുന്നു.

പരിഹാരം ഒരു കോൺഫിഗറേഷൻ മാറ്റമാണ്, ഫയർവാൾ നിയമമല്ല: generate_policy unique; ഓരോ നയത്തിനും അതിന്റേതായ reqid നൽകുന്നു, അതിനാൽ പങ്കാളിയുടെ നയം തോറുമുള്ള അസോസിയേഷനുകൾക്ക് പൊരുത്തപ്പെടുന്ന പങ്കാളികളുണ്ട്. അത് പ്രയോഗിക്കുക, വീണ്ടും ചർച്ച ചെയ്യുക, വിജയം പ്രഖ്യാപിക്കുന്നതിന് മുൻപ് പ്രതീക്ഷിക്കുന്ന സബ്‌നെറ്റുകൾക്കായി വ്യത്യസ്ത reqid-കൾ എണ്ണുക.

രണ്ട് സബ്‌നെറ്റുകൾ ഇപ്പോഴും ഒരു reqid പങ്കിടുമ്പോൾ മറുവശം രണ്ടെണ്ണം പ്രതീക്ഷിക്കുന്നുവെങ്കിൽ, നിങ്ങൾ അസമത്വം കണ്ടെത്തി. മാപ്പിംഗ് രേഖപ്പെടുത്തുക, കാരണം അടുത്ത മാറ്റം അത് ശരിയാക്കിയോ നിലനിർത്തിയോ എന്നതിന് അതാണ് തെളിവ്.

സെലക്ടറുകൾ ചർച്ചയിൽ നിന്ന് വരുന്നു, നിങ്ങളുടെ കോൺഫിഗറേഷനിൽ നിന്നല്ല

സംരക്ഷിത ശ്രേണികൾ ഇരു അറ്റങ്ങളും സമ്മതിച്ചതാണ്, ഒരു വശം ആവശ്യപ്പെട്ടതല്ല. വിശാലമായ ദൂര ശ്രേണിക്കെതിരെ ഹോസ്റ്റ് ജോടി വാഗ്ദാനം ചെയ്യുന്ന ക്ലയന്റിന് ഗേറ്റ്‌വേയുടെ ഇടുങ്ങിയ പതിപ്പ് ലഭിക്കുന്നു, ക്ലയന്റിന് അത് വിശാലമാക്കാനാവില്ല. ഇൻസ്റ്റാൾ ചെയ്ത സെലക്ടറുകൾ വായിക്കുക, നിങ്ങളുടെ പ്രാദേശിക ഫയലിലുള്ളവയല്ല.

ലക്ഷ്യം വിപരീതമാകുമ്പോൾ, അതായത് ഒരു ലക്ഷ്യസ്ഥാനം ടണലിന് പുറത്ത് നിർത്തൽ, സ്വയമേവ ഇൻസ്റ്റാൾ ചെയ്ത രേഖയെ തോൽപ്പിക്കാൻ കുറഞ്ഞ മുൻഗണനാ സംഖ്യയുള്ള ബൈപാസ് നയം ചേർക്കുക. ടെംപ്ലേറ്റില്ലാത്ത നയം വ്യക്തമായ ടെക്സ്റ്റ് അനുവദിക്കുന്നു, ഇത് അതിനെ മാറ്റ രേഖയ്ക്കുള്ള ബോധപൂർവമായ ഒഴിവാക്കലാക്കുന്നു, ഡീബഗ്ഗിംഗ് ഘട്ടമല്ല.

ഈ ക്രമത്തിൽ പരിശോധിക്കുക, എങ്ങനെ പിന്നോട്ട് പോകാമെന്ന് അറിയുക

ഓരോ സബ്‌നെറ്റിനും രണ്ട് ദിശകളിലും നയങ്ങൾ ലിസ്റ്റ് ചെയ്യുക, ഹോസ്റ്റ് റൂട്ട് ചെയ്യുന്നുവെങ്കിൽ ഫോർവേഡ് ദിശയും ഉൾപ്പെടെ. വ്യത്യസ്ത reqid-കൾ എണ്ണി പ്രതീക്ഷിക്കുന്ന വശത്ത് ഓരോ നയത്തിനും ഒന്നുണ്ടെന്ന് ഉറപ്പാക്കുക. ഇൻസ്റ്റാൾ ചെയ്ത സെലക്ടറുകളെ സമ്മതിച്ചവയുമായി താരതമ്യം ചെയ്യുക. കീ പുതുക്കലിന് ശേഷം അസോസിയേഷൻ തോറുമുള്ള കൗണ്ടറുകൾ വീണ്ടും വായിക്കുക, കാരണം നിങ്ങൾ പരിശോധിച്ച അസോസിയേഷൻ ഇതിനകം പോയിരിക്കാം. റൂട്ടുകൾ ഒടുവിൽ പരിശോധിക്കുക, കാരണം ദൂരെയുള്ള സബ്‌നെറ്റിലേക്കുള്ള റൂട്ട് ഇല്ലാതിരിക്കുന്നത് വ്യക്തമായ നയ കൗണ്ടറുകളോടെ സമാനമായ ഏകദിശാ ലക്ഷണം ഉണ്ടാക്കുന്നു.

പങ്കാളിയെ മാറ്റുന്നതിന് മുൻപ് രണ്ട് xfrm കമാന്റുകളുടെയും നിലവിലെ ഔട്ട്പുട്ട് സേവ് ചെയ്യുക. പുതിയ ക്രമീകരണം തിരിച്ചുള്ള ദിശ പുനഃസ്ഥാപിക്കുന്നില്ലെങ്കിൽ, ആ ഔട്ട്പുട്ട് പുനഃസ്ഥാപിക്കുന്നത് ഓർമ്മയിൽ നിന്ന് ടണൽ വീണ്ടും നിർമ്മിക്കുന്നതിനെക്കാൾ വേഗതയേറിയ പിൻവാങ്ങലാണ്, താരതമ്യം സത്യസന്ധമായി നിലനിർത്തുന്നു.