Ubuntu میں iptables بمقابلہ nftables: اصل میں کیا چلتا ہے؟

Ubuntu میں iptables بمقابلہ nftables: آپ کا box کون سا چلا رہا ہے؟

Ubuntu 20.04 اور اس کے بعد کے ورژنز میں iptables کمانڈ ایک front end ہے جو nftables کے rules لکھتا ہے۔ kernel میں ایک ہی packet filter، nftables، چلتا ہے، اور user space کی دو کمانڈز اسے program کرتی ہیں۔ iptables -A INPUT کی سطر اب بھی بالکل پہلے کی طرح کام کرتی ہے، اور اس کے بنائے ہوئے rule کو nft پرنٹ کر سکتا ہے۔

اس پر یقین کرنے سے پہلے اپنے 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) پرنٹ کرتا ہے۔ brackets میں دیا گیا نام backend ہے۔ (nf_tables) کا مطلب ہے کہ کمانڈ nftables سے بات کرتی ہے۔ (legacy) کا مطلب پرانا x_tables backend ہے، جسے Ubuntu اب بھی iptables-legacy کے طور پر ship کرتا ہے اور جسے kernel مکمل طور پر الگ ruleset کے طور پر برقرار رکھتا ہے۔ update-alternatives اس انتخاب کے پیچھے موجود symbolic link پرنٹ کرتا ہے: link currently points to /usr/sbin/iptables-nft۔

ایسے نئے VPS پر جہاں کوئی firewall configure نہ ہو، sudo nft list ruleset کچھ بھی پرنٹ نہیں کرتا۔ یہ خالی output آپ کا baseline ہے۔ پرانے طریقے سے ایک rule شامل کریں اور دوبارہ دیکھیں۔

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 rule دراصل nftables rule ہے۔ iptables-nft اپنے بنائے ہوئے tables کو mark کرتا ہے، اور nft یہ warning اس وقت پرنٹ کرتا ہے جب اسے وہ mark نظر آتا ہے، کیونکہ ایسے table میں nft سے ترمیم کرنے پر ایک ہی rules کو دو tools manage کرتے ہیں۔ دیکھیں کہ ایک کمانڈ نے کیا بنایا: ایک ایسا table جس کا نام آپ نے نہیں دیا، اور ایسی chains جن کا آپ نے مطالبہ نہیں کیا۔ یہی پرانا model ہے، اور جب آپ براہ راست nftables لکھتے ہیں تو سب سے پہلے یہی چیز تبدیل ہوتی ہے۔

آپ سے iptables -L کیا چھپاتا ہے

iptables -L صرف filter table دکھاتا ہے۔ NAT (network address translation) rules کے لیے iptables -t nat -L درکار ہے، جبکہ mangle rules کے لیے -t mangle درکار ہے۔ IPv6 ایک الگ command، ip6tables، میں موجود ہوتا ہے اور اس میں ہر rule کی اپنی copy ہوتی ہے۔ اس لیے ایک box ایک listing میں صاف نظر آ سکتا ہے، جبکہ کوئی ایسی table آپ کے packets کو drop یا rewrite کر رہی ہو جسے آپ نے کبھی check ہی نہ کیا ہو۔

sudo nft list ruleset ہر family، ہر table، ہر chain اور ہر rule کو ایک ہی output میں دکھاتا ہے۔ ایسے server پر جسے آپ نے خود build نہ کیا ہو، یہ single command حقیقی طور پر loaded configuration دیکھنے کا تیز ترین طریقہ ہے۔ Rule handles دکھانے کے لیے -a شامل کریں۔ کسی ایک rule کو delete کرنے کے لیے یہ handles درکار ہوتے ہیں، پوری chain کو نہیں۔

یہاں دو عادتیں بھی درست کر لیں۔ iptables -L addresses اور ports کو names میں resolve کرتا ہے، اس لیے خراب resolver والے box پر ایسا لگتا ہے کہ command hang ہو گئی ہے: iptables -nvL استعمال کریں۔ اس کے علاوہ sudo iptables-legacy -nvL سے تصدیق کریں کہ legacy back end خالی ہے، کیونکہ اگر دونوں back ends میں rules موجود ہوں تو kernel دونوں کا جائزہ لیتا ہے، اور کوئی بھی listing مکمل صورتِ حال نہیں دکھاتی۔

آپ کی بنائی ہوئی tables اور chains، inherited نہیں

nftables ابتدا میں خالی ہوتا ہے۔ جب تک آپ table نہ بنائیں، کوئی filter table موجود نہیں ہوتا، اور filter صرف آپ کا منتخب کیا ہوا نام ہے۔ کسی chain کو packets اسی وقت ملتے ہیں جب آپ اسے type، hook اور priority دیں؛ اس طرح وہ base chain بن جاتی ہے۔ ان خصوصیات کے بغیر chain تک صرف واضح jump یا goto کے ذریعے پہنچا جا سکتا ہے، اس لیے جب تک کوئی rule اس پر jump نہ کرے، اس کی کوئی لاگت نہیں ہوتی۔

دوسری بڑی تبدیلی inet family ہے۔ ایک inet table میں IPv4 اور IPv6 کے لیے ایک ہی rules استعمال کیے جا سکتے ہیں۔ اس سے اس قسم کے bugs ختم ہوتے ہیں جن میں کوئی port iptables میں بند ہوتا ہے، لیکن ip6tables میں مکمل طور پر کھلا رہ جاتا ہے۔ یہ عدم مطابقت اتنی عام ہے کہ 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 server پر موجود ہر table delete کرتا ہے، جن میں وہ tables بھی شامل ہیں جو ufw اور Docker نے اپنے لیے بنائی ہیں۔ Live server پر اسے چلانے سے پہلے باقی ہدایات بھی پڑھیں۔

input chain کا پہلا rule زیادہ تر کام کرتا ہے۔ ct state established,related accept ان connections کے replies کو واپس آنے دیتا ہے جو آپ نے شروع کیے تھے، اس لیے باقی chain کو صرف نئی connections کے بارے میں فیصلہ کرنا ہوتا ہے۔ ct state invalid drop ایسے packets کو discard کرتا ہے جو کسی معلوم connection یا valid start سے match نہ ہوں۔ اس کے بعد موجود ہر rule ایک explicit hole ہے، اور policy drop باقی traffic کو handle کرتا ہے۔

File کو load کرنے سے پہلے اسے check کریں، اور اس دوران دوسری 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 کرتا ہے اور errors report کرتا ہے، مگر کچھ load نہیں کرتا۔ درست 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 کی ضرورت ہے، نہ rules کی renumbering، اور match ایک ہی lookup رہتا ہے، چاہے set میں پانچ addresses ہوں یا پچاس ہزار۔ flags interval کی مدد سے set میں ranges اور CIDR (classless inter-domain routing) prefixes، جیسے 198.51.100.0/24، شامل کیے جا سکتے ہیں۔ اس flag کے بغیر set صرف single addresses قبول کرتا ہے، اور prefix load نہیں ہوتا۔

Sets اپنے elements کو خود expire بھی کر سکتے ہیں۔

set banned {
  type ipv4_addr
  flags timeout
  timeout 1h
}

ip saddr @banned drop والے rule کے ساتھ ہر element شامل کیے جانے کے ایک گھنٹے بعد خود remove ہو جاتا ہے۔ اسی طریقے سے Ubuntu 24.04 پر fail2ban کا nftables action کسی address کو ban کرتا ہے: یہ set میں ایک element شامل کرتا ہے، rule شامل نہیں کرتا۔ اگر ports کا تصور نیا ہے تو Linux میں port کی اصل نوعیت سے شروع کریں۔

Migration کے دوران ایک فرق اکثر مسئلہ بنتا ہے۔ nftables packets کو شمار نہیں کرتا، جب تک آپ اسے ایسا کرنے کے لیے نہ کہیں۔ iptables -nvL ہر rule کے لیے counters ہمیشہ دکھاتا ہے۔ nftables میں صرف counter keyword رکھنے والے rules کے numbers ہوتے ہیں، اس لیے ہر اس rule میں counter شامل کریں جسے بعد میں debug کرنے کی توقع ہو۔

ہُکس اور ترجیحات ترتیب کا فیصلہ کیسے کرتی ہیں

ایک base chain میں hook کا نام دیا جاتا ہے۔ یہ packet path میں وہ مقام ہے جہاں chain چلتی ہے۔ prerouting routing decision سے پہلے چلتا ہے۔ input اس مشین کے لیے addressed packets پر چلتا ہے۔ forward اس مشین سے routed packets پر چلتا ہے۔ output local processes سے آنے والے packets پر چلتا ہے۔ postrouting آخر میں، packet کے روانہ ہونے سے فوراً پہلے چلتا ہے۔

Priority ایک ہی hook کے اندر chains کی ترتیب طے کرتی ہے۔ سب سے کم number پہلے آتا ہے۔ nftables کلاسیکی values کے لیے نام فراہم کرتا ہے: raw کی value -300 ہے، mangle کی -150، dstnat کی -100، filter کی 0، اور srcnat کی 100 ہے۔ priority filter; لکھنا، priority 0; لکھنے کے برابر ہے۔

اب وہ حصہ جو یہ طے کرتا ہے کہ tools کو ملا کر استعمال کرنا کام کرے گا یا نہیں۔ کسی hook پر registered ہر base chain priority order میں چلتی ہے۔ آپ کی chain میں packet کو accept کرنا عمل کا اختتام نہیں ہوتا: accept صرف اسی chain کو ختم کرتا ہے، اور packet اسی hook پر موجود اگلی base chain تک پہنچتا رہتا ہے۔ drop ہر جگہ final ہے اور packet کو فوراً روک دیتا ہے۔ اس لیے آپ کی table میں موجود permissive rule، ufw کی table میں موجود drop کو ختم نہیں کر سکتا، چاہے پہلے کوئی بھی چلے، اور آپ کا accept بعد میں چلنے والی chain سے کوئی تحفظ فراہم نہیں کرتا۔

ایک ہی hook پر یکساں priority رکھنے والی دو base chains registration order میں چلتی ہیں۔ یہ order اس بات پر منحصر ہوتا ہے کہ کون سی service پہلے start ہوئی۔ reboot کے بعد یہ order تبدیل ہو سکتا ہے۔ اگر آپ کو ufw کے ساتھ اپنی table چلانی ضروری ہو تو اسے distinct priority دیں، تاکہ order پہلے سے درج ہو اور اس کے لیے race نہ ہو۔

ریورس NAT rule لکھنے کی ضرورت کیوں نہیں؟

یہ وہ سوال ہے جس کا لوگ اکثر غلط جواب دیتے ہیں، اس لیے براہِ راست جواب یہ ہے: connection tracking آپ کے لیے reverse translation لکھتا ہے۔ دوسری rule شامل کرنے کی ضرورت نہیں ہوتی۔

معمول کے 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 کے خلاف جانچا جاتا ہے۔ جب کوئی rule match ہوتی ہے تو kernel اس translation کو connection tracking table میں connection کے entry کے ساتھ محفوظ کر لیتا ہے۔ دونوں سمتوں میں آنے والے ہر بعد کے packet کو محفوظ شدہ entry کی بنیاد پر rewrite کیا جاتا ہے، اور rules دوبارہ نہیں پڑھی جاتیں۔ `conntrack` tool انسٹال کریں اور 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 وہ connection ہیں جو client نے `203.0.113.10:8080، یعنی آپ کے public address، کی طرف بھیجا تھا۔ اگلے چار fields وہ reply ہیں جس کی kernel توقع رکھتا ہے۔ یہ reply پہلے ہی الٹی سمت اور translated حالت میں ہے اور 10.0.0.5:80`، یعنی حقیقی backend، سے آتا ہے۔ یہ دوسرا tuple ہی reverse rule ہے۔ پہلے packet کے match ہونے پر kernel نے اسے لکھا تھا۔

اس لیے return direction کے لیے rule نہ لکھیں۔ وہ match نہیں کر سکتی، کیونکہ return packets established connection سے متعلق ہوتے ہیں اور کبھی nat chain تک نہیں پہنچتے۔ اگر وہ کسی طرح match ہو بھی جائیں تو آپ ایسے packet کو دوبارہ translate کریں گے جسے kernel پہلے ہی درست کر چکا ہے۔

Rewrite کہاں ہونی چاہیے، یہ بھی اسی mechanism سے واضح ہوتا ہے۔ Destination translation کو `prerouting میں، routing decision سے پہلے، چلنا چاہیے، کیونکہ routing کو نیا destination نظر آنا ضروری ہے۔ ورنہ packet غلط جگہ چلا جائے گا۔ Box کی اپنی پیدا کردہ traffic کو اسی وجہ سے output hook میں handle کیا جاتا ہے۔ Source translation، جس میں source port rewrite بھی شامل ہے، postrouting میں، routing کے بعد، چلنی چاہیے کیونکہ routing نے اسی وقت outgoing interface منتخب کیا ہوتا ہے۔ masquerade` اپنا address اسی interface سے لیتا ہے، اور routing مکمل ہونے تک interface معلوم نہیں ہوتا۔

اسی لیے اس جیسی rule 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 share کرتے ہوں اور ان کے source ports آپس میں ٹکرا جائیں تو یہی مطلوبہ عمل ہے۔ Reply اس range کے کسی port پر addressed ہو کر آتا ہے، conntrack اسے entry سے match کرتا ہے، اور packet deliver ہونے سے پہلے original source port بحال کر دیا جاتا ہے۔ ایک بار پھر، دوسری rule کی ضرورت نہیں ہوتی۔

اس کا ایک عملی نتیجہ یہ ہے کہ NAT rule تبدیل کرنے سے پہلے سے موجود connections منتقل نہیں ہوتے، کیونکہ ان کی translation پہلے ہی محفوظ ہو چکی ہوتی ہے۔ Entries expire ہونے تک وہ پرانا behavior برقرار رکھتے ہیں۔ `sudo conntrack -D -p tcp --dport 8080 matching entries حذف کرتا ہے، جبکہ sudo conntrack -F` تمام entries حذف کرتا ہے۔ NAT box پر دوسرے command کو احتیاط سے استعمال کریں، کیونکہ یہی محفوظ شدہ 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 شامل ہوتی ہیں، اور اسی structure کی ایک ip6 filter copy بھی موجود ہوتی ہے۔ sudo nft list ruleset | grep ufw سے اسے دیکھیں۔ یہ chains /etc/ufw میں موجود files سے generate ہوتی ہیں، اور ufw reload انہیں شروع سے دوبارہ لکھتا ہے۔ اسی وجہ سے اوپر ہاتھ سے شامل کیا گیا 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 سے پہلے run ہوتے ہیں۔ نتیجہ پہلی بار سب کو حیران کرتا ہے: ufw deny 80 load ہونے کے باوجود container internet سے قابل رسائی رہتا ہے۔ اس کا حل DOCKER-USER chain میں ہے، جسے Docker آپ کے rules کے لیے چھوڑتا ہے، اور Docker containers ufw کو کیوں نظرانداز کرتے ہیں اس عمل کی وضاحت کرتی ہے۔ sudo nft list ruleset | grep -i docker سے اپنے سرور پر موجود rules دیکھیں۔

اب اوپر دی گئی configuration کی flush ruleset line دوبارہ پڑھیں۔ یہ ہر table کو delete کرتی ہے، بشمول ان tables کے جنہیں یہ دونوں tools manage کرتے ہیں۔ Docker host پر published ports اس وقت تک کام نہیں کرتے جب تک sudo systemctl restart docker chains کو دوبارہ build نہ کرے۔ firewall صاف کرتے وقت اپنی services کو offline کرنے کی سب سے عام وجہ یہی ایک line ہے۔

ریبوٹ کے بعد برقرار رہنے والے قواعد

کوئی بھی 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 انسٹال کرتا ہے اور قواعد کو /etc/iptables/rules.v4 اور /etc/iptables/rules.v6 میں محفوظ کرتا ہے۔

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

دونوں کو نہ چلائیں۔ دو files بیک وقت firewall رکھنے کا دعویٰ کریں گی تو ان کے قواعد مختلف ہو جائیں گے، اور آخر میں load ہونے والی file غالب آ جائے گی۔ یہ بات دونوں files پڑھ کر قابلِ پیش گوئی نہیں ہوگی۔

Live ruleset کو dump کرنے میں بھی ایک متعلقہ مسئلہ ہے۔ sudo nft -s list ruleset > /etc/nftables.conf اس وقت load کیا گیا مکمل ruleset محفوظ کرتا ہے، جس میں ufw کی tables اور Docker کی tables بھی شامل ہوتی ہیں۔ اسے boot کے وقت restore کرنے سے ان قواعد کی منجمد copy بن جاتی ہے جنہیں یہ tools خود بنانا چاہتے ہیں، اور پھر ان کے start ہونے کے بعد دوسری copy بھی بن جاتی ہے۔ صرف اپنی table کو sudo nft -s list table inet filter کے ذریعے dump کریں۔ -s flag counters کو خارج کرتا ہے، کیونکہ counters config file میں شامل نہیں ہونے چاہییں۔

VPS پر ufw فعال کرنا چاہیے؟

ufw کو اسی وقت تبدیل کریں جب آپ کو ایسی functionality درکار ہو جسے یہ بیان نہیں کر سکتا۔ عام VPS کے لیے ufw کافی ہے: default deny کے ساتھ چند ports کھلے ہوں۔ صرف اپنی مرضی سے اسے hand-written ruleset سے تبدیل کرنے پر وہی firewall برقرار رہتا ہے، مگر maintain کرنے کے لیے ایک اضافی چیز بن جاتی ہے۔

جب آپ کی ضرورت ufw کے model سے باہر ہو تو 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` اور hand-written table ایک ساتھ چلانے والا host اب بھی traffic منتقل کرے گا، لیکن live policy دو rulesets کا مجموعہ بن جائے گی۔ ان کا evaluation order service startup طے کرے گا، اور دونوں files پڑھنے والا کوئی شخص یہ نہیں بتا سکے گا کہ host حقیقت میں کیا کرتا ہے۔

موجودہ iptables ruleset منتقل کرنا

iptables-translate ایک rule کو تبدیل کرتا ہے اور اس کی nftables شکل دکھاتا ہے۔ یہ system میں کوئی تبدیلی نہیں کرتا۔

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 کے لیے بھی یہی کام کرتا ہے۔ اس کے output کو ابتدائی مسودہ سمجھیں۔ یہ conversion mechanical اور ہر rule کے مطابق ہوتی ہے، اس لیے پرانے table اور chain names واپس ملتے ہیں، IPv4 اور IPv6 کے لیے دو الگ rulesets بنتے ہیں، اور وہ sets شامل نہیں ہوتے جن کی وجہ سے migration کرنا مفید تھا۔ اسے دستی طور پر ایک inet table میں دوبارہ لکھیں، پھر live server پر لاگو کرنے سے پہلے nft -c -f کے ذریعے اس کی جانچ کریں۔

ان مثالوں میں موجود addresses documentation ranges 203.0.113.0/24 اور 198.51.100.0/24 سے لیے گئے ہیں، جبکہ enp1s0 ایک interface name ہے۔ اپنی values ip route show default اور ip -br addr سے حاصل کریں اور میری values copy نہ کریں، کیونکہ موجودہ Ubuntu images میں interface کا نام عموماً eth0 نہیں ہوتا۔

FAQ

کیا Ubuntu پر iptables متروک ہو چکا ہے؟

یہ command ختم نہیں ہو رہی اور Ubuntu 24.04 پر اب بھی کام کرتی ہے۔ تبدیلی اس کے اندرونی طریقۂ کار میں آئی ہے: iptables ایک front end ہے جو iptables-nft back end کے ذریعے nftables rules لکھتا ہے۔ اپنی configuration iptables -V سے چیک کریں؛ یہ 24.04 پر iptables v1.8.10 (nf_tables) دکھاتا ہے۔ پرانا x_tables back end اب بھی iptables-legacy کے طور پر شامل ہے، اور اس کا ruleset بالکل الگ ہوتا ہے۔ اس لیے rules صرف ایک back end میں شامل کریں، دونوں میں نہیں۔

کیا واپسی کے راستے میں NAT ختم کرنے کے لیے دوسری rule درکار ہے؟

نہیں۔ جب connection کی پہلی packet کسی nat rule سے match ہوتی ہے تو connection tracking translation محفوظ کر لیتا ہے، اور دونوں سمتوں میں آنے والی ہر بعد کی packet اسی محفوظ entry کے مطابق rewrite ہوتی ہے۔ sudo conntrack -L اسے ہر connection کے لیے دو tuples کے طور پر دکھاتا ہے: پہلے اصل سمت، پھر پہلے ہی reverse کی گئی reply۔ واپسی کی سمت کے لیے لکھی گئی rule مدد نہیں کر سکتی، کیونکہ return packets کبھی nat chain تک نہیں پہنچتیں۔

کیا میں ufw اور اپنی nftables rules ایک ساتھ چلا سکتا ہوں؟

یہ کام کرتا ہے، لیکن اس سے مسئلہ پیدا ہوگا۔ کسی hook پر موجود ہر base chain چلتی ہے، اس لیے live policy دونوں rulesets کا مجموعہ ہوتی ہے۔ ان کی ترتیب priority کے مطابق، اور برابر priority کی صورت میں اس service کے مطابق طے ہوتی ہے جو پہلے start ہوئی ہو۔ کسی ایک ruleset میں موجود drop حتمی فیصلہ ہوتا ہے، اور آپ کے ruleset میں موجود accept دوسری service کو اسی packet کو drop کرنے سے نہیں روکتا۔ ایک ہی tool منتخب کریں۔ اگر nftables استعمال کرنا ہے تو پہلے ufw کو disable کریں اور sudo nft list ruleset سے تصدیق کریں کہ اس کی tables ختم ہو چکی ہیں۔

Ubuntu پر nftables rules کو reboot کے بعد برقرار کیسے رکھوں؟

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 میں وہ tables بھی شامل ہو جاتی ہیں جنہیں ufw اور Docker خود manage کرتے ہیں۔