Ubuntu वर iptables की nftables? नेमके कोणते चालते

Ubuntu मधील iptables विरुद्ध nftables: तुमच्या बॉक्सवर कोणते चालू आहे?

Ubuntu 20.04 आणि त्यानंतरच्या आवृत्त्यांमध्ये iptables command हा nftables नियम लिहिणारा front end आहे. Kernel मध्ये एकच packet filter चालतो: nftables. त्याला program करण्यासाठी दोन user space commands वापरता येतात. iptables -A INPUT line पूर्वीप्रमाणेच कार्य करते आणि ती तयार करणारा नियम nftables नियम असतो, जो nft print करू शकतो.

हे मान्य करण्यापूर्वी तुमच्या स्वतःच्या server वर याची खात्री करा.

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

Ubuntu 24.04 मध्ये (August 2026 पर्यंत iptables 1.8.10), iptables -V हे iptables v1.8.10 (nf_tables) print करते. कंसातील नाव backend दर्शवते. (nf_tables) म्हणजे command nftables शी संवाद साधते. (legacy) म्हणजे जुना x_tables backend. Ubuntu अजूनही तो iptables-legacy म्हणून उपलब्ध करून देते आणि kernel त्याला पूर्णपणे स्वतंत्र ruleset म्हणून ठेवतो. त्या निवडीमागील symlink update-alternatives print करते: link currently points to /usr/sbin/iptables-nft.

Firewall configuration नसलेल्या नव्या VPS वर sudo nft list ruleset काहीही print करत नाही. हे रिकामे output तुमचा 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 त्याने तयार केलेले tables दर्शवते. हे चिन्ह दिसल्यावर nft ती warning print करते, कारण अशा table मध्ये nft वापरून बदल केल्यास त्याच rules वर दोन tools चे नियंत्रण राहते. एका command ने काय तयार केले ते पाहा: तुम्ही नाव न दिलेला table आणि तुम्ही मागणी न केलेल्या chains. ही जुनी पद्धत आहे. nftables थेट लिहिताना सर्वप्रथम याच गोष्टीत बदल होतो.

तुमच्यापासून iptables -L काय लपवते

iptables -L फक्त filter तक्ता दाखवते. NAT (network address translation) नियमांसाठी iptables -t nat -L आवश्यक आहे, तर mangle नियमांसाठी -t mangle आवश्यक आहे. IPv6 स्वतंत्र command, ip6tables मध्ये असते आणि त्यामध्ये प्रत्येक नियमाची स्वतंत्र प्रत असते. त्यामुळे एखाद्या listing मध्ये server स्वच्छ दिसू शकतो, पण तुम्ही कधीही तपासले नाही अशा table मधून काहीतरी तुमचे packets drop किंवा rewrite करत असू शकते.

sudo nft list ruleset प्रत्येक family, प्रत्येक table, प्रत्येक chain आणि प्रत्येक rule एकाच output मध्ये दाखवते. तुम्ही स्वतः तयार न केलेल्या server वर प्रत्यक्षात काय loaded आहे हे पाहण्याचा हा सर्वात जलद मार्ग आहे. Rule handles दाखवण्यासाठी -a जोडा. संपूर्ण chain ऐवजी एखादा एकच rule delete करण्यासाठी हे handles आवश्यक असतात.

तुम्ही येथे असताना दोन सवयी सुधारणे उपयुक्त ठरेल. iptables -L addresses आणि ports चे names मध्ये resolution करते. त्यामुळे resolver मध्ये बिघाड असलेल्या server वर ते command अडकलेले दिसते: iptables -nvL वापरा. तसेच sudo iptables-legacy -nvL वापरून legacy backend रिकामा असल्याची खात्री करा. दोन्ही backends मध्ये rules असल्यास kernel दोन्हींचे evaluation करते आणि कोणत्याही एका listing मधून संपूर्ण स्थिती दिसत नाही.

तुम्ही तयार केलेले tables आणि chains, वारशाने मिळालेले नाहीत

nftables ची सुरुवात रिकाम्या configuration पासून होते. तुम्ही तयार करेपर्यंत filter table अस्तित्वात नसतो आणि filter हा शब्द तुम्ही निवडलेले केवळ एक नाव असतो. एखाद्या chain ला type, hook आणि priority दिल्यावरच ती packets पाहते; त्यामुळे ती base chain बनते. ही माहिती नसलेली chain केवळ स्पष्ट jump किंवा goto केल्यावरच गाठली जाते. त्यामुळे तिच्यावर काहीतरी jump होईपर्यंत तिचा कोणताही खर्च होत नाही.

दुसरा महत्त्वाचा बदल म्हणजे inet family. एक inet table IPv4 आणि IPv6 साठी त्याच rules हाताळतो. त्यामुळे iptables मध्ये एखादा port बंद आणि ip6tables मध्ये पूर्णपणे उघडा राहण्यासारख्या bugs चा एक संपूर्ण प्रकार टाळता येतो. हा mismatch इतका सामान्य आहे की ufw boxes वर त्यासाठी स्वतंत्र failure mode आहे.

ही संपूर्ण server ruleset आहे. ती /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;
  }
}

Line 2 दोनदा वाचा. flush ruleset box वरील सर्व tables delete करते. यामध्ये ufw आणि Docker यांनी स्वतःसाठी तयार केलेल्या tables चाही समावेश होतो. Live server वर हे चालवण्यापूर्वी पुढील मजकूर पूर्ण वाचा.

Input chain मधील पहिला rule बहुतांश काम करतो. तुम्ही सुरू केलेल्या connections ची replies परत येऊ देण्यासाठी ct state established,related accept वापरले जाते. त्यामुळे उर्वरित chain ला केवळ नवीन connections बद्दल निर्णय घ्यावा लागतो. कोणत्याही ज्ञात connection शी किंवा वैध सुरुवातीशी जुळत नसलेले packets ct state invalid drop टाकून देते. त्यानंतरचे सर्व नियम स्पष्टपणे अनुमती दिलेले मार्ग आहेत आणि उर्वरित traffic policy drop हाताळते.

File load करण्यापूर्वी ती तपासा आणि हे करताना दुसरे SSH session उघडे ठेवा. policy drop तसेच SSH rule मधील एक typo यामुळे तुम्ही स्वतःच्याच server मधून lock out होऊ शकता.

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

nft -c -f file parse करते आणि ती load न करता errors दाखवते. Parse यशस्वी असल्यास कोणतेही output दिसत नाही.

दीर्घ rule lists ऐवजी sets वापरा

tcp dport { 80, 443 } हा anonymous set आहे: प्रत्येक port साठी एक rule ठेवण्याऐवजी एक rule आणि एक 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 किंवा rule renumbering आवश्यक नाही. Set मध्ये पाच addresses असोत किंवा पन्नास हजार, match करण्यासाठी एकच lookup वापरला जातो. Set मध्ये ranges आणि 198.51.100.0/24 सारखे CIDR (classless inter-domain routing) prefixes ठेवता येतात, कारण flags interval हे flag त्यासाठी आवश्यक आहे. हे flag नसल्यास set मध्ये फक्त single addresses स्वीकारले जातात आणि prefix load करणे अयशस्वी होते.

Sets मधील elements स्वतः expire होऊ शकतात.

set banned {
  type ipv4_addr
  flags timeout
  timeout 1h
}

ip saddr @banned drop असलेल्या rule मुळे प्रत्येक element add केल्यानंतर एक तासाने स्वतः remove होतो. Ubuntu 24.04 वरील fail2ban मधील nftables action address ला अशा प्रकारे ban करते: ती set मध्ये एक element add करते, rule add करत नाही. Ports ही संकल्पना नवीन असल्यास Linux मध्ये port प्रत्यक्षात काय असतो येथून सुरुवात करा.

Migration करताना एक फरक अनेकांच्या लक्षात येत नाही. तुम्ही स्पष्टपणे सांगितल्याशिवाय nftables packets मोजत नाही. iptables -nvL प्रत्येक rule साठी counters नेहमी दाखवते. nftables मध्ये counter keyword असलेल्या rulesनाच numbers मिळतात. त्यामुळे नंतर debug करण्याची अपेक्षा असलेल्या प्रत्येक rule मध्ये counter ठेवा.

हुक आणि प्राधान्यक्रम अंमलबजावणीचा क्रम कसा ठरवतात

Base chain मध्ये एक hook नमूद केलेला असतो. Packet path मधील ज्या टप्प्यावर तो चालतो, तो hook असतो. prerouting routing decision पूर्वी चालतो. input या मशीनसाठी असलेल्या packets वर चालतो. forward या मशीनमधून route होणाऱ्या packets वर चालतो. output स्थानिक processes कडून आलेल्या packets वर चालतो. postrouting शेवटी, packet बाहेर जाण्यापूर्वी चालतो.

Priority मुळे एका hook मधील chains चा क्रम ठरतो. सर्वात कमी संख्या आधी येते. nftables पारंपरिक values साठी नावे देते: raw म्हणजे -300, mangle म्हणजे -150, dstnat म्हणजे -100, filter म्हणजे 0 आणि srcnat म्हणजे 100. priority filter; लिहिणे आणि priority 0; लिहिणे समान आहे.

आता tools एकत्र वापरता येतील की नाही हे ठरवणारा भाग पाहू. Hook वर नोंदवलेली प्रत्येक base chain priority च्या क्रमाने चालते. तुमच्या chain मध्ये packet स्वीकारला तरी प्रक्रिया पूर्ण होत नाही: accept फक्त ती chain समाप्त करतो आणि packet त्याच hook वरील पुढील base chain कडे जातो. drop सर्वत्र अंतिम असतो आणि packet त्वरित थांबवतो. त्यामुळे तुमच्या table मधील permissive rule मुळे ufw च्या table मधील drop रद्द होत नाही, कोणती chain आधी चालली याची पर्वा न करता. तसेच, नंतर चालणाऱ्या chain पासून तुमचे accept तुम्हाला संरक्षण देत नाही.

समान hook वर समान priority असलेल्या दोन base chains registration order नुसार चालतात. हा क्रम कोणती service आधी सुरू झाली यावर अवलंबून असतो. रीबूटनंतर हा क्रम बदलू शकतो. ufw सोबत तुमची स्वतःची table चालवायची असल्यास तिला स्वतंत्र priority द्या. त्यामुळे क्रम आधीच निश्चित होतो आणि त्यासाठी registration race होत नाही.

रिव्हर्स 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 च्या entry सोबत साठवतो. त्यानंतर दोन्ही दिशांमधील प्रत्येक packet stored entry नुसार rewrite केला जातो. कोणताही नियम पुन्हा वाचला जात नाही. conntrack tool install करा आणि 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 आहे. ते 203.0.113.10:8080 या तुमच्या public address कडे निर्देशित असते. पुढील चार fields म्हणजे kernel ला अपेक्षित असलेला reply आहे. तो आधीच उलटवलेला आणि translated असतो आणि 10.0.0.5:80 या वास्तविक backend कडून येतो. हा दुसरा tuple म्हणजेच reverse rule आहे. पहिला packet जुळला तेव्हा kernel ने तो लिहिला.

म्हणून return direction साठी नियम लिहू नका. तो जुळू शकत नाही, कारण return packets established connection चा भाग असतात आणि nat chain पर्यंत कधीही पोहोचत नाहीत. तो काही प्रकारे तिथे पोहोचलाच, तरी kernel ने आधीच दुरुस्त केलेला packet पुन्हा translate केला जाईल.

Rewrite कुठे ठेवायचा हे याच यंत्रणेतून ठरते. Destination translation prerouting मध्ये, routing decision च्या आधी चालली पाहिजे. Routing ला नवीन destination दिसणे आवश्यक आहे; अन्यथा packet चुकीच्या ठिकाणी जाईल. Box ने स्वतः निर्माण केलेला traffic याच कारणासाठी output hook मध्ये हाताळला जातो. Source translation, ज्यामध्ये source port rewrite देखील समाविष्ट आहे, postrouting मध्ये, routing ने outgoing interface निवडल्यानंतर चालली पाहिजे. masquerade आपला address त्या interface कडून घेते. Routing पूर्ण होईपर्यंत interface माहीत नसतो.

म्हणून अशा प्रकारचा नियम path च्या शेवटीच असतो आणि इतर कुठेही नसतो.

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

Port range source address सोबत source port देखील rewrite करते. अनेक internal clients एकच public address वापरत असताना आणि त्यांचे source ports एकमेकांशी collide होत असताना हेच अपेक्षित असते. Reply त्या range मधील एखाद्या port कडे निर्देशित होऊन येतो. conntrack तो reply entry शी जुळवतो आणि packet deliver करण्यापूर्वी मूळ source port परत ठेवतो. पुन्हा, दुसऱ्या नियमाची गरज नसते.

याचा एक व्यावहारिक परिणाम असा आहे की NAT नियम बदलल्याने आधीपासून अस्तित्वात असलेली connections दुसरीकडे हलत नाहीत, कारण त्यांची translation आधीच साठवलेली असते. त्यांच्या entries expire होईपर्यंत त्या जुन्या पद्धतीनेच कार्यरत राहतात. sudo conntrack -D -p tcp --dport 8080 जुळणाऱ्या entries delete करते आणि sudo conntrack -F त्या सर्व delete करते. NAT box वर दुसऱ्या command चा वापर काळजीपूर्वक करा. या stored translations मुळेच सध्याच्या connections सुरू राहतात. त्यामुळे त्या flush केल्यास box मधून जाणारी प्रत्येक connection एकाच वेळी तुटते.

ufw आणि Docker दोघेही स्वतःचे rules लिहितात

ufw हा iptables साठी front end आहे. Ubuntu मध्ये iptables हा nftables साठी front end आहे. त्यामुळे ufw असलेल्या सर्व्हरमध्ये ip filter table असते. त्यात ufw-before-input, ufw-user-input इत्यादी नावांच्या chains असतात. याशिवाय त्याच संरचनेची ip6 filter copy देखील असते. हे sudo nft list ruleset | grep ufw वापरून पाहा. या chains /etc/ufw मधील files मधून तयार होतात. ufw reload त्या files वरून chains पुन्हा सुरुवातीपासून लिहिते. म्हणून वरून manually जोडलेला iptables rule पुढील reload वेळी नाहीसा होतो. VPS साठी ufw ची मूलभूत माहिती या file layout चे स्पष्टीकरण देते.

Docker firewall स्वतः configure करते आणि ufw चा सल्ला घेत नाही. -p 80:80 वापरून port publish केल्यावर nat table मध्ये DNAT rule लिहिला जातो आणि forward path मध्ये accept rule जोडला जातो. हे दोन्ही ufw च्या user chains च्या आधी लागू होतात. त्यामुळे एकदा का ufw deny 80 load केले, तरी container इंटरनेटवरून उपलब्ध राहतो. याचे निराकरण Docker ने तुमच्या rules साठी ठेवलेल्या DOCKER-USER chain मध्ये करता येते. Docker containers ufw कडे दुर्लक्ष का करतात याचे टप्प्याटप्प्याने स्पष्टीकरण देते. तुमच्या सर्व्हरवर काय configure आहे ते sudo nft list ruleset | grep -i docker वापरून पाहा.

आता वरील configuration मधील flush ruleset line पुन्हा वाचा. ती Docker आणि ufw ही दोन्ही tools व्यवस्थापित करत असलेल्या tables सह प्रत्येक table delete करते. Docker host वर published ports काम करणे थांबवतात. sudo systemctl restart docker chains पुन्हा तयार करेपर्यंत त्या ports उपलब्ध होत नाहीत. Firewall नीटनेटका करताना लोक स्वतःच्याच services बंद पाडतात, त्याचे हे सर्वांत सामान्य कारण आहे.

रीबूटनंतरही लागू राहणारे नियम

कोणतेही ruleset स्वतःहून persistent नसते. Shutdown वेळी 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 साठी package म्हणजे iptables-persistent. ते netfilter-persistent install करते आणि /etc/iptables/rules.v4 तसेच /etc/iptables/rules.v6 मध्ये save करते.

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

दोन्ही चालवू नका. Firewall ठेवण्याचा दावा करणाऱ्या दोन files कालांतराने वेगळ्या होतील. त्यांपैकी शेवटी load होणारी file लागू होईल; हे कोणती file लागू होईल हे दुसरी file न पाहता ठरवता येत नाही.

Live ruleset dump करतानाही एक संबंधित अडचण असते. sudo nft -s list ruleset > /etc/nftables.conf त्या क्षणी load असलेले सर्व नियम capture करते. यात ufw चे tables आणि Docker चे tables देखील येतात. Boot वेळी ते restore केल्यास या tools ना स्वतः तयार करायच्या असलेल्या नियमांची स्थिर copy load होते. ही tools सुरू झाल्यावर नियमांची दुसरी copy तयार होते. फक्त तुमचा स्वतःचा table dump करण्यासाठी sudo nft -s list table inet filter वापरा. -s flag counters वगळतो. Counters config file मध्ये ठेवायचे नसतात.

VPS वर बदल करावा का?

तुम्हाला ufw मधून व्यक्त करता येणार नाही अशी एखादी गोष्ट आवश्यक नसेल, तर ufw मध्ये बदल करू नका. नेहमीच्या VPS कामासाठी ufw पुरेसे आहे: काही मोजके पोर्ट खुले ठेवून default deny लागू करणे. केवळ स्वतःचे ruleset लिहिण्यासाठी ते बदलल्यास तुम्हाला तोच firewall आणि देखभालीसाठी आणखी एक घटक मिळतो.

तुमची गरज ufw च्या मॉडेलच्या बाहेर असेल, तेव्हा native पद्धत वापरा: NAT आणि port forwarding, runtime वर update करता येणारे sets, दोन्ही address families साठी लागू होणारा एक rule किंवा स्वतः निवडलेल्या chain priorities. ही योग्य कारणे आहेत. ufw मध्ये यापैकी कोणतीही गोष्ट व्यक्त करण्याची पद्धत नाही.

तुम्ही native पद्धत स्वीकारली, तर ती पूर्णपणे स्वीकारा. sudo ufw disable आणि sudo systemctl disable --now ufw चालवा. sudo nft list ruleset वापरून त्याचे tables हटले आहेत याची खात्री करा. त्यानंतर तुमची स्वतःची file load करा. ufw आणि हाताने लिहिलेले table एकत्र चालणाऱ्या box मधून network traffic तरीही पुढे जातो. मात्र live policy आता दोन rulesets चा संयोग असते. त्यांचे मूल्यमापन service startup ने ठरवलेल्या क्रमाने होते. त्यामुळे दोन्ही files वाचूनही प्रत्यक्षात box काय करते हे कोणीही निश्चित सांगू शकत नाही.

विद्यमान iptables ruleset चे स्थलांतर

iptables-translate एक rule रूपांतरित करून त्याचे 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 संपूर्ण saved ruleset साठीही हेच करते. तिचे output हे पहिला मसुदा समजा. रूपांतरण यांत्रिक असून प्रत्येक rule स्वतंत्रपणे रूपांतरित केले जाते. त्यामुळे जुन्या table आणि chain names, IPv4 आणि IPv6 साठी दोन स्वतंत्र rulesets, तसेच हे स्थलांतर करण्यामागील मुख्य फायदा असलेले कोणतेही sets मिळत नाहीत. ते हाताने एकाच inet table मध्ये पुन्हा लिहा. Live server वर लागू करण्यापूर्वी nft -c -f वापरून ते तपासा.

या उदाहरणांमधील addresses documentation ranges 203.0.113.0/24 आणि 198.51.100.0/24 मधून घेतले आहेत. enp1s0 हे interface name आहे. माझे values कॉपी करण्याऐवजी तुमचे values ip route show default आणि ip -br addr मधून घ्या, कारण सध्याच्या Ubuntu images मध्ये interface चे नाव क्वचितच eth0 असते.

FAQ

Ubuntu वर iptables अप्रचलित आहे का?

ही command हटवली जात नाही आणि Ubuntu 24.04 वर अजूनही कार्य करते. बदल आतून होणाऱ्या प्रक्रियेत झाला आहे: iptables हा असा front end आहे, जो iptables-nft back end मार्फत nftables rules लिहितो. iptables -V वापरून तुमची स्थिती तपासा. Ubuntu 24.04 वर ते iptables v1.8.10 (nf_tables) दाखवते. जुना x_tables back end अजूनही iptables-legacy म्हणून उपलब्ध आहे. त्याच्याकडे स्वतंत्र ruleset असतो. त्यामुळे rules एका back end मध्येच ठेवा; दोन्ही back end मध्ये ठेवू नका.

परतीच्या मार्गावर NAT पूर्ववत करण्यासाठी दुसरा rule आवश्यक आहे का?

नाही. Connection tracking मध्ये connection चे पहिले packet nat rule शी जुळते तेव्हा translation साठवले जाते. त्यानंतर दोन्ही दिशांमधील प्रत्येक packet त्या साठवलेल्या entry नुसार पुन्हा लिहिला जातो. sudo conntrack -L हे प्रत्येक connection साठी दोन tuples दाखवते: प्रथम मूळ दिशा आणि त्यानंतर आधीच उलटवलेला reply. Return direction साठी लिहिलेला rule उपयोगी ठरत नाही, कारण return packets कधीही nat chain पर्यंत पोहोचत नाहीत.

मी ufw आणि माझे स्वतःचे nftables rules एकाच वेळी चालवू शकतो का?

ते कार्य करते, पण त्यामुळे समस्या निर्माण होऊ शकते. Hook वरील प्रत्येक base chain चालते. त्यामुळे live policy म्हणजे दोन्ही rulesets चे एकत्रित परिणाम असतात. त्यांचा क्रम priority नुसार ठरतो आणि priority समान असल्यास, आधी सुरू झालेल्या service नुसार ठरतो. त्यांपैकी कोणत्याही एकामधील drop अंतिम परिणाम ठरवते. तुमच्यातील accept दुसऱ्या ruleset ला तोच packet drop करण्यापासून थांबवत नाही. एकच tool निवडा. nftables वापरायचे असल्यास, आधी ufw disable करा आणि sudo nft list ruleset मधून त्याचे tables हटले आहेत याची खात्री करा.

Ubuntu वर reboot नंतर nftables rules कसे टिकवू?

Ruleset /etc/nftables.conf मध्ये ठेवा, sudo nft -c -f /etc/nftables.conf वापरून ते तपासा आणि नंतर sudo systemctl enable --now nftables चालवा. ही service default ने enabled नसते. त्यामुळे systemctl is-enabled nftables एकदा चालवणे उपयुक्त आहे. ही file तयार करताना फक्त तुमचे स्वतःचे table sudo nft -s list table inet filter वापरून dump करा. पूर्ण list ruleset dump मध्ये ufw आणि Docker स्वतः व्यवस्थापित करत असलेले tables देखील येतात.