ഒരു നിയമത്തിന് അനുവദിച്ച VPN പൂളിനെ ഒരു ലക്ഷ്യ ശ്രേണിയിൽ നിന്ന് അകറ്റി നിർത്താം, ഗേറ്റ്‌വേ ചെയ്യുന്ന മറ്റൊന്നിനെയും ബാധിക്കാതെ. നിയമം തന്നെ ചെറുതാണ്; അത് പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുന്ന ഭാഗങ്ങൾ അത് വസിക്കുന്ന ഹുക്കും ചെയിനിലെ അതിന്റെ സ്ഥാനവുമാണ്. ഈ രണ്ടും തെറ്റിച്ചാൽ ശരിയാണെന്ന് തോന്നുന്ന, പക്ഷേ സ്ഥിരതയില്ലാതെ പെരുമാറുന്ന ഒരു ഫയർവാൾ ലഭിക്കും. നിയമം പാക്കറ്റിനെ കാണുമ്പോൾ പാക്കറ്റ് എന്തു ചെയ്യുന്നു എന്നതിൽ നിന്ന് തുടങ്ങുക.

നിയമം യഥാർത്ഥത്തിൽ എന്താണ് പൊരുത്തപ്പെടുത്തുന്നത്

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

ഇന്റർഫേസ് പൊരുത്തമാണ് ഫോർവേഡ് ചെയ്യുന്ന ക്ലയന്റ് ട്രാഫിക്കിനെ ഗേറ്റ്‌വേയുടെ സ്വന്തം കണക്ഷനുകളിൽ നിന്ന് വേർതിരിക്കുന്നത്. അതില്ലെങ്കിൽ, സ്രോതസ്സ് പൂൾ മാത്രം പേരിടുന്ന ഒരു നിയമം, ഗേറ്റ്‌വേ തന്നെ ആ വിലാസത്തിൽ നിന്ന് സൃഷ്ടിക്കുന്ന പാക്കറ്റുകളെയും ബാധിക്കും, അങ്ങനെ ഒരിക്കലെങ്കിലും സംഭവിച്ചാൽ. സ്രോതസ്സ് പ്രിഫിക്സ് നയത്തെ അനുവദിച്ച ക്ലയന്റുകളിലേക്ക് പരിമിതപ്പെടുത്തുന്നു, ലക്ഷ്യ പ്രിഫിക്സ് അതിനെ ഒരു ശ്രേണിയിലേക്കും. നിയമം ഒരു പട്ടികയല്ല, ഒരു ഖണ്ഡനമായി വായിക്കുക.

എന്തെങ്കിലും തിരുത്തുന്നതിന് മുമ്പ് മൂന്ന് മൂല്യങ്ങൾ എഴുതിവയ്ക്കുക: ടണൽ ഇന്റർഫേസിന്റെ പേര്, സർവർ വിതരണം ചെയ്യുന്ന പൂൾ, നിഷേധിക്കാൻ ഉദ്ദേശിക്കുന്ന പ്രിഫിക്സ്. അവയിൽ ഏതെങ്കിലും തെറ്റിയാൽ വൃത്തിയായി പാഴ്‌സ് ചെയ്യപ്പെടുന്ന, പക്ഷേ ഒന്നും സംരക്ഷിക്കാത്ത ഒരു നിയമം ഉണ്ടാകും. ആ മൂന്ന് മൂല്യങ്ങൾ നിയമത്തിന് അരികിലുള്ള മാറ്റരേഖയിൽ സൂക്ഷിക്കുക.

ഹുക്കാണ് നിയമം ആർക്ക് ബാധകമെന്ന് തീരുമാനിക്കുന്നത്

netfilter ചെയിൻ ഒരു ഹുക്കിലേക്ക് ഘടിപ്പിക്കുന്നു, കൂടാതെ ഏത് പാക്കറ്റുകൾ ചെയിൻ കാണുന്നു എന്നത് ഹുക്കാണ് തീരുമാനിക്കുന്നത്. forward ഹുക്ക് ഗേറ്റ്‌വേയിലൂടെ റൂട്ട് ചെയ്യുന്ന ട്രാഫിക്ക് കാണുന്നു, അതാണ് ക്ലയന്റിൽ നിന്ന് ലക്ഷ്യത്തിലേക്കുള്ള ട്രാഫിക്. ചെയിനിലെ മറ്റെല്ലാം മറ്റൊരു സദസ്സിനെ ലക്ഷ്യമിടുന്നു.

input ഹുക്ക് ഗേറ്റ്‌വേയിലേക്ക് തന്നെ അഭിസംബോധന ചെയ്ത ട്രാഫിക്ക് കാണുന്നു, അതിനാൽ അവിടെ വയ്ക്കുന്ന നിയമം ട്രാൻസിറ്റിനെയല്ല, അതിന്റെ സ്വന്തം സേവനങ്ങളിലേക്കുള്ള പ്രവേശനത്തെ നിയന്ത്രിക്കുന്നു. output ഹുക്ക് ഗേറ്റ്‌വേ സ്വയം ഉണ്ടാക്കുന്ന ട്രാഫിക്ക് കാണുന്നു, ഇത് ക്ലയന്റ് പൂൾ നയത്തിന് ആവശ്യമായതിന് വിപരീതമാണ്. ചെയിനുകളുടെ പേരുകൾ റൂൾസെറ്റ് എഴുതിയയാൾ തിരഞ്ഞെടുത്ത ഏകപക്ഷീയ ലേബലുകളാണ്, അതിനാൽ പേരിൽ നിന്ന് ഹുക്ക് ഊഹിക്കരുത്. ചെയിൻ എവിടെ ഘടിപ്പിച്ചിരിക്കുന്നു എന്ന് പരിശോധിച്ച ശേഷം അത് എന്ത് പൊരുത്തപ്പെടുത്താം എന്ന് അനുമാനിക്കുക.

HookTraffic it seesRight for this policy
inputAddressed to the gatewayNo, that is the host's own services
forwardRouted through the gatewayYes, for client-to-destination traffic
outputGenerated by the gatewayNo, that is the opposite direction

ഘടിപ്പിക്കൽ വായിക്കുന്നത് ഒരു വരിയുള്ള പരിശോധനയാണ്, പാക്കറ്റ് ഒരിക്കലും കാണാത്ത ചെയിനിൽ നിയമം വീഴുന്നത് അത് തടയുന്നു.

വിശാലമായ accept-ന് മുമ്പ് നിയമം വയ്ക്കുക

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

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

sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.conf

മൂന്നാമത്തെ കമാൻഡ് ഫയൽ പ്രയോഗിക്കാതെ പാഴ്‌സ് ചെയ്യുന്നു, അത് സിന്റാക്സ് പിശകുകൾ തടസ്സമാകുന്നതിന് മുമ്പ് പിടിക്കുന്നു. റോൾബാക്ക് പ്ലാനോടെ പ്രയോഗിക്കുക, കാരണം forward ചെയിനിലെ തെറ്റായ ഒരു നിയമം നിങ്ങൾ ജോലി ചെയ്യുന്ന ടണൽ മുറിച്ചേക്കാം.

നിലവിലുള്ള ഫ്ലോകൾ നിങ്ങളുടെ പുതിയ നിയമത്തെ കാര്യമാക്കുന്നില്ല

നിയമം നിലവിൽ വരുന്നതിന് മുമ്പ് സൃഷ്ടിച്ച conntrack എൻട്രി മുൻ accept-മായി പൊരുത്തപ്പെടുന്നത് തുടരുന്നു. അതുകൊണ്ടാണ് പുതിയ ഡ്രോപ്പ് ചിലപ്പോൾ പുതിയ കണക്ഷനുകൾക്ക് പ്രവർത്തിക്കുന്നതായി തോന്നുകയും പരീക്ഷിക്കുന്ന കണക്ഷന് ഒന്നും ചെയ്യാതിരിക്കുകയും ചെയ്യുന്നത്.

ചെയിനിന്റെ മുകളിലുള്ള സ്റ്റേറ്റ് പൊരുത്തം വായിക്കുക. നിങ്ങളുടെ നിയമത്തിന് മുമ്പ് അത് established, related ട്രാഫിക് സ്വീകരിക്കുന്നുവെങ്കിൽ, ഇതിനകം നടക്കുന്ന ഓരോ ഫ്ലോയും അടയുന്നതുവരെ ഒഴുകുന്നത് തുടരും. അടിയന്തര നിയമത്തിന് സാധാരണയായി അതാണ് വേണ്ട പെരുമാറ്റം, തൽക്ഷണ കട്ട് പ്രതീക്ഷിക്കുമ്പോൾ അത് ആശയക്കുഴപ്പമുണ്ടാക്കുന്നു. വിന്യസിക്കുന്നതിന് മുമ്പ് ഏത് ഫലമാണ് വേണ്ടതെന്ന് തീരുമാനിക്കുക. തുറന്ന കണക്ഷൻ പുനരുപയോഗിക്കുന്ന ഒരു പരീക്ഷണം നിങ്ങൾക്ക് തെറ്റായ കഥ പറയും.

sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'

ആദ്യ കമാൻഡ് ഒരു ഫ്ലോ ഉണ്ടോ എന്ന് കാണിക്കുന്നു, രണ്ടാമത്തേത് ആദ്യകാല സ്റ്റേറ്റ് നിയമം അത് സ്വീകരിക്കുന്നത് തുടരുന്നുണ്ടോ എന്ന് കാണിക്കുന്നു. രണ്ടും വായനയ്ക്ക് മാത്രമുള്ളതും സംഭവസമയത്ത് പ്രവർത്തിപ്പിക്കാൻ സുരക്ഷിതവുമാണ്.

ഈ നിയമം എന്തല്ല

ഡൊമെയിൻ ബ്ലാക്ക്‌ലിസ്റ്റോ IPv6 നയമോ ഒരു അപ്ലിക്കേഷൻ അക്കൗണ്ടിലുള്ള നിയന്ത്രണമോ അല്ല ഈ നിയമം.

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

ഈ നിയമം നൽകുന്ന കരാർ കൃത്യമാണ്: അനുവദിച്ച പൂളിൽ നിന്ന് ഒരു ലക്ഷ്യ പ്രിഫിക്സിലേക്കുള്ള ട്രാഫിക് നിഷേധിക്കപ്പെടുന്നു, ബന്ധമില്ലാത്ത ഗേറ്റ്‌വേ ട്രാഫിക് അതിന്റെ നിലവിലുള്ള നയം നിലനിർത്തുന്നു. ആ വാക്യം നിയമത്തിന് അരികിൽ എഴുതുക, അടുത്തയാൾ അത് എന്തിനായിരുന്നു എന്ന് അറിയും.

അനുബന്ധ ലേഖനങ്ങൾ