Ubuntu पर iptables vs nftables: क्या अंतर है?

Ubuntu पर iptables बनाम nftables: आपका सर्वर किसका उपयोग कर रहा है?

Ubuntu 20.04 और उसके बाद के वर्ज़न में, iptables कमांड एक फ्रंट-एंड है जो nftables रूल्स लिखता है। कर्नल में केवल एक पैकेट फिल्टर चलता है, जो कि nftables है, और दो यूजर-स्पेस कमांड इसे प्रोग्राम करते हैं। एक iptables -A INPUT लाइन अभी भी बिल्कुल वैसे ही काम करती है जैसे पहले करती थी, और इसके द्वारा बनाया गया रूल एक nftables रूल होता है जिसे nft प्रिंट कर सकता है।

किसी भी बात पर विश्वास करने से पहले अपने सर्वर पर इसकी पुष्टि करें।

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) प्रिंट करता है। ब्रैकेट में दिया गया नाम बैक-एंड है। (nf_tables) का अर्थ है कि कमांड nftables से बात कर रही है। (legacy) का अर्थ है पुराना x_tables बैक-एंड, जिसे Ubuntu अभी भी iptables-legacy के रूप में शिप करता है और जिसे कर्नल एक पूरी तरह से अलग रूल्सेट के रूप में रखता है। update-alternatives उस विकल्प के पीछे के सिमलिंक (symlink) को प्रिंट करता है: link currently points to /usr/sbin/iptables-nft।

बिना किसी फायरवॉल कॉन्फ़िगरेशन वाले एक नए VPS पर, sudo nft list ruleset कुछ भी प्रिंट नहीं करता है। यह खाली आउटपुट आपका बेसलाइन है। पुराने तरीके से एक रूल जोड़ें और फिर से देखें।

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 के साथ एडिट करने से दो टूल्स एक ही रूल्स के प्रभारी हो जाते हैं। देखें कि एक कमांड ने क्या उत्पन्न किया: एक ऐसी टेबल जिसे आपने नाम नहीं दिया, और ऐसी चेन्स जिन्हें आपने नहीं मांगा था। यह पुराना मॉडल है, और nftables को सीधे लिखते समय यह सबसे पहली चीज है जो बदल जाती है।

iptables -L आपसे क्या छिपाता है

iptables -L केवल filter टेबल दिखाता है। NAT (network address translation) नियमों के लिए iptables -t nat -L की आवश्यकता होती है, और mangle नियमों के लिए -t mangle की। IPv6 एक अलग कमांड, ip6tables में रहता है, जिसमें हर नियम की अपनी कॉपी होती है। इसलिए, एक बॉक्स एक लिस्टिंग में साफ दिख सकता है, जबकि कोई ऐसी टेबल से आपके पैकेट ड्रॉप या रीराइट कर रही हो जिसे आपने कभी चेक ही नहीं किया।

sudo nft list ruleset एक ही आउटपुट में हर फैमिली, हर टेबल, हर चेन और हर नियम को प्रिंट करता है। जिस सर्वर को आपने खुद सेटअप नहीं किया है, उस पर यह कमांड यह देखने का सबसे तेज़ तरीका है कि वास्तव में क्या लोड है। नियम हैंडल प्रिंट करने के लिए -a जोड़ें, जिसकी आवश्यकता आपको पूरी चेन के बजाय एक नियम को डिलीट करने के लिए पड़ती है।

यहाँ रहते हुए दो आदतें सुधारना फायदेमंद है। iptables -nvL का उपयोग करें, क्योंकि iptables -L एड्रेस और पोर्ट्स को नामों में रिजॉल्व करता है, जिससे खराब रिजॉल्वर वाले बॉक्स पर ऐसा लग सकता है कि सिस्टम हैंग हो गया है। और यह सुनिश्चित करें कि लेगेसी बैक एंड खाली है, इसके लिए sudo iptables-legacy -nvL का उपयोग करें। यदि दोनों बैक एंड में नियम मौजूद हैं, तो कर्नेल दोनों का मूल्यांकन करता है, और कोई भी लिस्टिंग आपको पूरी स्थिति नहीं दिखाती है।

ऐसी टेबल्स और चेन्स जिन्हें आप बनाते हैं, न कि जो विरासत में मिलती हैं

nftables खाली शुरू होता है। जब तक आप कोई टेबल नहीं बनाते, तब तक कोई filter टेबल नहीं होती, और filter शब्द केवल आपके द्वारा चुना गया एक नाम है। एक चेन पैकेट को तभी देखती है जब आप उसे एक टाइप, एक हुक और एक प्रायोरिटी देते हैं, जो उसे एक बेस चेन बनाता है। बिना इनके, एक चेन तक केवल एक स्पष्ट jump या goto के माध्यम से ही पहुँचा जा सकता है, इसलिए जब तक कोई उस पर जंप नहीं करता, तब तक उसका कोई प्रभाव नहीं पड़ता।

दूसरा बड़ा बदलाव inet फैमिली है। एक inet टेबल IPv4 और IPv6 दोनों को एक ही रूल्स में संभालती है, जिससे बग्स की एक पूरी श्रेणी खत्म हो जाती है जहाँ एक पोर्ट iptables में बंद होता है और ip6tables में पूरी तरह खुला रहता है। यह विसंगति इतनी आम है कि ufw बॉक्स पर इसका अपना फेल्योर मोड होता है।

यहाँ एक पूर्ण सर्वर रूल्सet दिया गया है। यह /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 द्वारा स्वयं के लिए बनाई गई टेबल्स भी शामिल हैं। इसे लाइव सर्वर पर चलाने से पहले पढ़ना जारी रखें।

इनपुट चेन का पहला नियम अधिकांश काम करता है। 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 लंबी rule सूचियों की जगह लेते हैं

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 को फिर से number देने की। चाहे set में पाँच address हों या पचास हजार, match हमेशा एक ही lookup रहता है। flags interval वह flag है जो set को ranges और CIDR (classless inter-domain routing) prefixes जैसे 198.51.100.0/24 को रखने की अनुमति देता है। इस flag के बिना set केवल single addresses ही ले सकता है, और prefix load करने पर error आ जाएगा।

Sets अपने elements को expire भी कर सकते हैं।

set banned {
  type ipv4_addr
  flags timeout
  timeout 1h
}

ip saddr @banned drop rule के साथ, हर element जुड़ने के एक घंटे बाद खुद ही हट जाता है। इसी तरह Ubuntu 24.04 पर fail2ban में nftables action किसी address को ban करता है: यह set में एक element जोड़ता है, न कि कोई rule। यदि ports आपके लिए नया विषय हैं, तो Linux पर port वास्तव में क्या है से शुरुआत करें।

migration के दौरान एक अंतर लोगों को उलझा देता है। nftables तब तक packets को count नहीं करता जब तक आप ऐसा करने के लिए न कहें। iptables -nvL हमेशा हर rule के लिए counters दिखाता है। nftables में केवल उन्हीं rules में numbers होते हैं जिनमें counter keyword होता है, इसलिए जिस rule को आप बाद में debug करना चाहते हैं, उसमें counter जरूर लगाएँ।

हुक और प्राथमिकताएं यह कैसे तय करती हैं कि क्रम क्या होगा

एक बेस चेन एक हुक का नाम बताती है, जो पैकेट पाथ में वह बिंदु है जहाँ यह रन होती है। prerouting राउटिंग निर्णय से पहले रन होता है। input इस मशीन के लिए संबोधित पैकेटों के लिए रन होता है। forward इसके माध्यम से राउट किए गए पैकेटों के लिए रन होता है। output स्थानीय प्रक्रियाओं से आने वाले पैकेटों के लिए रन होता है। postrouting सबसे अंत में, पैकेट के बाहर निकलने से ठीक पहले रन होता है।

प्राथमिकता एक हुक के भीतर चेन को क्रमबद्ध करती है, जिसमें सबसे छोटी संख्या पहले आती है। nftables क्लासिक मानों को नाम देता है: raw का मान -300 है, mangle का मान -150 है, dstnat का मान -100 है, filter का मान 0 है, srcnat का मान 100 है। priority filter; लिखना priority 0; लिखने के समान ही है।

अब वह हिस्सा जो यह तय करता है कि क्या अलग-अलग टूल्स को मिलाना काम करेगा। एक हुक पर रजिस्टर्ड हर बेस चेन प्राथमिकता के क्रम में रन होती है। आपकी चेन में स्वीकार किया गया पैकेट अभी समाप्त नहीं हुआ है: accept केवल उस चेन को समाप्त करता है, और पैकेट उसी हुक पर अगली बेस चेन तक जारी रहता है। drop हर जगह अंतिम है और पैकेट को तुरंत रोक देता है। इसलिए आपकी टेबल का एक अनुमति देने वाला नियम ufw की टेबल में किए गए ड्रॉप को पूर्ववत नहीं कर सकता, चाहे कोई भी पहले रन हो, और आपका accept आपको बाद में रन होने वाली चेन से कोई सुरक्षा नहीं देता है।

एक ही हुक पर समान प्राथमिकता वाली दो बेस चेन रजिस्ट्रेशन के क्रम में रन होती हैं, जो इस बात पर निर्भर करता है कि कौन सी सर्विस पहले स्टार्ट हुई। वह क्रम रीबूट के बाद बदल सकता है। यदि आपको ufw के साथ अपनी टेबल रन करनी ही है, तो इसे एक अलग प्राथमिकता दें ताकि क्रम पहले से निर्धारित हो, न कि रेस कंडीशन पर निर्भर।

रिवर्स NAT नियम लिखने की आवश्यकता क्यों नहीं है?

यह वह प्रश्न है जिसे लोग सबसे अधिक गलत समझते हैं, इसलिए यहाँ इसका सीधा उत्तर दिया गया है। Connection tracking आपके लिए रिवर्स ट्रांसलेशन (reverse translation) लिख देता है। इसमें कोई दूसरा नियम जोड़ने की आवश्यकता नहीं होती है।

एक nat table जो सामान्य VPS कार्य के दोनों हिस्सों को पूरा करती है, वह कुछ इस तरह दिखती है:

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
  }
}

किसी कनेक्शन के केवल पहले पैकेट का मूल्यांकन nat chain के विरुद्ध किया जाता है। जब कोई नियम मेल खाता है, तो kernel उस ट्रांसलेशन को connection tracking table में कनेक्शन की प्रविष्टि (entry) के साथ संग्रहीत कर लेता है। बाद के प्रत्येक पैकेट को, दोनों दिशाओं में, संग्रहीत प्रविष्टि से फिर से लिखा (rewrite) जाता है, और किसी भी नियम को दोबारा नहीं पढ़ा जाता है। conntrack टूल इंस्टॉल करें और एक लाइव प्रविष्टि देखें।

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) के रूप में पढ़ें। पहले चार फ़ील्ड वह कनेक्शन हैं जैसा कि क्लाइंट ने इसे भेजा था, जिसे 203.0.113.10:8080, यानी आपके सार्वजनिक पते पर संबोधित किया गया था। दूसरे चार वह उत्तर (reply) हैं जिसकी kernel अपेक्षा करता है, जो पहले से ही रिवर्स और ट्रांसलेट हो चुका है, और 10.0.0.5:80, यानी वास्तविक backend से आ रहा है। वह दूसरा टुपल ही रिवर्स नियम है। जब पहला पैकेट मेल खाया था, तब kernel ने इसे लिखा था।

इसलिए वापसी की दिशा (return direction) के लिए कोई नियम न लिखें। यह मेल नहीं खा सकता, क्योंकि वापसी वाले पैकेट एक स्थापित कनेक्शन का हिस्सा होते हैं और कभी भी nat chain तक नहीं पहुँचते हैं। यदि यह किसी तरह मेल खा भी जाता है, तो आप उस पैकेट को फिर से ट्रांसलेट कर देंगे जिसे kernel पहले ही ठीक कर चुका है।

Rewrite कहाँ होना चाहिए, यह भी उसी तंत्र से तय होता है। Destination translation को prerouting में, routing निर्णय से पहले चलना चाहिए, क्योंकि routing को नया destination देखना आवश्यक है, अन्यथा पैकेट गलत जगह चला जाएगा। स्वयं बॉक्स द्वारा उत्पन्न ट्रैफ़िक को भी इसी कारण से output हुक में संभाला जाता है। Source translation, जिसमें source port का rewrite भी शामिल है, को postrouting में, routing द्वारा आउटगोइंग इंटरफ़ेस चुनने के बाद चलना चाहिए। masquerade अपना पता उस इंटरफ़ेस से लेता है, और जब तक routing नहीं हो जाती, तब तक इंटरफ़ेस ज्ञात नहीं होता है।

यही कारण है कि इस तरह का नियम पथ के अंत में ही होना चाहिए और कहीं नहीं।

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 करती है, जो तब आवश्यक होता है जब कई आंतरिक क्लाइंट एक ही सार्वजनिक पते को साझा करते हैं और उनके source ports आपस में टकराते हैं। उस रेंज में संबोधित एक उत्तर (reply) आता है, conntrack इसे प्रविष्टि से मिलाता है, और पैकेट डिलीवर होने से पहले मूल source port को वापस रख दिया जाता है। फिर से, कोई दूसरा नियम नहीं।

एक व्यावहारिक परिणाम यह है: NAT नियम बदलने से पहले से मौजूद कनेक्शन प्रभावित नहीं होते, क्योंकि उनका ट्रांसलेशन पहले ही संग्रहीत हो चुका होता है। वे तब तक पुराने व्यवहार को बनाए रखते हैं जब तक कि उनकी प्रविष्टियाँ समाप्त (expire) नहीं हो जातीं। sudo conntrack -D -p tcp --dport 8080 मेल खाने वाली प्रविष्टियों को हटा देता है और sudo conntrack -F उन सभी को हटा देता है। NAT बॉक्स पर दूसरे वाले का उपयोग सावधानी से करें, क्योंकि वे संग्रहीत ट्रांसलेशन ही वर्तमान कनेक्शनों को जीवित रखते हैं, इसलिए उन्हें हटाने से बॉक्स से होकर जाने वाले सभी कनेक्शन एक साथ टूट जाएंगे।

ufw और Docker दोनों अपने नियम स्वयं लिखते हैं

ufw, iptables का एक फ्रंट-एंड है, जो Ubuntu पर nftables का फ्रंट-एंड है। इसलिए एक ufw बॉक्स में ufw-before-input, ufw-user-input आदि नामों की चेन से भरी एक ip filter टेबल होती है, साथ ही उसी संरचना की एक ip6 filter कॉपी भी होती है। sudo nft list ruleset | grep ufw के साथ इसकी जाँच करें। वे चेन /etc/ufw की फाइलों से उत्पन्न होती हैं, और ufw reload उन्हें शुरू से फिर से लिखता है, यही कारण है कि ऊपर से जोड़ा गया हाथ से लिखा हुआ iptables नियम अगले रीलोड पर गायब हो जाता है। VPS के लिए ufw की बुनियादी बातें उस फाइल लेआउट को कवर करती हैं।

Docker स्वयं फायरवॉल को प्रोग्राम करता है और ufw से परामर्श नहीं करता है। -p 80:80 के साथ पोर्ट पब्लिश करने पर nat टेबल में एक DNAT नियम लिखा जाता है और फॉरवर्ड पाथ में एक एक्सेप्ट नियम जुड़ जाता है, और ये दोनों ufw की यूजर चेन से पहले चलते हैं। इसका परिणाम सबको एक बार हैरान कर देता है: ufw deny 80 लोड हो जाता है, और कंटेनर अभी भी इंटरनेट से एक्सेस किया जा सकता है। इसका समाधान DOCKER-USER चेन में है जिसे Docker आपके नियमों के लिए छोड़ देता है, और Docker कंटेनर ufw को क्यों अनदेखा करते हैं में इसे विस्तार से समझाया गया है। sudo nft list ruleset | grep -i docker के साथ देखें कि आपके बॉक्स पर क्या चल रहा है।

अब ऊपर दिए गए कॉन्फ़िगरेशन से उस flush ruleset लाइन को फिर से पढ़ें। यह हर टेबल को डिलीट कर देता है, जिसमें वे टेबल भी शामिल हैं जिन्हें ये दोनों टूल्स मैनेज करते हैं। Docker होस्ट पर, पब्लिश किए गए पोर्ट तब तक काम करना बंद कर देते हैं जब तक कि sudo systemctl restart docker चेन को फिर से न बना ले। फायरवॉल को साफ करते समय यह एक लाइन सबसे आम तरीका है जिससे लोग अपनी खुद की सेवाओं को ऑफलाइन कर लेते हैं।

Reboot के बाद भी बने रहने वाले rules

दोनों में से कोई भी 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

दोनों को एक साथ न चलाएं। दो files जो दोनों ही firewall को संभालने का दावा करती हैं, उनमें अंतर आ जाएगा, और जो अंत में load होगी वह प्रभावी होगी, जिसे किसी भी file को पढ़कर पहले से नहीं बताया जा सकता।

Live ruleset को dump करने में एक संबंधित खतरा है। sudo nft -s list ruleset > /etc/nftables.conf उस समय load किए गए हर नियम को capture कर लेता है, जिसमें ufw की tables और Docker की tables भी शामिल हैं। यदि आप इसे boot के समय restore करते हैं, तो आपको उन rules की एक frozen copy मिल जाएगी जिन्हें ये tools खुद बनाने की उम्मीद करते हैं, और फिर उनके start होने पर एक दूसरी copy बन जाएगी। केवल अपनी table को dump करें, sudo nft -s list table inet filter का उपयोग करके। -s flag counters को हटा देता है, जिनकी config file में कोई आवश्यकता नहीं होती।

क्या आपको अपने VPS पर firewall चालू करना चाहिए?

जब तक आपको ऐसी किसी चीज़ की आवश्यकता न हो जिसे ufw व्यक्त न कर सके, तब तक उसे न छेड़ें। ufw एक सामान्य VPS के काम को कवर करता है: डिफ़ॉल्ट रूप से सभी को अस्वीकार करना और कुछ चुनिंदा ports को खुला रखना। केवल दिखावे के लिए इसे हाथ से लिखे गए ruleset से बदलना आपको वही firewall देता है, लेकिन साथ ही रखरखाव का एक अतिरिक्त बोझ भी।

जब आपकी आवश्यकता ufw के मॉडल से बाहर हो, तब native tools का उपयोग करें: जैसे NAT और port forwarding, runtime पर अपडेट होने वाले sets, एक ही rule जो दोनों address families को कवर करे, या chain की प्राथमिकताएं जिन्हें आप स्वयं चुनते हैं। ये वास्तविक कारण हैं, और ufw में इनमें से किसी को भी लागू करने का कोई तरीका नहीं है।

यदि आप native tools का उपयोग करते हैं, तो पूरी तरह से करें। sudo ufw disable और sudo systemctl disable --now ufw चलाएं, sudo nft list ruleset के साथ पुष्टि करें कि इसकी tables हट गई हैं, और फिर अपनी खुद की file लोड करें। एक ऐसा सर्वर जो ufw और हाथ से लिखी गई table दोनों को एक साथ चलाता है, वह traffic तो पास करेगा, लेकिन वर्तमान policy दो rulesets का योग होगी। इनका मूल्यांकन service startup द्वारा निर्धारित क्रम में होता है, और किसी भी file को पढ़ने वाला व्यक्ति यह नहीं बता पाएगा कि सर्वर वास्तव में क्या कर रहा है।

मौजूदा iptables ruleset को माइग्रेट करना

iptables-translate एक नियम को convert करता है और उसका nftables प्रारूप प्रिंट करता है। यह सर्वर पर कोई बदलाव नहीं करता है।

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 पूरे सहेजे गए ruleset के लिए यही काम करता है। इसके आउटपुट को पहला ड्राफ्ट मानें। यह conversion यांत्रिक है और नियम-दर-नियम होता है, इसलिए आपको पुराने table और chain के नाम वापस मिलते हैं, IPv4 और IPv6 के लिए दो अलग-अलग rulesets मिलते हैं, और वे sets नहीं मिलते जिनके कारण यह बदलाव करना सार्थक होता है। इसे हाथ से एक inet table के रूप में फिर से लिखें, और फिर इसे live सर्वर पर लागू करने से पहले nft -c -f से जाँचें।

इन उदाहरणों में दिए गए पते documentation ranges 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 है?

यह command हट नहीं रही है और यह Ubuntu 24.04 पर भी काम करती है। जो बदलाव हुआ है वह इसके बैकएंड में है: iptables एक फ्रंट-एंड है जो iptables-nft बैकएंड के माध्यम से nftables नियम लिखता है। अपने सिस्टम की जाँच iptables -V से करें, जो 24.04 पर iptables v1.8.10 (nf_tables) प्रिंट करता है। पुराना x_tables बैकएंड अभी भी iptables-legacy के रूप में उपलब्ध है, और इसमें पूरी तरह से अलग नियम सेट होते हैं, इसलिए नियमों को केवल एक ही बैकएंड में रखें, दोनों में नहीं।

क्या मुझे वापसी के रास्ते पर NAT को हटाने के लिए दूसरे नियम की आवश्यकता है?

नहीं। Connection tracking अनुवाद को तब स्टोर कर लेती है जब किसी कनेक्शन का पहला पैकेट nat नियम से मेल खाता है, और दोनों दिशाओं में बाद के हर पैकेट को उस स्टोर्ड एंट्री से फिर से लिखा जाता है। sudo conntrack -L इसे प्रति कनेक्शन दो टुपल्स के रूप में दिखाता है: मूल दिशा, और फिर पहले से रिवर्स किया गया उत्तर। वापसी की दिशा के लिए लिखा गया नियम मदद नहीं कर सकता, क्योंकि वापसी वाले पैकेट कभी भी nat चेन तक नहीं पहुँचते।

क्या मैं ufw और अपने स्वयं के nftables नियमों को एक साथ चला सकता हूँ?

यह काम करता है, लेकिन आप समस्या को न्योता दे रहे हैं। हुक पर हर बेस चेन चलती है, इसलिए लाइव पॉलिसी दोनों नियम सेटों का संयोजन होती है, जो प्राथमिकता के आधार पर और, समान प्राथमिकता होने पर, उस सेवा के आधार पर क्रमबद्ध होती है जो पहले शुरू हुई थी। किसी भी एक में drop अंतिम होता है, और आपके नियमों में accept दूसरे को उसी पैकेट को ड्रॉप करने से नहीं रोकता है। किसी एक टूल को चुनें। यदि वह nftables है, तो पहले ufw को डिसेबल करें और सुनिश्चित करें कि इसकी टेबल sudo nft list ruleset से हट गई हैं।

मैं Ubuntu पर nftables नियमों को रीबूट के बाद कैसे सुरक्षित रखूँ?

नियम सेट को /etc/nftables.conf में रखें, इसे sudo nft -c -f /etc/nftables.conf से जाँचें, और फिर sudo systemctl enable --now nftables चलाएँ। यह सेवा डिफ़ॉल्ट रूप से इनेबल नहीं होती है, इसलिए systemctl is-enabled nftables को एक बार चलाना उचित है। जब आप वह फ़ाइल जनरेट करें, तो केवल अपनी टेबल को sudo nft -s list table inet filter के साथ डंप करें, क्योंकि पूर्ण list ruleset डंप उन टेबल्स को भी कैप्चर कर लेता है जिन्हें ufw और Docker स्वयं मैनेज करते हैं।