Ubuntu-வில் iptables மற்றும் nftables வேறுபாடு என்ன?

Ubuntu-வில் iptables vs nftables: உங்கள் server எதைப் பயன்படுத்துகிறது?

Ubuntu 20.04 மற்றும் அதற்குப் பிந்தைய பதிப்புகளில், iptables கட்டளை என்பது nftables விதிகளை எழுதும் ஒரு front end ஆகும். Kernel-ல் nftables என்ற ஒரே ஒரு packet filter மட்டுமே இயங்குகிறது, அதை இரண்டு user space கட்டளைகள் நிர்வகிக்கின்றன. ஒரு iptables -A INPUT வரி இப்போதும் பழையபடியே செயல்படும், அது உருவாக்கும் விதி ஒரு nftables விதியாகவே இருக்கும், அதை nft மூலம் பார்க்க முடியும்.

இதை நம்புவதற்கு முன் உங்கள் server-ல் உறுதிப்படுத்திக் கொள்ளுங்கள்.

iptables -V
sudo update-alternatives --display iptables
sudo nft list ruleset

Ubuntu 24.04-ல் (ஆகஸ்ட் 2026 நிலவரப்படி, iptables 1.8.10), iptables -V கட்டளை iptables v1.8.10 (nf_tables) என்பதை வெளியீடாகக் காட்டும். அடைப்புக்குறிக்குள் இருக்கும் பெயர் back end-ஐக் குறிக்கிறது. (nf_tables) என்பது அந்த கட்டளை nftables-உடன் தொடர்பு கொள்கிறது என்பதைக் குறிக்கிறது. (legacy) என்பது பழைய x_tables back end-ஐக் குறிக்கிறது; இதை Ubuntu இப்போதும் iptables-legacy ஆக வழங்குகிறது மற்றும் kernel இதை முற்றிலும் தனித்தனி ruleset-ஆக வைத்திருக்கிறது. update-alternatives கட்டளை அந்தத் தேர்வுக்குப் பின்னால் உள்ள symlink-ஐக் காட்டும்: link currently points to /usr/sbin/iptables-nft.

எந்த firewall-உம் அமைக்கப்படாத புதிய VPS-ல், sudo nft list ruleset கட்டளை எதையும் காட்டாது. அந்த வெற்று வெளியீடே உங்கள் அடிப்படை நிலை (baseline). பழைய முறையில் ஒரு விதியைச் சேர்த்துவிட்டு மீண்டும் சரிபார்க்கவும்.

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo nft list ruleset

# Warning: table ip filter is managed by iptables-nft, do not touch!
table ip filter {
  chain INPUT {
    type filter hook input priority filter; policy accept;
    tcp dport 22 counter packets 0 bytes 0 accept
  }
  chain FORWARD {
    type filter hook forward priority filter; policy accept;
  }
  chain OUTPUT {
    type filter hook output priority filter; policy accept;
  }
}

உங்கள் iptables விதி இப்போது ஒரு nftables விதியாகும். iptables-nft அது உருவாக்கும் அட்டவணைகளைக் குறிக்கும், மேலும் nft அந்த அடையாளத்தைப் பார்க்கும்போது எச்சரிக்கையை வெளியிடும். ஏனெனில், அத்தகைய அட்டவணையை nft மூலம் திருத்துவது ஒரே விதிகளுக்கு இரண்டு கருவிகளைப் பொறுப்பாக்கிவிடும். ஒரு கட்டளை எதை உருவாக்கியது என்று பாருங்கள்: நீங்கள் பெயரிடாத ஒரு அட்டவணை மற்றும் நீங்கள் கேட்காத chains. அதுவே பழைய முறை, நீங்கள் நேரடியாக nftables-ஐ எழுதும்போது முதலில் மாறக்கூடிய விஷயம் அதுதான்.

iptables -L உங்களிடமிருந்து எதை மறைக்கிறது

iptables -L ஆனது filter அட்டவணையை மட்டுமே காட்டுகிறது. NAT (network address translation) விதிகளுக்கு iptables -t nat -L தேவைப்படுகிறது, மேலும் mangle விதிகளுக்கு -t mangle தேவைப்படுகிறது. IPv6 ஒரு தனி கட்டளையான ip6tables-ல் இயங்குகிறது, இது ஒவ்வொரு விதியின் தனி நகலைக் கொண்டுள்ளது. எனவே, நீங்கள் சரிபார்க்காத ஒரு அட்டவணையிலிருந்து உங்கள் பாக்கெட்டுகளை (packets) ஏதேனும் ஒன்று நீக்கலாம் அல்லது மாற்றியமைக்கலாம் என்றாலும், ஒரு பட்டியலைப் பார்க்கும்போது அந்த சர்வர் சுத்தமாக இருப்பது போலத் தோன்றலாம்.

sudo nft list ruleset ஒவ்வொரு குடும்பம், ஒவ்வொரு அட்டவணை, ஒவ்வொரு சங்கிலி (chain) மற்றும் ஒவ்வொரு விதியையும் ஒரே வெளியீட்டில் அச்சிடுகிறது. நீங்கள் உருவாக்காத ஒரு சர்வரில், உண்மையில் என்ன ஏற்றப்பட்டுள்ளது என்பதைப் பார்க்க இந்த ஒற்றைக் கட்டளையே வேகமான வழியாகும். விதிகளின் ஹேண்டில்களை (handles) அச்சிட -a-ஐச் சேர்க்கவும்; முழு சங்கிலியையும் நீக்குவதற்குப் பதிலாக ஒரு குறிப்பிட்ட விதியை மட்டும் நீக்க இது உங்களுக்குத் தேவைப்படும்.

இங்கே இருக்கும்போது இரண்டு பழக்கங்களைச் சரிசெய்வது நல்லது. iptables -L முகவரிகளையும் போர்ட்களையும் பெயர்களாக மாற்றுகிறது, எனவே பழுதடைந்த ரிசால்வர் (resolver) உள்ள சர்வரில் இது செயலிழந்தது போலத் தோன்றும்: அதற்குப் பதிலாக iptables -nvL-ஐப் பயன்படுத்தவும். மேலும், பழைய பேக்-எண்ட் (legacy back end) காலியாக இருப்பதை sudo iptables-legacy -nvL மூலம் உறுதிப்படுத்தவும், ஏனெனில் இரண்டு பேக்-எண்டுகளிலும் விதிகள் இருந்தால் கர்னல் (kernel) இரண்டையும் மதிப்பீடு செய்யும், மேலும் எந்தப் பட்டியலும் உங்களுக்கு முழுமையான விவரத்தைக் காட்டாது.

நீங்கள் உருவாக்கும் அட்டவணைகள் மற்றும் சங்கிலிகள் (Tables and chains)

nftables எதையும் கொண்டிருக்காமல் தொடங்கும். நீங்கள் உருவாக்கும் வரை எந்தவொரு filter அட்டவணையும் இருக்காது, மேலும் filter என்பது நீங்கள் தேர்ந்தெடுத்த ஒரு பெயர் மட்டுமே. ஒரு சங்கிலிக்கு (chain) நீங்கள் வகை (type), ஹூக் (hook) மற்றும் முன்னுரிமை (priority) ஆகியவற்றை வழங்கினால் மட்டுமே அது பாக்கெட்டுகளைக் கவனிக்கும், இதுவே அடிப்படைச் சங்கிலி (base chain) எனப்படும். இவை இல்லாத சங்கிலி, ஒரு வெளிப்படையான jump அல்லது goto மூலம் மட்டுமே அணுகப்படும், எனவே அதற்கு எதையும் அனுப்பாதவரை அது எந்தச் சுமையையும் ஏற்படுத்தாது.

மற்றொரு பெரிய மாற்றம் inet குடும்பம் ஆகும். ஒரு inet அட்டவணை IPv4 மற்றும் IPv6 ஆகிய இரண்டையும் ஒரே விதிகளில் கையாளுகிறது. இது, ஒரு போர்ட் iptables-ல் மூடப்பட்டும் ip6tables-ல் திறந்தும் இருக்கும் பிழைகளை நீக்குகிறது. இந்த முரண்பாடு மிகவும் பொதுவானது என்பதால், ufw பெட்டிகளில் இதற்கெனவே ஒரு தோல்வி முறை உள்ளது.

முழுமையான சர்வர் விதிகள் தொகுப்பு இதோ. இது /etc/nftables.conf-ல் சேமிக்கப்பட வேண்டும்.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  set admin_ips {
    type ipv4_addr
    flags interval
    elements = { 203.0.113.5, 198.51.100.0/24 }
  }

  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    ct state invalid drop
    iif lo accept
    ip protocol icmp accept
    meta l4proto ipv6-icmp accept
    tcp dport 22 ip saddr @admin_ips counter accept
    tcp dport { 80, 443 } counter accept
  }

  chain forward {
    type filter hook forward priority filter; policy drop;
  }

  chain output {
    type filter hook output priority filter; policy accept;
  }
}

இரண்டாவது வரியை இரண்டு முறை படிக்கவும். flush ruleset கட்டளையானது ufw மற்றும் Docker உருவாக்கிய அட்டவணைகள் உட்பட, சர்வரில் உள்ள அனைத்து அட்டவணைகளையும் நீக்கிவிடும். நேரலையில் இயங்கும் சர்வரில் இதைச் செயல்படுத்தும் முன் தொடர்ந்து படிக்கவும்.

input சங்கிலியில் உள்ள முதல் விதிதான் பெரும்பாலான வேலைகளைச் செய்கிறது. ct state established,related accept, நீங்கள் தொடங்கிய இணைப்புகளுக்கான பதில்களை உள்ளே அனுமதிக்கிறது, எனவே சங்கிலியின் மற்ற பகுதிகள் புதிய இணைப்புகளைப் பற்றி மட்டுமே முடிவெடுக்க வேண்டும். ct state invalid drop, அறியப்பட்ட இணைப்பு அல்லது சரியான தொடக்கத்துடன் பொருந்தாத பாக்கெட்டுகளை நிராகரிக்கிறது. அதற்குப் பிறகு உள்ள அனைத்தும் வெளிப்படையான துளைகளாகும், மேலும் policy drop மீதமுள்ளவற்றைக் கையாளுகிறது.

கோப்பை ஏற்றுவதற்கு முன் அதைச் சரிபார்க்கவும், அவ்வாறு செய்யும்போது இரண்டாவது SSH அமர்வைத் திறந்து வைத்திருக்கவும். policy drop கட்டளையுடன் SSH விதியில் ஒரு சிறிய எழுத்துப் பிழை இருந்தாலும், அது உங்களை உங்கள் சர்வரிலிருந்து வெளியேற்றிவிடும்.

sudo nft -c -f /etc/nftables.conf
sudo nft -f /etc/nftables.conf
sudo nft list ruleset

nft -c -f கோப்பை ஆய்வு செய்து, எதையும் ஏற்றாமல் பிழைகளை மட்டும் தெரிவிக்கும். பிழையற்ற ஆய்வு எந்த வெளியீட்டையும் காட்டாது.

நீண்ட விதிப் பட்டியல்களுக்கு மாற்றாக Sets

tcp dport { 80, 443 } என்பது ஒரு anonymous set ஆகும்: ஒவ்வொரு port-க்கும் தனித்தனி விதி எழுதுவதற்குப் பதிலாக, ஒரே விதியையும் ஒரு lookup-ஐயும் இது பயன்படுத்துகிறது. admin_ips போன்ற ஒரு named set இன்னும் கூடுதல் வசதிகளை வழங்குகிறது, ஏனெனில் firewall இயங்கிக்கொண்டிருக்கும்போதே நீங்கள் அதன் உள்ளடக்கத்தை மாற்ற முடியும்.

sudo nft add element inet filter admin_ips { 203.0.113.9 }
sudo nft list set inet filter admin_ips
sudo nft delete element inet filter admin_ips { 203.0.113.9 }

இதில் reload செய்ய வேண்டிய அவசியமில்லை, விதிகளை மறுவரிசைப்படுத்த வேண்டியதில்லை. set-ல் ஐந்து முகவரிகள் இருந்தாலும் அல்லது ஐம்பதாயிரம் முகவரிகள் இருந்தாலும், அந்தப் பொருத்தம் (match) ஒரே ஒரு lookup-ஆகவே இருக்கும். flags interval என்ற flag-ஐப் பயன்படுத்தினால் மட்டுமே, ஒரு set-ஆல் 198.51.100.0/24 போன்ற ranges மற்றும் CIDR (classless inter-domain routing) prefixes-ஐச் சேமிக்க முடியும். இந்த flag இல்லையென்றால், அந்த set ஒற்றை முகவரிகளை மட்டுமே ஏற்கும், மேலும் prefix-ஐ load செய்ய முயலும்போது அது தோல்வியடையும்.

Sets தங்களுக்குள் இருக்கும் உறுப்புகளை (elements) குறிப்பிட்ட காலத்திற்குப் பிறகு நீக்கிக்கொள்ளும் வசதியையும் கொண்டுள்ளன.

set banned {
  type ipv4_addr
  flags timeout
  timeout 1h
}

ip saddr @banned drop என்ற விதியைப் பயன்படுத்தினால், ஒரு உறுப்பு சேர்க்கப்பட்ட ஒரு மணி நேரத்திற்குப் பிறகு அது தானாகவே நீக்கப்படும். fail2ban on Ubuntu 24.04-ல் nftables இந்த முறையில்தான் ஒரு முகவரியைத் தடை (ban) செய்கிறது: இது ஒரு விதியைச் சேர்ப்பதற்குப் பதிலாக, ஒரு set-ல் ஒரு உறுப்பைச் சேர்க்கிறது. ports என்றால் என்ன என்பதில் உங்களுக்கு அடிப்படை தேவைப்பட்டால், what a port actually is on Linux என்பதிலிருந்து தொடங்கவும்.

migration செய்யும்போது ஒரு முக்கியமான வேறுபாடு பலரைத் தடுமாறச் செய்யும். நீங்கள் கேட்காதவரை nftables பாக்கெட்டுகளைக் கணக்கிடாது (count). iptables -nvL-ல் அனைத்து விதிகளுக்கும் எப்போதும் counters இருக்கும். ஆனால் nftables-ல் counter என்ற keyword உள்ள விதிகளுக்கு மட்டுமே எண்கள் இருக்கும். எனவே, பிற்காலத்தில் debug செய்ய வேண்டிய எந்தவொரு விதியிலும் counter-ஐச் சேர்த்துக்கொள்ளுங்கள்.

Hooks மற்றும் priorities எவ்வாறு வரிசையைத் தீர்மானிக்கின்றன

ஒரு base chain என்பது ஒரு hook-ஐக் குறிக்கிறது; இது packet பாதையில் அந்த chain இயங்கும் இடமாகும். prerouting routing முடிவுக்கு முன்பாக இயங்குகிறது. input இந்த machine-க்கு வரும் packet-களுக்காக இயங்குகிறது. forward இதன் வழியாக செல்லும் packet-களுக்காக forward இயங்குகிறது. output local process-களிலிருந்து வரும் packet-களுக்காக output இயங்குகிறது. postrouting packet வெளியேறுவதற்குச் சற்று முன்பு, கடைசியாக postrouting இயங்குகிறது.

Priority என்பது ஒரே hook-ல் உள்ள chain-களின் வரிசையைத் தீர்மானிக்கிறது; இதில் குறைந்த எண் கொண்டவை முதலில் இயங்கும். nftables பாரம்பரிய மதிப்புகளுக்குப் பெயர்களை வழங்குகிறது: raw என்பது -300, mangle என்பது -150, dstnat என்பது -100, filter என்பது 0, srcnat என்பது 100 ஆகும். priority filter; என்று எழுதுவது priority 0; என்று எழுதுவதற்குச் சமமாகும்.

இப்போது பல்வேறு கருவிகளை ஒன்றாகப் பயன்படுத்துவது வேலை செய்யுமா என்பதைத் தீர்மானிக்கும் பகுதிக்கு வருவோம். ஒரு hook-ல் பதிவு செய்யப்பட்ட ஒவ்வொரு base chain-ம், அதன் priority வரிசைப்படி இயங்கும். உங்கள் chain-ல் ஒரு packet ஏற்கப்பட்டால், அதன் செயல்முறை முடிவடையாது: accept அந்த chain-ஐ மட்டுமே முடிக்கும், packet அதே hook-ல் உள்ள அடுத்த base chain-க்குச் செல்லும். drop என்பது எல்லா இடங்களிலும் இறுதியானது, இது packet-ஐ உடனடியாக நிறுத்திவிடும். எனவே, உங்கள் table-ல் உள்ள ஒரு தளர்வான விதி, ufw table-ல் உள்ள drop விதியை மாற்ற முடியாது; எது முதலில் இயங்கினாலும் இது பொருந்தும். மேலும், உங்கள் accept, பிற்காலத்தில் இயங்கும் ஒரு chain-லிருந்து உங்களுக்கு எந்தப் பாதுகாப்பையும் வழங்காது.

ஒரே hook-ல் ஒரே priority கொண்ட இரண்டு base chains இருந்தால், அவை பதிவு செய்யப்பட்ட வரிசையில் இயங்கும்; இது எந்த service முதலில் தொடங்குகிறது என்பதைப் பொறுத்தது. அந்த வரிசை reboot-க்குப் பிறகு மாறக்கூடும். நீங்கள் உங்கள் சொந்த table-ஐ ufw-வுடன் சேர்த்து இயக்க விரும்பினால், அதற்குத் தனித்துவமான priority-ஐ வழங்கவும். அப்போதுதான் வரிசை முறை முன்கூட்டியே தீர்மானிக்கப்படும், இல்லையெனில் அது race condition-க்கு வழிவகுக்கும்.

ஏன் எழுத வேண்டிய reverse NAT விதி எதுவும் இல்லை?

மக்கள் அடிக்கடி தவறாகப் புரிந்துகொள்ளும் கேள்வி இதுதான், இதோ அதற்கான நேரடி பதில். Connection tracking உங்களுக்காக reverse translation-ஐ எழுதிவிடுகிறது. நீங்கள் கூடுதலாக எந்த விதியையும் சேர்க்க வேண்டியதில்லை.

ஒரு VPS-ன் வழக்கமான பணிகளின் இரண்டு பாதிகளையும் செய்யும் nat table இதோ:

table inet nat {
  chain prerouting {
    type nat hook prerouting priority dstnat; policy accept;
    iifname "enp1s0" tcp dport 8080 dnat ip to 10.0.0.5:80
  }

  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 10.0.0.0/24 oifname "enp1s0" masquerade
  }
}

ஒரு connection-ன் முதல் packet மட்டுமே nat chain-ல் சரிபார்க்கப்படும். ஒரு விதி பொருந்தும்போது, kernel அந்த translation-ஐ connection tracking table-ல் அந்த connection-ன் பதிவோடு சேர்த்துச் சேமித்துக்கொள்ளும். அதன் பிறகு வரும் ஒவ்வொரு packet-ம், இரண்டு திசைகளிலும், சேமிக்கப்பட்ட அந்தப் பதிவின் அடிப்படையில் மாற்றியமைக்கப்படும்; மீண்டும் எந்த விதியும் வாசிக்கப்படாது. conntrack கருவியை நிறுவி, நேரடிப் பதிவை (live entry) பாருங்கள்.

sudo apt install -y conntrack
sudo conntrack -L -p tcp

tcp 6 431999 ESTABLISHED src=198.51.100.20 dst=203.0.113.10 sport=54321 dport=8080 src=10.0.0.5 dst=198.51.100.20 sport=80 dport=54321 [ASSURED] mark=0 use=1

இதை இரண்டு tuples-ஆக வாசியுங்கள். முதல் நான்கு புலங்கள் (fields) client அனுப்பிய connection, இது உங்கள் public address-ஆன 203.0.113.10:8080-ஐ நோக்கியது. அடுத்த நான்கு புலங்கள் kernel எதிர்பார்க்கும் பதில் (reply), இது ஏற்கனவே மாற்றப்பட்டு, 10.0.0.5:80-லிருந்து, அதாவது உண்மையான backend-லிருந்து வருகிறது. அந்த இரண்டாவது tuple தான் reverse விதி. முதல் packet பொருந்தும்போது kernel அதை எழுதிவிட்டது.

எனவே, திரும்ப வரும் திசைக்கு (return direction) எந்த விதியையும் எழுதாதீர்கள். அது பொருந்தாது, ஏனெனில் திரும்ப வரும் packets ஏற்கனவே established ஆன connection-க்கு உரியவை, அவை ஒருபோதும் nat chain-ஐ அடையாது. ஒருவேளை அது பொருந்தினாலும், kernel ஏற்கனவே சரிசெய்த packet-ஐ நீங்கள் மீண்டும் மாற்றியமைக்க நேரிடும்.

ஒரு rewrite எங்கே இருக்க வேண்டும் என்பது இதே வழிமுறையைப் பொறுத்தது. Destination translation-ஐ prerouting-ல், routing முடிவுக்கு முன்பே செய்ய வேண்டும். ஏனெனில், routing புதிய destination-ஐப் பார்க்க வேண்டும், இல்லையெனில் packet தவறான இடத்திற்குச் சென்றுவிடும். அதே காரணத்திற்காக, box-ஆல் உருவாக்கப்படும் traffic output hook-ல் கையாளப்படுகிறது. Source translation, source port rewrite உட்பட, routing வெளியேறும் interface-ஐத் தேர்ந்தெடுத்த பிறகு, postrouting-ல் நடக்க வேண்டும். masquerade அந்த interface-லிருந்து அதன் முகவரியை எடுத்துக்கொள்ளும், routing நடக்கும் வரை அந்த interface எதுவென்று தெரியாது.

அதனால்தான் இது போன்ற ஒரு விதி பாதையின் இறுதியில் மட்டுமே இருக்க வேண்டும், வேறு எங்கும் இருக்கக்கூடாது.

ip saddr 10.0.0.0/24 oifname "enp1s0" snat ip to 203.0.113.10:20000-30000

பல internal clients ஒரே public address-ஐப் பகிர்ந்து கொள்ளும்போது, அவற்றின் source ports மோதிக்கொண்டால், source port-ஐயும் source address-ஐயும் மாற்றியமைக்க இந்த port range பயன்படுகிறது. அந்த range-ல் உள்ள ஒரு port-க்கு பதில் (reply) வரும்போது, conntrack அதை அந்தப் பதிவோடு பொருத்தி, packet விநியோகிக்கப்படுவதற்கு முன்பே அசல் source port-ஐ மீண்டும் அமைத்துவிடும். மீண்டும் சொல்கிறேன், இரண்டாவது விதி தேவையில்லை.

ஒரு நடைமுறை விளைவு: ஏற்கனவே உள்ள connection-களை ஒரு NAT விதியை மாற்றுவது பாதிக்காது, ஏனெனில் அவற்றின் translation ஏற்கனவே சேமிக்கப்பட்டுவிட்டது. அவற்றின் பதிவுகள் காலாவதியாகும் வரை அவை பழைய செயல்பாட்டையே தொடரும். sudo conntrack -D -p tcp --dport 8080 பொருந்தக்கூடிய பதிவுகளை நீக்கும், sudo conntrack -F அனைத்தையும் நீக்கும். NAT box-ல் இரண்டாவது கட்டளையை கவனமாகப் பயன்படுத்துங்கள், ஏனெனில் அந்தச் சேமிக்கப்பட்ட translation-கள்தான் தற்போதைய connection-களை உயிர்ப்புடன் வைத்திருக்கின்றன; அவற்றை அழிப்பது box வழியாக நடக்கும் அனைத்து connection-களையும் ஒரே நேரத்தில் துண்டித்துவிடும்.

ufw மற்றும் Docker ஆகிய இரண்டும் தங்களுக்கென தனித்தனி விதிகளை உருவாக்குகின்றன

ufw என்பது iptables-க்கான ஒரு front end ஆகும்; இது Ubuntu-வில் nftables-க்கான front end ஆகச் செயல்படுகிறது. எனவே, ஒரு ufw server-ல் ufw-before-input, ufw-user-input போன்ற பெயர்களைக் கொண்ட chains நிறைந்த ஒரு ip filter table இருக்கும், அதனுடன் அதே அமைப்பைக் கொண்ட ஒரு ip6 filter நகலும் இருக்கும். இவற்றை sudo nft list ruleset | grep ufw மூலம் சரிபார்க்கலாம். அந்த chains அனைத்தும் /etc/ufw-ல் உள்ள கோப்புகளிலிருந்து உருவாக்கப்படுகின்றன. ufw reload அவற்றை முழுமையாக மீண்டும் எழுதுவதால், கையால் சேர்க்கப்படும் ஒரு iptables விதி அடுத்த முறை reload செய்யும்போது மறைந்துவிடும். VPS-க்கான ufw அடிப்படைகள் அந்த கோப்பு அமைப்பை விளக்குகின்றன.

Docker தனது firewall-ஐத் தானே நிர்வகித்துக்கொள்கிறது, அது ufw-ஐக் கலந்தாலோசிப்பதில்லை. -p 80:80 மூலம் ஒரு port-ஐ வெளியிடும்போது, அது nat table-ல் ஒரு DNAT விதியை எழுதி, forward path-ல் ஒரு accept விதியைச் சேர்க்கிறது. இவை இரண்டும் ufw-ன் user chains-க்கு முன்பே இயங்குகின்றன. இதன் விளைவு அனைவரையும் ஆச்சரியப்படுத்தும்: ufw deny 80 loaded நிலையில் இருந்தாலும், container இணையத்திலிருந்து அணுகக்கூடியதாகவே இருக்கும். இதற்கான தீர்வு Docker உங்களுக்காக விட்டுவைத்துள்ள DOCKER-USER chain-ல் உள்ளது. Docker containers ஏன் ufw-ஐப் புறக்கணிக்கின்றன என்பது குறித்து விரிவாகப் பார்க்கவும். உங்கள் server-ல் என்ன உள்ளது என்பதை sudo nft list ruleset | grep -i docker மூலம் கண்டறியவும்.

இப்போது மேலே உள்ள config-ல் உள்ள அந்த flush ruleset வரியை மீண்டும் வாசிக்கவும். அது அந்த இரண்டு கருவிகளும் நிர்வகிக்கும் tables உட்பட அனைத்து tables-களையும் நீக்கிவிடும். ஒரு Docker host-ல், sudo systemctl restart docker அந்த chains-ஐ மீண்டும் உருவாக்கும் வரை, published ports வேலை செய்யாது. firewall-ஐச் சுத்தம் செய்யும்போது மக்கள் தங்கள் சொந்த services-ஐத் தாங்களே offline ஆக்கிக்கொள்ளும் பொதுவான வழி இந்த ஒரே ஒரு வரிதான்.

Reboot-க்குப் பிறகும் நிலைத்திருக்கும் விதிகள்

எந்தவொரு விதிகளும் தானாகவே நிலைத்திருக்காது. கணினி அணைக்கப்படும்போது kernel அனைத்து விதிகளையும் மறந்துவிடும். ஒவ்வொரு பக்கமும் இதற்கென தனித்தனி package-களைப் பயன்படுத்துகின்றன.

nftables-க்கு, /etc/nftables.conf கோப்பை nftables.service வாசிக்கிறது. Ubuntu-வில் இந்த service முடக்கப்பட்டே (disabled) இருக்கும், எனவே அதை நம்புவதற்கு முன் சரிபார்க்கவும்.

systemctl is-enabled nftables
sudo nft -c -f /etc/nftables.conf
sudo systemctl enable --now nftables

iptables-க்கு, iptables-persistent என்ற package பயன்படுத்தப்படுகிறது. இது netfilter-persistent-ஐ நிறுவி, விதிகளை /etc/iptables/rules.v4 மற்றும் /etc/iptables/rules.v6 கோப்புகளில் சேமிக்கிறது.

sudo apt install -y iptables-persistent
sudo netfilter-persistent save

இவ்விரண்டையும் ஒரே நேரத்தில் இயக்க வேண்டாம். firewall-ஐ நிர்வகிப்பதாகக் கூறும் இரண்டு கோப்புகள் இருந்தால், அவை ஒன்றோடொன்று முரண்படும். கடைசியாக load செய்யப்படும் கோப்பே அமலுக்கு வரும், ஆனால் எந்தக் கோப்பு முதலில் வரும் என்பதை எவராலும் கணிக்க முடியாது.

நேரலையில் உள்ள விதிகளை dump செய்வதில் ஒரு சிக்கல் உள்ளது. sudo nft -s list ruleset > /etc/nftables.conf அந்த நேரத்தில் load ஆகியுள்ள அனைத்து விதிகளையும், அதாவது ufw மற்றும் Docker-ன் அட்டவணைகளையும் சேர்த்துப் பிடிக்கும். இதை boot-ன் போது restore செய்தால், அந்த கருவிகள் தாங்களாகவே உருவாக்க வேண்டிய விதிகளின் நகல் ஒன்று உருவாகும்; அவை மீண்டும் இயங்கும்போது இரண்டாவது நகல் உருவாகி குழப்பத்தை ஏற்படுத்தும். உங்கள் சொந்த அட்டவணையை மட்டும் sudo nft -s list table inet filter மூலம் dump செய்யவும். -s flag-ஐப் பயன்படுத்தினால், configuration கோப்பில் இருக்கக்கூடாத counters தவிர்க்கப்படும்.

உங்கள் VPS-ல் firewall-ஐ இயக்க வேண்டுமா?

உங்களுக்குத் தேவையானதை ufw மூலம் செய்ய முடியாவிட்டால் ஒழிய, அதை மாற்ற வேண்டாம். ஒரு சாதாரண VPS-க்குத் தேவையான அனைத்தையும் ufw வழங்குகிறது: இயல்பாக அனைத்தையும் மறுத்தல் (default deny) மற்றும் குறிப்பிட்ட சில ports-ஐ மட்டும் அனுமதித்தல். வெறும் தேவைக்காக மட்டும் அதை நீக்கிவிட்டு, நீங்களாகவே ஒரு ruleset-ஐ உருவாக்கினால், அது அதே firewall பாதுகாப்பைத்தான் தரும், ஆனால் பராமரிப்புச் சுமை மட்டுமே கூடும்.

ufw-ன் கட்டமைப்பிற்குள் அடங்காத தேவைகள் இருக்கும்போது மட்டும் native முறையைப் பயன்படுத்தவும்: NAT மற்றும் port forwarding, runtime-ல் நீங்கள் மாற்றக்கூடிய sets, ஒரே விதியின் கீழ் இரு address families-ஐயும் கையாளுதல் அல்லது நீங்களாகவே முன்னுரிமை அளிக்கும் chain-கள் போன்றவை. இவைதான் உண்மையான காரணங்கள்; இவற்றை ufw-ஆல் செய்ய முடியாது.

நீங்கள் native முறைக்கு மாறினால், முழுமையாக மாறிவிடுங்கள். sudo ufw disable மற்றும் sudo systemctl disable --now ufw கட்டளைகளை இயக்கவும், அதன் tables நீக்கப்பட்டுவிட்டதை sudo nft list ruleset மூலம் உறுதிப்படுத்தவும், அதன் பிறகு உங்கள் சொந்த கோப்பை ஏற்றவும். ufw மற்றும் நீங்களாக எழுதிய table ஆகிய இரண்டையும் ஒரே நேரத்தில் இயக்கினால் traffic செல்லும், ஆனால் நடைமுறையில் உள்ள policy என்பது இரண்டு ruleset-களின் தொகுப்பாக இருக்கும். அது எந்த வரிசையில் இயங்குகிறது என்பது service தொடங்கும் நேரத்தைப் பொறுத்தது; எனவே, கோப்புகளைப் படிப்பவர்களால் அந்த server-ன் உண்மையான firewall நிலையைத் துல்லியமாகக் கூற முடியாது.

ஏற்கனவே உள்ள iptables விதிகளை இடம்பெயர்த்தல்

iptables-translate ஒரு விதியை மாற்றி, அதன் nftables வடிவத்தை அச்சிடுகிறது. இது server-ல் எந்த மாற்றத்தையும் செய்யாது.

iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT

nft add rule ip filter INPUT tcp dport 22 counter accept

iptables-restore-translate -f /etc/iptables/rules.v4 முழுமையாகச் சேமிக்கப்பட்ட விதிகளுக்கும் இதையே செய்கிறது. இதன் வெளியீட்டை ஒரு முதல் வரைவாகக் கருதவும். இந்த மாற்றம் இயந்திரத்தனமானது மற்றும் விதிக்கு விதி நடைபெறுவது; எனவே, பழைய table மற்றும் chain பெயர்களே மீண்டும் கிடைக்கும். IPv4 மற்றும் IPv6-க்கு என இரண்டு தனித்தனி விதிகளே கிடைக்கும், nftables-க்கு மாறுவதன் முக்கிய நோக்கமான sets இதில் இருக்காது. இதை நீங்களே ஒரு inet table-ஆக கையால் மாற்றி எழுதவும். நேரடி server-ல் பயன்படுத்துவதற்கு முன் nft -c -f மூலம் அதைச் சரிபார்க்கவும்.

இந்த உதாரணங்களில் உள்ள முகவரிகள் 203.0.113.0/24 மற்றும் 198.51.100.0/24 ஆகிய ஆவண வரம்புகளிலிருந்து எடுக்கப்பட்டவை, மேலும் enp1s0 என்பது ஒரு interface பெயர். என்னுடையதை அப்படியே நகலெடுப்பதற்குப் பதிலாக, ip route show default மற்றும் ip -br addr ஆகியவற்றிலிருந்து உங்களுடையதை எடுத்துக்கொள்ளுங்கள். ஏனெனில், தற்போதைய Ubuntu images-ல் எதற்கும் eth0 என்று பெயரிடப்படுவது அரிது.

FAQ

Ubuntu-வில் iptables பயன்பாட்டில் இல்லையா (deprecated)?

இந்தக் கட்டளை நீக்கப்படவில்லை, இது Ubuntu 24.04-லும் தொடர்ந்து செயல்படும். இதில் மாறியிருப்பது அதன் பின்னணியில் நடக்கும் செயல்பாடுகள் மட்டுமே: iptables என்பது ஒரு front end, இது iptables-nft back end வழியாக nftables விதிகளை எழுதுகிறது. உங்கள் கணினியில் உள்ளதை iptables -V மூலம் சரிபார்க்கவும், இது 24.04-ல் iptables v1.8.10 (nf_tables) என்று காட்டும். பழைய x_tables back end இன்னும் iptables-legacy ஆக வழங்கப்படுகிறது, இது முற்றிலும் தனித்துவமான விதிகளை (ruleset) கொண்டுள்ளது. எனவே, விதிகளை ஏதேனும் ஒரு back end-ல் மட்டும் பதிவிடவும், இரண்டிலும் வேண்டாம்.

திரும்பும் வழியில் NAT-ஐ நீக்க இரண்டாவது விதி தேவையா?

தேவையில்லை. ஒரு connection-ன் முதல் packet nat விதியுடன் பொருந்தும்போது, connection tracking அந்த மாற்றத்தைச் சேமித்துக்கொள்ளும். அதன் பிறகு வரும் அனைத்து packet-களும் அந்தச் சேமிக்கப்பட்ட பதிவின் அடிப்படையில் மாற்றப்படும். sudo conntrack -L ஒரு connection-க்கு இரண்டு tuples-ஐக் காட்டும்: ஒன்று அசல் திசை, மற்றொன்று ஏற்கனவே மாற்றப்பட்ட பதில் (reply). திரும்பும் திசைக்காக எழுதப்படும் விதி உதவாது, ஏனெனில் திரும்பும் packet-கள் ஒருபோதும் nat chain-ஐ அடைவதில்லை.

ufw மற்றும் எனது சொந்த nftables விதிகளை ஒரே நேரத்தில் இயக்க முடியுமா?

இது செயல்படும், ஆனால் சிக்கல்களை உருவாக்கும். ஒவ்வொரு base chain-ம் hook-ல் இயங்குவதால், நடைமுறையில் உள்ள கொள்கை (policy) இரண்டு விதிகளின் தொகுப்பாக இருக்கும். இவை முன்னுரிமை (priority) அடிப்படையில் வரிசைப்படுத்தப்படும்; சமமான முன்னுரிமை எனில், எந்த service முதலில் தொடங்குகிறதோ அதுவே முன்னிலை பெறும். ஏதேனும் ஒன்றில் உள்ள drop இறுதியானது, மேலும் உங்களது விதியில் உள்ள ஒரு accept மற்றொன்று packet-ஐத் தடுப்பதைத் தடுக்காது. ஏதேனும் ஒரு கருவியை மட்டும் தேர்ந்தெடுக்கவும். nftables-ஐத் தேர்ந்தெடுத்தால், முதலில் ufw-ஐ முடக்கிவிட்டு, sudo nft list ruleset-ல் அதன் tables நீக்கப்பட்டுள்ளதை உறுதிப்படுத்தவும்.

Ubuntu-வில் reboot செய்த பிறகும் nftables விதிகள் நீடிக்க என்ன செய்ய வேண்டும்?

விதித் தொகுப்பை (ruleset) /etc/nftables.conf-ல் வைத்து, sudo nft -c -f /etc/nftables.conf மூலம் சரிபார்த்து, பின் sudo systemctl enable --now nftables-ஐ இயக்கவும். இந்த service இயல்பாகவே enabled நிலையில் இருக்காது, எனவே systemctl is-enabled nftables-ஐ ஒருமுறை இயக்குவது நல்லது. அந்த file-ஐ உருவாக்கும்போது, உங்கள் சொந்த table-ஐ மட்டும் sudo nft -s list table inet filter மூலம் dump செய்யவும். ஏனெனில், முழுமையான list ruleset dump-ல் ufw மற்றும் Docker தமக்காக நிர்வகிக்கும் tables-களும் சேர்ந்துவிடும்.