OpenVPN റൂട്ട് strongSwan XFRM നയത്തോട് എന്തുകൊണ്ട് തോൽക്കുന്നു
ഒരു പ്രത്യേക OpenVPN റൂട്ട് XFRM നയത്തെ മറികടക്കുന്നില്ല: റൂട്ടും നയത്തിന്റെ സെലക്ടറുകളും വായിക്കുക, തുടർന്ന് ചുരുക്കുക, ഒഴിവാക്കുക അല്ലെങ്കിൽ XFRM ഇന്റർഫേസിലേക്ക് പോകുക.
പാക്കറ്റുകൾ OpenVPN റൂട്ട് പിന്തുടർന്നാലും IPsec നയത്തിൽ കുടുങ്ങാം, ഈ സംയോജനം ശരിയായ കോൺ ഒഴികെ എല്ലാ കോണുകളിൽ നിന്നും റൂട്ടിംഗ് ബഗ് പോലെ തോന്നുന്നു. Linux ഒരു റൂട്ട് പരിഹരിച്ചതിന് ശേഷം വേറിട്ട സുരക്ഷാ നയ ഡാറ്റാബേസ് സമീപിക്കുന്നു, അതിനാൽ കൂടുതൽ നിർദ്ദിഷ്ട ലക്ഷ്യ റൂട്ട് പൊരുത്തപ്പെടുന്ന XFRM നയത്തെ മാറ്റിസ്ഥാപിക്കുന്നില്ല. കാണുന്ന ലക്ഷണം ഹോസ്റ്റ് വിട്ട് ഒരിക്കലും എത്താത്ത ട്രാഫിക്കാണ്, എന്നാൽ രണ്ട് ടണലുകളും തങ്ങൾ ആരോഗ്യത്തോടെയിരിക്കുന്നു എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു. മൂന്ന് ഓപ്ഷനുകൾ ഇത് പരിഹരിക്കുന്നു, ഏത് തിരഞ്ഞെടുക്കണം എന്നത് ആ രണ്ട് പാതകളിൽ ഏതാണ് ആ പ്രിഫിക്സ് വഹിക്കേണ്ടത് എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.
രണ്ട് തീരുമാനങ്ങൾ, ഒന്നല്ല
റൂട്ട് തിരഞ്ഞെടുപ്പ് ഒരു ഇടുങ്ങിയ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: ഏത് അടുത്ത ഹോപ്പും ഉറവിട വിലാസവുമാണ് ഈ പാക്കറ്റ് വഹിക്കേണ്ടത്. സുരക്ഷാ നയ ഡാറ്റാബേസ് മറ്റൊന്നിന് ഉത്തരം നൽകുന്നു: ഈ പാക്കറ്റിന് IPsec സംരക്ഷണം ആവശ്യമാണോ, ഏത് സെലക്ടറുകൾക്ക് കീഴിൽ. രണ്ടും ഒരേ പാക്കറ്റിനായി പ്രവർത്തിക്കുന്നു, കൂടാതെ ആദ്യത്തേത് പാലിക്കുന്നത് രണ്ടാമത്തേതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. അതുകൊണ്ടാണ് മെട്രിക് മാറ്റുന്നതോ സ്ഥിര റൂട്ട് ചേർക്കുന്നതോ ലക്ഷണത്തെ തൊടാതെ വിട്ടേക്കാം.
വിശാലമായ IPsec സെലക്ടറാണ് സാധാരണ കാരണം. 172.16.0.0/12 സംരക്ഷിക്കുന്ന നയം 172.20.8.0/24-ഉം ഉൾക്കൊള്ളുന്നു, അവിടേക്ക് അഡ്മിനിസ്ട്രേറ്റർ OpenVPN ടണലിലൂടെ എത്താൻ ഉദ്ദേശിച്ചേക്കാം. ഉദ്ദേശ്യം റൂട്ടിംഗ് പട്ടികയിൽ മാത്രമാണ്, നയ ഡാറ്റാബേസ് അതിനെക്കുറിച്ച് ഒരിക്കലും അറിഞ്ഞില്ല.
ഇതിനെ രണ്ട് മെട്രിക്കുകളുടെ മത്സരമായല്ല, കോൺഫിഗർ ചെയ്ത രണ്ട് സംരക്ഷണ പാതകൾ തമ്മിലുള്ള സംഘർഷമായി കാണുക. തിരുത്തൽ തെറ്റായ പരിധിയോടെ കോൺഫിഗർ ചെയ്ത ഘടകത്തിനാണ്.
കെർണൽ യഥാർത്ഥത്തിൽ തിരഞ്ഞെടുക്കുന്ന റൂട്ട് വായിക്കുക
കെർണൽ നടത്തുന്ന തിരയലിൽ നിന്ന് തുടങ്ങുക, ഉറവിട വിലാസവും അതിനെ മറ്റൊരു പട്ടികയിലേക്ക് തിരിച്ചുവിടാവുന്ന ഏത് നയ നിയമവും ഉൾപ്പെടെ. മുൻ നിയമം മറ്റൊരു പട്ടിക തിരഞ്ഞെടുത്താൽ പ്രധാന പട്ടികയിലെ റൂട്ട് ഒരിക്കലും പരിഗണിക്കപ്പെടാം, കൂടാതെ ഏറ്റവും നീളമുള്ള പ്രിഫിക്സ് പൊരുത്തം നിയമം തിരഞ്ഞെടുക്കുന്ന പട്ടികയ്ക്കുള്ളിൽ മാത്രമേ ബാധകമാകൂ.
ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15
അവസാന കമാൻഡാണ് പ്രധാനം, കാരണം അത് തിരഞ്ഞെടുത്ത റൂട്ടും കെർണൽ ഉപയോഗിക്കുന്ന ഉറവിട വിലാസവും ഒരുമിച്ച് അച്ചടിക്കുന്നു. ആ ഔട്ട്പുട്ടിനെ IPsec നയം പൊരുത്തപ്പെടുന്ന സെലക്ടറുമായി താരതമ്യം ചെയ്യുക. റൂട്ട് OpenVPN ഇന്റർഫേസിലേക്ക് ചൂണ്ടുകയും നയം ഇപ്പോഴും അതേ ജോടിയുമായി പൊരുത്തപ്പെടുകയും ചെയ്യുമ്പോൾ, ഊഹിക്കാതെ തന്നെ സംഘർഷം പുനർനിർമ്മിച്ചിരിക്കുന്നു.
ടിക്കറ്റിലെത്തുന്നതിന് മുമ്പ് ഡമ്പുകളെ ബന്ധമില്ലാത്ത വിലാസങ്ങളിൽ നിന്ന് മുക്തമാക്കി വയ്ക്കുക. ഉത്പാദന ഹോസ്റ്റിന്റെ റൂട്ടിംഗ് പട്ടിക ആന്തരിക ടോപ്പോളജി വഹിക്കുന്നു, ചോദ്യത്തിന് ഉത്തരം നൽകുന്ന വരികൾ മാത്രമാണ് ഒട്ടിക്കാൻ യോഗ്യം.
ബാധകമാകുന്ന നയവും വായിക്കുക
നയ പട്ടിക ദിശ, സെലക്ടറുകൾ, പൊരുത്തപ്പെടുന്ന പാക്കറ്റിന് എന്ത് സംഭവിക്കുമെന്ന് തീരുമാനിക്കുന്ന ടെംപ്ലേറ്റ് എന്നിവ കാണിക്കുന്നു. ആദ്യം പുറത്തേക്കുള്ള ദിശ വായിക്കുക, തുടർന്ന് മടങ്ങിവരുന്ന ട്രാഫിക്കിനായി അകത്തേക്കുള്ള വശം, കാരണം ഏകദിശാ ഒഴിവാക്കൽ ആരംഭിച്ച് ഒരിക്കലും പൂർത്തിയാകാത്ത കണക്ഷൻ സൃഷ്ടിക്കുന്നു.
ip -s xfrm policy
swanctl --list-sas
പട്ടികയിലെ സെലക്ടറുകളെ കണക്ഷൻ ചർച്ച ചെയ്ത പ്രിഫിക്സുകളുമായി താരതമ്യം ചെയ്യുക. strongSwan-ന്റെ റൂട്ട് ഇൻസ്റ്റാളേഷൻ ഓഫാക്കുന്നത് ആ നയങ്ങളെ നീക്കുന്നില്ല, മെട്രിക് മാറ്റുന്നത് ഏത് ഉറവിട-ലക്ഷ്യ ജോടിയെ നയം സംരക്ഷിക്കുന്നു എന്നതിനെ മാറ്റുന്നില്ല. ഈ രണ്ട് വ്യാജ പരിഹാരങ്ങളെ നേരത്തേ ഒഴിവാക്കാൻ യോഗ്യമാണ്, കാരണം ആളുകൾ ആദ്യം അവയാണ് പരീക്ഷിക്കുന്നത്.
നിങ്ങൾ പ്രതീക്ഷിച്ച പ്രിഫിക്സിന് പട്ടികയിൽ നയമില്ലെങ്കിൽ, പ്രശ്നം മറ്റെവിടെയാണ്, റൂട്ടിംഗ് പട്ടിക സത്യം പറയുന്നതാകാം. പ്രിഫിക്സ് ഉൾക്കൊള്ളുന്ന വിശാലമായ നയം അതിലുണ്ടെങ്കിൽ, നിങ്ങൾ പിടിച്ചെടുക്കൽ കണ്ടെത്തി.
രണ്ട് പാതകളും ന്യായമാകുമ്പോൾ മൂന്ന് ഓപ്ഷനുകൾ
വിശാലമായ പ്രിഫിക്സ് ആവശ്യകതയല്ലാതെ സൗകര്യമായിരുന്നപ്പോൾ IPsec സെലക്ടർ ചുരുക്കുന്നതാണ് ഏറ്റവും വൃത്തിയുള്ള ഓപ്ഷൻ. യഥാർത്ഥത്തിൽ IPsec-ന് പിന്നിലുള്ള സബ്നെറ്റുകളിലേക്ക് ദൂര ട്രാഫിക് സെലക്ടർ കുറയ്ക്കുന്നത് എല്ലാ ഹോസ്റ്റുകൾക്കുമുള്ള സംഘർഷം ഒരുമിച്ച് നീക്കുന്നു, അതിന്റെ ചെലവ് പുതിയ ഘടകമല്ല, കീ വീണ്ടും ചർച്ച ചെയ്യലാണ്.
വിശാല സെലക്ടർ നിലനിൽക്കേണ്ടിവരുമ്പോൾ പാസ്ത്രൂ ഒഴിവാക്കലാണ് ശസ്ത്രക്രിയാ ഓപ്ഷൻ. child pass മോഡ് ഉപയോഗിക്കുന്ന വേറിട്ട കണക്ഷനെ strongSwan പിന്തുണയ്ക്കുന്നു, അത് പൊരുത്തപ്പെടുന്ന ട്രാഫിക് IPsec പ്രോസസ്സ് ചെയ്യരുതെന്ന് കെർണലിനോട് പറയുന്നു. ലൂപ്പ്ബാക്ക് ദൂര വിലാസം ആ കണക്ഷൻ വരുന്ന പിയർമാർക്കായി തിരഞ്ഞെടുക്കപ്പെടുന്നത് തടയുന്നു, കൂടാതെ സെലക്ടറുകൾ എല്ലാത്തിനെയുമല്ല, യഥാർത്ഥ അധികാരപ്പെടുത്തിയ ജോടിയെ വിവരിക്കണം.
connections {
openvpn-exception {
remote_addrs = 127.0.0.1
children {
openvpn-exception {
local_ts = 10.44.7.0/24
remote_ts = 172.20.8.0/24
mode = pass
start_action = trap
}
}
}
}
strongSwan കോൺഫിഗറേഷൻ ഉദാഹരണങ്ങൾ ഈ നയ തരവും ലൂപ്പ്ബാക്ക് പിയർ പാരമ്പര്യവും രേഖപ്പെടുത്തുന്നു. മൂന്നാമത്തെ ഓപ്ഷൻ XFRM ഇന്റർഫേസുകളുള്ള റൂട്ട് അധിഷ്ഠിത ഡിസൈൻ ആണ്, അത് നയത്തെ ആഗോള സെലക്ടറിന് പകരം പേരിട്ട ഇന്റർഫേസിലൂടെ റൂട്ട് ചെയ്യുന്ന ട്രാഫിക്കിലേക്ക് ബന്ധിപ്പിക്കുന്നു. ഇത് ട്യൂൺ അല്ല, മാറ്റം ആണ്, ട്രാഫിക് ഇപ്പോഴും ചർച്ച ചെയ്ത സെലക്ടറുകളെ പാലിക്കണം.
| Option | Use it when | Cost |
|---|---|---|
| Narrow the selector | The broad prefix was convenience | A rekey and a policy review |
| Passthrough child | The broad selector must stay | One exception per intended pair |
| XFRM interface | Policy should follow routing | A design migration |
ബാക്കിയുള്ളത് ദുർബലമാക്കാതെ ഒഴിവാക്കൽ തെളിയിക്കുക
മാറ്റം ലോഡ് ചെയ്ത ശേഷം ഒഴിവാക്കലും സംരക്ഷിതമായി തുടരേണ്ട സാധാരണ ലക്ഷ്യവും പരിശോധിക്കുക. രണ്ട് ദിശകളും പരിശോധിക്കുക, തുടർന്ന് OpenVPN ടണൽ വീഴ്ത്തി ഒഴിവാക്കിയ ട്രാഫിക്കിന് എന്ത് സംഭവിക്കുന്നു എന്ന് സ്ഥിരീകരിക്കുക. ടണൽ താഴെയായിരിക്കുമ്പോൾ ആ പ്രിഫിക്സ് നിശ്ശബ്ദമായി തുറന്ന് അയയ്ക്കുന്ന ഒഴിവാക്കൽ സംഭവവേളയിൽ കണ്ടെത്തേണ്ടതല്ല, ബോധപൂർവം എടുക്കേണ്ട നയ തീരുമാനമാണ്.
ഏത് പ്രിഫിക്സ് ഏത് പാത ഉപയോഗിക്കുന്നു, എന്തുകൊണ്ട് എന്ന് രേഖപ്പെടുത്തുക. അല്ലാത്തപക്ഷം വിശാല സെലക്ടർ കാണുന്ന അടുത്ത എഞ്ചിനീയർ അതേ അന്വേഷണം വീണ്ടും തുറക്കും, ഉത്തരം ആരും വായിക്കാത്ത commit സന്ദേശത്തിൽ കിടക്കും.