tun0 ഇല്ലേ? nftables-ൽ ഡീക്രിപ്റ്റ് ചെയ്ത IPsec, meta ipsec ഉപയോഗിച്ച് പൊരുത്തപ്പെടുത്തുക

നിങ്ങൾ ഒരു ടണൽ ഇന്റർഫേസ് പ്രതീക്ഷിക്കുന്നു, അത് തിരയുന്നു, ഫയർവാളിൽ പൊരുത്തപ്പെടുത്താൻ ഒന്നുമില്ല. നയാധിഷ്ഠിത ഗേറ്റ്വേ ഉണ്ടാകുമ്പോൾ ഇത് സാധാരണമാണ്: എൻക്രിപ്റ്റ് ചെയ്ത കൈമാറ്റം ഭൗതിക ഇന്റർഫേസിൽ എത്തുന്നു, പിന്നീട് കൈമാറുന്ന ഡീക്രിപ്റ്റ് ചെയ്ത ആന്തരിക പാക്കറ്റും അതേ ഇന്റർഫേസിൽ എത്തുന്നതായി കാണപ്പെടുന്നു. tun0 ഇല്ല, കാരണം ഒന്നും അത് സൃഷ്ടിച്ചിട്ടില്ല.

ആന്തരിക അഭ്യർത്ഥന ഇപ്പോഴും സ്വന്തം ഉറവിടം, ലക്ഷ്യം, സേവനം എന്നിവയുള്ള വേറിട്ട പാക്കറ്റാണ്, ഏത് സുരക്ഷാ അസോസിയേഷനിൽ നിന്നാണ് അത് പുറത്തുവന്നതെന്ന് കേർണലിന് അറിയാം. ഈ അറിവാണ് ഒരു ഫയർവാൾ നിയമത്തിന് പൊരുത്തപ്പെടുത്താൻ കഴിയുന്നത്.

രണ്ട് പാക്കറ്റ്, ഒരു ഇന്റർഫേസ്

ഇൻബൗണ്ട് ദിശ സങ്കൽപ്പിക്കുക. ESP അല്ലെങ്കിൽ UDP-യിൽ പൊതിഞ്ഞ പാക്കറ്റ് എത്തുന്നു, കേർണൽ യോജിക്കുന്ന നയം കണ്ടെത്തി ഡീക്രിപ്റ്റ് ചെയ്ത് വ്യക്തമായ പാക്കറ്റ് കൈമാറ്റ പാതയ്ക്ക് നൽകുന്നു. ഇന്റർഫേസിന്റെ പേര് മാത്രം നോക്കുന്ന നിയമത്തിന് ആ പാക്കറ്റിനെ അതേ വയറിലൂടെ വരുന്ന മറ്റേതെങ്കിലും ട്രാഫിക്കിൽ നിന്ന് വേർതിരിക്കാൻ കഴിയില്ല.

അതിനെ വേർതിരിക്കുന്നത് പാക്കറ്റിനോട് ചേർന്ന ഇൻബൗണ്ട് സുരക്ഷാ പാതയുടെ സന്ദർഭമാണ്. nftables അത് meta ipsec exists എന്ന് കാണിക്കുന്നു, പാക്കറ്റ് IPsec സുരക്ഷാ പാതയിലൂടെ വന്നപ്പോൾ ഇത് ശരിയാണ്. അത് ക്ലയന്റ് പൂൾ, ലക്ഷ്യം, സേവനം എന്നിവയുമായി ചേർത്താൽ നിയമം സുരക്ഷിതമാകാൻ മതിയായ കൃത്യതയുള്ളതാകും.

സന്ദർഭം ഒഴിവാക്കുന്നതാണ് സാധാരണ തെറ്റ്, അത് അലങ്കാരമല്ല, സുരക്ഷാ തെറ്റാണ്. ക്ലയന്റ് പൂളിൽ നിന്ന് വരുന്ന എല്ലാം സ്വീകരിക്കുന്ന നിയമം പ്രാദേശിക നെറ്റ്വർക്കിൽ നിന്നുള്ള വ്യാജ പാക്കറ്റും അതേ സന്തോഷത്തോടെ സ്വീകരിക്കും, കാരണം ഉറവിട വിലാസം സ്വയം ഒന്നിന്റെയും തെളിവല്ല. ഉറവിടത്തെ അർത്ഥവത്താക്കാനുള്ള ഏറ്റവും വിലകുറഞ്ഞ വഴി സുരക്ഷാ പാതയുടെ സന്ദർഭമാണ്. ഓഡിറ്റിന് ശേഷം ചേർക്കുന്നതിനുപകരം തുടക്കം മുതൽ അതോടൊപ്പം നിയമം എഴുതുക.

കൈമാറ്റ നിയമം എഴുതുക

10.90.0.0/24 ൽ ക്ലയന്റുകളുള്ള പ്രാമാണീകരിച്ച IPv4 റിമോട്ട് ആക്സസ് സേവനവും 203.0.113.40 ൽ ഒരു അനുവദിച്ച ലക്ഷ്യവുമുണ്ടെന്ന് കരുതുക. ആ ഫ്ലോയ്ക്കുള്ള നിയമത്തിന്റെ ഭാഗം ഇങ്ങനെയാണ്.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

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

oifname എന്ന പദം നിലനിർത്താൻ യോഗ്യമാണ്. അത് പുറത്തേക്കുള്ള തീരുമാനം രേഖപ്പെടുത്തുന്നു, നിങ്ങൾ ഉദ്ദേശിക്കാത്ത ദിശയിൽ നിയമം പൊരുത്തപ്പെടുന്നത് തടയുന്നു, ഇത് ഇന്റർനെറ്റിലേക്ക് പല പാതകളുള്ള ഗേറ്റ്വേയിൽ പ്രധാനമാണ്. ഒരേയൊരു അപ്ലിങ്കുള്ള പരീക്ഷണ ബോക്സിൽ പദം അധികമായി തോന്നുന്നു, അതുകൊണ്ടുതന്നെ ബോക്സിന് രണ്ടാം അപ്ലിങ്ക് ലഭിക്കുന്നതിന് മുമ്പ് അത് നീക്കം ചെയ്യുന്നു.

പുറം കൈമാറ്റത്തിനുള്ള അനുമതികൾ വേറിട്ടതാണ്. ഗേറ്റ്വേയുടെ ഇൻപുട്ട് പാതയ്ക്ക് അത് യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന IKE, ESP അല്ലെങ്കിൽ UDP പൊതിയുന്ന പോർട്ടുകൾ വേണം, ആ അനുമതികൾ അകത്തെ ഡീക്രിപ്റ്റ് ചെയ്ത പാക്കറ്റിനെക്കുറിച്ച് ഒന്നും അനുവദിക്കുന്നില്ല. രണ്ടും കൂട്ടിക്കലർത്തുന്നതാണ് പ്രവർത്തിക്കുന്ന ടണൽ എല്ലാം കൈമാറുന്ന ഫയർവാളിലേക്ക് എത്തുന്ന വഴി.

ഇൻബൗണ്ട് സന്ദർഭം ഔട്ട്ബൗണ്ട് സന്ദർഭമല്ല

അതേ പ്രയോഗ കുടുംബം മറുവശത്തെ ദിശയെ rt ipsec കൊണ്ട് ഉൾക്കൊള്ളുന്നു, അത് ഒരു പാക്കറ്റ് ഉപയോഗിക്കാൻ പോകുന്ന ഔട്ട്ബൗണ്ട് സുരക്ഷാ അസോസിയേഷനെ വിവരിക്കുന്നു. അത് മറ്റൊരു ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: ഈ പാക്കറ്റ് എവിടെനിന്ന് വന്നു എന്നല്ല, അടുത്ത ഘട്ടത്തിൽ അത് സംരക്ഷിക്കപ്പെടുമോ എന്നാണ്.

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

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

NAT ഫയർവാൾ തീരുമാനമല്ല

സ്വകാര്യ ക്ലയന്റ് പൂളിൽ നിന്ന് ഇന്റർനെറ്റിലേക്കുള്ള ട്രാഫിക്കിന് സാധാരണയായി ഉറവിട വിവർത്തനം ആവശ്യമാണ്, അല്ലെങ്കിൽ മറുപടിക്ക് തിരികെയുള്ള വഴി കണ്ടെത്താനാകില്ല. എന്നാൽ മറ്റൊരു ഔട്ട്ബൗണ്ട് IPsec നയത്തിനായി തിരഞ്ഞെടുത്ത ട്രാഫിക് അതിന്റെ ആവശ്യമായ ഒഴിവാക്കൽ നിലനിർത്തണം, അടുത്ത സംരക്ഷണ തീരുമാനത്തെക്കുറിച്ച് ചിന്തിക്കാതെ എല്ലാ സ്വകാര്യ ഉറവിടങ്ങളും മറച്ചുവയ്ക്കുന്നത് അത് തകർക്കുന്നു.

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

നേരെ മറിച്ചും ശരിയാണ്, അത് ആളുകളെ അത്ഭുതപ്പെടുത്തുന്നു: ഒരു ഫിൽട്ടർ അടിസ്ഥാന ചെയിനിൽ എവിടെയോ ഉള്ള അനുവാദത്തിന് മറ്റൊരു ബാധകമായ ചെയിനിലെ തുടർന്നുള്ള നിരസിക്കലിനെതിരെ യാതൊരു ഭാരവുമില്ല. ഫലം നിർണ്ണയിക്കുന്നത് ക്രമവും ചെയിനിന്റെ വ്യാപ്തിയുമാണ്, ഫയലിൽ അനുവാദം ഉണ്ടോ എന്നല്ല.

കൃത്യമായ ആന്തരിക സേവനം പരിശോധിക്കുക

നിങ്ങൾ അനുവദിച്ച നിർദ്ദിഷ്ട ലക്ഷ്യവും പോർട്ടും യഥാർത്ഥ ക്ലയന്റിൽ നിന്ന് പരീക്ഷിച്ച് മറുപടി തിരികെ വരുന്നുവെന്ന് ഉറപ്പാക്കുക. തുടർന്ന് നിങ്ങൾ അനുവദിക്കാത്ത എന്തെങ്കിലും പരീക്ഷിച്ച് അത് കടന്നുപോകുന്നില്ലെന്ന് പരിശോധിക്കുക, കാരണം വളരെ വിശാലമായ നിയമവും ശരിയായ നിയമം പോലെതന്നെ ആദ്യ പരീക്ഷണം വിജയിക്കുന്നു. ക്ലയന്റ് ഒരിക്കലും വിട്ടുപോകാത്ത അഭ്യർത്ഥനയും ഫയർവാൾ ഫലമല്ല, അതിനാൽ പാക്കറ്റ് വിലയിരുത്തപ്പെട്ടോ എന്ന് അറിയാൻ കൗണ്ടറുകൾ വായിക്കുക. രണ്ട് പരീക്ഷണവും ഒരു കൗണ്ടർ വായനയും നിയമക്കൂട്ടം വായിച്ച് ചെലവഴിച്ച ഒരു ഉച്ചയ്ക്കുശേഷത്തേക്കാൾ കൂടുതൽ പറയും.

nftables റഫറൻസ് meta ipsec, rt ipsec, ദിശാനിർദ്ദിഷ്ട പ്രയോഗങ്ങൾ എന്നിവ രേഖപ്പെടുത്തുന്നു, ഇൻസ്റ്റാൾ ചെയ്ത പതിപ്പുമായി വാക്യഘടന പരിശോധിക്കേണ്ട സ്ഥലം അവിടെയാണ്. വ്യാപ്തി വ്യക്തമായി സൂക്ഷിക്കുക: ഇത് ഒരു IPv4 ഉദാഹരണമാണ്, IPv6-നെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, ഏകപക്ഷീയമായ പൊതു പോർട്ട് കൈമാറ്റത്തെ VPN സേവനത്തിന്റെ ഭാഗമാക്കുന്നുമില്ല.