strongSwan trap മോഡ്: IPsec ടണൽ ട്രാഫിക്കിനായി കാത്തിരിക്കുന്നത് എന്തുകൊണ്ട്
നിഷ്ക്രിയ ഓൺ-ഡിമാൻഡ് IPsec ടണൽ പാക്കറ്റ് അതിന്റെ trap നയവുമായി പൊരുത്തപ്പെടുന്നതുവരെ CHILD SA കാണിക്കുന്നില്ല. അവസ്ഥ വായിക്കുക, ട്രിഗർ പരിശോധിക്കുക, start എപ്പോൾ അനുയോജ്യമെന്ന് അറിയുക.
സ്റ്റാറ്റസ് ഔട്ട്പുട്ടിൽ CHILD SA കാണാനില്ല, ടണൽ മരിച്ചതുപോലെ തോന്നുന്നു, പിന്നീട് ദൂരെയുള്ള സബ്നെറ്റിലേക്കുള്ള ping അതിനെ ഉയർത്തുന്നു. ഓൺ-ഡിമാൻഡ് IPsec ക്രമീകരണത്തിൽ ഈ ക്രമം ഡിസൈനാണ്, തകരാറല്ല. trap നയം ഒരു സെലക്ടർ ഇൻസ്റ്റാൾ ചെയ്ത് കാത്തിരിക്കുന്നു, അതുമായി പൊരുത്തപ്പെടുന്ന ആദ്യ പാക്കറ്റാണ് IKE-യും CHILD SA ചർച്ചയും ആരംഭിക്കുന്നത്.
ആശയക്കുഴപ്പത്തിന്റെ ഒരു ഭാഗം പദാവലിയാണ്: “up” രണ്ട് വ്യത്യസ്ത അവസ്ഥകൾക്ക് ഉപയോഗിക്കുന്നു. കോൺഫിഗറേഷൻ ലോഡ് ചെയ്തു, കേർണൽ നയം നിലവിലുണ്ട്, ഡാറ്റ അസോസിയേഷൻ ഇല്ല. സജീവ SA മാത്രം എണ്ണുന്ന മോണിറ്റർ, ആരും അങ്ങോട്ട് ട്രാഫിക് അയക്കാത്തിടത്തോളം ആരോഗ്യമുള്ള സൈറ്റിനെ ഡൗൺ എന്ന് റിപ്പോർട്ട് ചെയ്യും.
നിഷ്ക്രിയ ഓൺ-ഡിമാൻഡ് ടണലിന് കാണിക്കാൻ CHILD SA ഇല്ല
trap എൻട്രി സ്വയം ഒന്നും പ്രാമാണീകരിക്കുന്നില്ല. തിരഞ്ഞെടുത്ത ട്രാഫിക്കിന് ഒരു നയം സൂക്ഷിക്കാനും, പാക്കറ്റിന് ആ നയം ആവശ്യമാകുമ്പോൾ acquisition ഉയർത്താനും കേർണലിനോട് ആവശ്യപ്പെടുന്നു. ഡീമൺ acquisition സ്വീകരിച്ച് child നിർവചനവുമായി ചേർത്ത് അവിടെ നിന്ന് ചർച്ച നടത്തുന്നു. അതുവരെ കാണിക്കാൻ IKE SA ഉം ഇല്ല, അതിനാൽ രണ്ട് പട്ടികകളും ഒരേസമയം ശൂന്യമായിരിക്കാം.
ഈ ക്രമമാണ് ലോഗുകളെ വായിക്കാവുന്നതാക്കുന്നത്. ആദ്യം acquisition വരുന്നു, പിന്നെ IKE_SA_INIT ഉം IKE_AUTH ഉം, പിന്നെ CHILD SA. acquisition-ന് ശേഷം ഉടനെ ലോഗ് അവസാനിക്കുന്നുവെങ്കിൽ ട്രിഗർ പ്രവർത്തിച്ചു. ചർച്ച പരാജയപ്പെട്ടു, അടുത്ത ചോദ്യം ട്രാപ്പിനെക്കുറിച്ചല്ല, ക്രെഡൻഷ്യലുകൾ, നിർദ്ദേശങ്ങൾ അല്ലെങ്കിൽ എത്തിച്ചേരൽ എന്നിവയെക്കുറിച്ചാണ്.
Linux കേർണൽ ബാക്കെൻഡിൽ ഏതെങ്കിലും SA നിലവിൽ വരുന്നതിന് മുൻപ് നയം കാണാം. ഇത് പ്രവർത്തിപ്പിക്കുക: ip xfrm policy . out ദിശയും കണക്ഷനിലേക്ക് സൂചിപ്പിക്കുന്ന ടെംപ്ലേറ്റുമുള്ള സെലക്ടർ കണ്ടെത്തുക. ആ എൻട്രിയാണ് ഓൺ-ഡിമാൻഡ് അവസ്ഥ, അതിന്റെ സാന്നിധ്യമാണ് ആദ്യം സ്ഥിരീകരിക്കേണ്ടത്.
start_action എന്തെങ്കിലും കാത്തിരിക്കുമോ ഇല്ലയോ എന്ന് തീരുമാനിക്കുന്നു
ഓരോ child swanctl.conf ഫയലിൽ start_action. start കോൺഫിഗറേഷൻ ലോഡ് ചെയ്യുമ്പോൾ ആരംഭിക്കുന്നു, trap നയം ഇൻസ്റ്റാൾ ചെയ്ത് കാത്തിരിക്കുന്നു, none ആരംഭം മറ്റൊന്നിന് വിട്ടുകൊടുക്കുന്നു. trap മാത്രമാണ് മുകളിൽ വിവരിച്ച “ping ചെയ്താൽ ഉയരും” സ്വഭാവം സൃഷ്ടിക്കുന്നത്.
children {
office-lan {
local_ts = 192.168.50.0/24
remote_ts = 192.168.70.0/24
start_action = trap
}
}
രണ്ട് ട്രാഫിക് സെലക്ടറുകൾ എന്താണ് താൽപ്പര്യമുള്ളതായി കണക്കാക്കുന്നതെന്ന് നിർവചിക്കുന്നു, ആ പ്രിഫിക്സുകൾക്ക് പുറത്തുള്ള ഹോസ്റ്റിൽ നിന്നുള്ള പാക്കറ്റ് trap പ്രവർത്തിപ്പിക്കുന്നില്ല; അത് സാധാരണപോലെ റൂട്ട് ചെയ്യുന്നു. ട്രിഗർ കൂടുതൽ ഉത്സാഹിയാക്കാൻ സെലക്ടറുകൾ വിശാലമാക്കുന്നത് ടണൽ സംരക്ഷിക്കുന്നുവെന്ന് അവകാശപ്പെടുന്ന പരിധിയും വിശാലമാക്കുന്നു, അതിനാൽ നിങ്ങൾ യഥാർത്ഥത്തിൽ എൻക്രിപ്റ്റ് ചെയ്യാൻ ഉദ്ദേശിക്കുന്ന ട്രാഫിക്കിൽ നിന്ന് അവ ഉരുത്തിരിക്കുക.
ഇവിടെ swanctl.conf റഫറൻസ് സ്വീകാര്യമായ മൂല്യങ്ങൾ പട്ടികപ്പെടുത്തുന്നു, SA നിലവിലായതിന് ശേഷം എന്ത് സംഭവിക്കുമെന്ന് നിയന്ത്രിക്കുന്ന പ്രത്യേക close, DPD പ്രവർത്തനങ്ങളും.
ട്രിഗർ യഥാർത്ഥത്തിൽ പ്രവർത്തിച്ചോ എന്ന് കണ്ടെത്തുക
ഇതിൽ നിന്ന് തുടങ്ങുക: swanctl --list-conns , child ഉദ്ദേശിച്ച പ്രവർത്തനത്തോടെ ലോഡ് ചെയ്തിട്ടുണ്ടെന്ന് സ്ഥിരീകരിക്കുക. പിന്നീട് local_ts അകത്തുള്ള ഹോസ്റ്റിൽ നിന്ന് remote_ts അകത്തുള്ള വിലാസത്തിലേക്ക് ഒരു പാക്കറ്റ് അയച്ച് swanctl --list-sas നിരീക്ഷിക്കുക. ഔട്ട്പുട്ട് മാറുന്നില്ലെങ്കിൽ, ഒരു acquisition-ഉം ഡീമണിലെത്തിയില്ല.
നിശബ്ദ trap-ന് രണ്ട് സാധാരണ കാരണങ്ങൾ: പാക്കറ്റ് നയത്തിൽ എത്തുന്നതിന് മുൻപ് source-NAT ചെയ്യപ്പെട്ടു, ഇപ്പോൾ local_ts മായി പൊരുത്തപ്പെടുന്നില്ല, അല്ലെങ്കിൽ സിന്റാക്സ് അല്ലെങ്കിൽ ക്രെഡൻഷ്യൽ പിശകിനാൽ കണക്ഷൻ ഒരിക്കലും ലോഡായില്ല. സെലക്ടറുകൾ തൊടുന്നതിന് മുൻപ് swanctl --load-all വീണ്ടും പ്രവർത്തിപ്പിച്ച് അതിന്റെ ഔട്ട്പുട്ട് വായിക്കുക. ലോഡാകാത്ത കണക്ഷൻ ഒരു നയവും ഇൻസ്റ്റാൾ ചെയ്യുന്നില്ല, അതിനാൽ ട്രാഫിക്കിന് പ്രവർത്തിപ്പിക്കാൻ ഒന്നുമില്ല.
ദിശയും പ്രധാനമാണ്: പുറത്തേക്കുള്ള ട്രാഫിക്കിനായി ഇൻസ്റ്റാൾ ചെയ്ത trap അകത്തേക്കുള്ള പാക്കറ്റിൽ ആരംഭിക്കുന്നില്ല. ദൂരെയുള്ള വശമാണ് ടണൽ ഉയർത്തേണ്ടതെങ്കിൽ അതിന് സ്വന്തം trap വേണം, അല്ലെങ്കിൽ ഈ വശത്തിന് start.
ആദ്യ പാക്കറ്റിനായി കാത്തിരിക്കുന്നത് എല്ലായ്പ്പോഴും ശരിയായ കൈമാറ്റമല്ല
സംവേദനാത്മക സെഷനുകൾ സെറ്റപ്പ് ചെലവ് അനുഭവിക്കുന്നു. ആദ്യ അഭ്യർത്ഥന IKE കൈമാറ്റത്തിന്റെയും CHILD ചർച്ചയുടെയും വില നൽകുന്നു, കുറഞ്ഞ സമയപരിധിയുള്ള ക്ലയന്റ് SA നിലവിൽ വരുന്നതിന് മുൻപ് പിൻവാങ്ങാം. സജീവമായ start ആ ആദ്യ-പാക്കറ്റ് കാലതാമസം നീക്കുന്നു. പക്ഷേ ഒരിക്കലും വന്നേക്കാത്ത ട്രാഫിക്കിനായി ടണൽ ഉയർത്തിവയ്ക്കുന്നു.
മൂന്ന് വസ്തുതകൾ തിരഞ്ഞെടുപ്പ് തീരുമാനിക്കുന്നു: പാത എത്ര തവണ ഉപയോഗിക്കുന്നു, ആദ്യ അഭ്യർത്ഥന് കർശനമായ സമയപരിധിയുണ്ടോ, ബൂട്ടിൽ പീയർ ലഭ്യമാണോ. ഇടയ്ക്കിടെയുള്ള ബാച്ച് ട്രാഫിക്കും ബൂട്ടിൽ ഓഫ്ലൈൻ ആകാവുന്ന പീയറും രണ്ടും അനുകൂലിക്കുന്നു trap നെ. കാലതാമസത്തോട് സംവേദനക്ഷമമായ ക്ലയന്റും എപ്പോഴും ലഭ്യമായ പീയറും അനുകൂലിക്കുന്നു start നെ. ഇരുവശത്തിനും ആരംഭിക്കാമെങ്കിൽ, ഇരട്ടി ചർച്ച ഒഴിവാക്കാൻ ട്രിഗർ ആരുടേതെന്ന് യോജിക്കുക.
ഇൻസ്റ്റാൾ ചെയ്ത നയവും ചോർച്ച-പ്രൂഫ് ഗ്യാരണ്ടിയല്ല. ആവശ്യകത fail-closed ആണെങ്കിൽ, SA ഇല്ലാത്ത ട്രാഫിക് ഫയർവാൾ ഉപേക്ഷിക്കണം, ആ നിയമം child നിർവചനത്തിന് പുറത്താണ്.
അടുത്ത വാദം അവസാനിപ്പിക്കുന്ന മൂന്ന് വരികൾ രേഖപ്പെടുത്തുക
സെലക്ടറുകൾ, സ്റ്റാർട്ടപ്പ് പ്രവർത്തനം, SA ഇല്ലാതെ നയം നിലവിലുണ്ടെന്ന് കാണിക്കുന്ന കമാൻഡ് ഔട്ട്പുട്ട് എന്നിവ എഴുതുക. ആ മൂന്ന് വരികൾ അടുത്ത തവണ ആരെങ്കിലും ടണൽ ഡൗൺ എന്ന് റിപ്പോർട്ട് ചെയ്യുമ്പോൾ “ഓൺ-ഡിമാൻഡും നിഷ്ക്രിയവും” എന്നതിനെ “ലോഡാകുന്നില്ല” എന്നതിൽ നിന്ന് വേർതിരിക്കുന്നു. രേഖപ്പെടുത്താൻ ഒരു മിനിറ്റ് മതി. അവയില്ലാതെ അതേ അന്വേഷണം പൂജ്യത്തിൽ നിന്ന് തുടങ്ങുന്നു.
സെലക്ടറിന് യഥാർത്ഥത്തിൽ അകത്തുള്ള ഹോസ്റ്റിൽ നിന്ന് പരീക്ഷിക്കുക. റൗട്ടറിൽ നിന്നുതന്നെയുള്ള ping പലപ്പോഴും വേറെ വഴി പോകുന്നു, അതിന് പിന്നിലുള്ള സബ്നെറ്റിനെ സംരക്ഷിക്കുന്ന നയത്തെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല.