Rocky یا AlmaLinux VPS پر firewalld کا بنیادی طریقہ

firewalld کیا ہے، اور Rocky اور AlmaLinux اسے کیوں فراہم کرتے ہیں

firewalld، Rocky Linux، AlmaLinux اور Red Hat Enterprise Linux (RHEL) کی دیگر rebuilds میں default طور پر نصب firewall manager ہے۔ دونوں distributions نے یہ default خود منتخب نہیں کیا بلکہ وراثت میں حاصل کیا۔ یہ بات اس وقت زیادہ واضح ہوتی ہے جب آپ جانتے ہوں کہ CentOS کا رخ بدلنے کے بعد Rocky اور AlmaLinux نے Red Hat کے کام کو rebuild کرنے کا آغاز کیسے کیا۔ firewalld خود packets کا معائنہ نہیں کرتا۔ یہ محفوظ شدہ configuration رکھتا ہے اور اسے nftables rules میں تبدیل کرتا ہے۔ firewall-cmd نامی ایک command سرور کو online رکھتے ہوئے اس configuration میں ترمیم کرتی ہے۔ اس guide میں دونوں distributions کے درمیان کچھ نہیں بدلتا، کیونکہ وہ چیزیں جو حقیقت میں Rocky کو AlmaLinux سے الگ کرتی ہیں compatibility کا وعدہ اور اب بھی supported CPUs کی range ہیں، firewall نہیں۔

اگر آپ پہلے ہی Ubuntu VPS پر ufw کے کام کرنے کا طریقہ جانتے ہیں تو آپ بنیادی مقصد سے واقف ہیں۔ firewalld میں دو ایسے تصورات شامل ہیں جو ufw میں موجود نہیں۔ پہلا zones ہیں: ایک named policy جس کے مطابق packets کو مختلف زمروں میں رکھا جاتا ہے۔ دوسرا live rules اور saved rules کے درمیان فرق ہے۔ یہی --permanent flag ہے اور اسی tool میں سب سے زیادہ الجھن بھی اسی سے پیدا ہوتی ہے۔

ذیل میں موجود ہر چیز ایسی command ہے جسے آپ اپنے سرور پر چلاتے ہیں۔ ہر تبدیلی کو دوسری machine سے test کریں، کیونکہ server پر درست نظر آنے والا rule internet سے دیکھنے پر پھر بھی غلط ہو سکتا ہے۔

کسی بھی دوسرے کام سے پہلے SSH کھولیں

زیادہ تر Rocky اور AlmaLinux installations میں firewalld پہلے ہی موجود اور فعال ہوتا ہے، اور اس کے جاری کردہ configuration میں SSH کی اجازت ہوتی ہے۔ کچھ minimal cloud images اسے ہٹا دیتی ہیں۔ قیاس کرنے کے بجائے جانچ کریں۔

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --state

firewall-cmd --state، running پرنٹ کرتا ہے۔ اگر service stopped ہو تو ہر دوسری firewall-cmd call، FirewallD is not running کا جواب دیتی ہے اور non-zero کے ساتھ خارج ہو جاتی ہے۔ جب کوئی command بالکل کچھ نہ کرتی محسوس ہو تو سب سے پہلے یہی چیز چیک کریں۔

اب دیکھیں کہ اس وقت کیا اجازت یافتہ ہے۔

sudo firewall-cmd --list-all

اصل output میں چند مزید lines ہوتی ہیں۔ اہم lines یہ ہیں:

public (active)
  target: default
  interfaces: eth0
  sources:
  services: cockpit dhcpv6-client ssh
  ports:
  rich rules:

services: line میں ssh موجود ہونے کی وجہ سے آپ کا session اب بھی کام کر رہا ہے۔ اگر یہ موجود نہ ہو تو کسی بھی دوسرے کام سے پہلے اسے شامل کریں، کیونکہ SSH rule کے بغیر firewall شروع کرنے سے session ختم ہو جاتا ہے اور آپ دوبارہ login نہیں کر پاتے۔

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

target: default کا مطلب ہے کہ کسی rule سے match نہ ہونے والا packet، ICMP (internet control message protocol) host-prohibited reply کے ساتھ reject کیا جاتا ہے۔ اس لیے بند port سے رابطہ کرنے والے client کو فوراً No route to host نظر آتا ہے۔ target کو DROP پر set کرنے سے server خاموش رہتا ہے، اور scanners پھر timeout کا انتظار کرتے ہیں۔

sudo firewall-cmd --permanent --zone=public --set-target=DROP
sudo firewall-cmd --reload

یہ command چلانے سے پہلے اس کی قیمت سمجھ لیں: DROP server کو ping کا جواب دینے سے بھی روک دیتا ہے، اس لیے آپ کی اپنی monitoring بھی خاموش ہو جاتی ہے۔

میرا rule کیوں غائب ہو گیا؟ --permanent flag

firewalld ایک وقت میں دو configurations رکھتا ہے۔ runtime configuration وہ ہے جسے kernel اسی وقت نافذ کرتا ہے۔ permanent configuration /etc/firewalld/zones/public.xml میں موجود ہوتی ہے اور reload یا reboot کے بعد دوبارہ لاگو ہو جاتی ہے۔

--permanent کے بغیر چلایا گیا command صرف runtime configuration تبدیل کرتا ہے۔ یہ فوراً کام کرتا ہے، لیکن اگلے reload یا boot پر ختم ہو جاتا ہے۔ --permanent کے ساتھ چلایا گیا command file میں لکھتا ہے، مگر چل رہی configuration میں کوئی تبدیلی نہیں کرتا۔ اس لیے reload کرنے تک port بند رہتا ہے۔ دونوں رویے bug نہیں ہیں۔ دونوں صارفین کو اس لیے حیران کرتے ہیں کہ command دونوں صورتوں میں success دکھاتا ہے۔

ہر بار دونوں commands لکھیں۔

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --reload

آپ دونوں configurations پڑھ سکتے ہیں۔ اس سے یہ معلوم کرنے کا تیز ترین طریقہ ملتا ہے کہ آپ سے دونوں میں سے کون سی غلطی ہوئی ہے۔

sudo firewall-cmd --list-services
sudo firewall-cmd --permanent --list-services

پہلا command live set دکھاتا ہے۔ دوسرا saved set دکھاتا ہے۔ اگر live set میں کوئی service موجود ہو اور saved set میں نہ ہو تو اگلے reload پر وہ rule ختم ہو جائے گا۔ اگر saved set میں کوئی rule موجود ہو اور live set میں نہ ہو تو آپ reload کرنا بھول گئے ہیں۔ sudo firewall-cmd --runtime-to-permanent تمام live configuration کو saved file میں نقل کرتا ہے۔ تجربات کے ایک session کے بعد یہ مفید ہوتا ہے۔

--reload connection tracking state برقرار رکھتا ہے، اس لیے آپ کا SSH session جاری رہتا ہے۔ --complete-reload kernel modules بھی reload کرتا ہے اور یہ state ختم کر دیتا ہے۔ اس سے عموماً آپ کے SSH session سمیت تمام کھلے connections منقطع ہو جاتے ہیں۔ سادہ reload استعمال کریں۔

ایک safety net پہلے سے موجود ہے۔ runtime rule خود بخود ختم ہو سکتا ہے۔

sudo firewall-cmd --add-service=http --timeout=5m

یہ rule پانچ منٹ بعد خود کو ہٹا لیتا ہے۔ اسے --permanent کے ساتھ استعمال نہیں کیا جا سکتا، اور یہی مقصد ہے: یہ ایسی تبدیلی کی testing کے لیے ہے جس کے بارے میں آپ کو یقین نہ ہو۔ پرانا safety net زیادہ بہتر ہے۔ Rules میں ترمیم کرتے وقت دوسری SSH session کھلی رکھیں، اور اسے اس وقت تک بند نہ کریں جب تک نیا login یہ ثابت نہ کر دے کہ نئے rules کام کر رہے ہیں۔

زونز، اور VPS پر صرف default zone کیوں اہم ہے

zone نامزد permissions کا مجموعہ ہوتا ہے، جس کے ساتھ trust level منسلک ہوتا ہے۔ firewalld ہر incoming packet کو بالکل ایک zone میں رکھتا ہے۔ یہ پہلے packet کے source address کو ہر zone کی sources: فہرست کے مقابل ملاتا ہے۔ اگر کوئی match نہ ہو تو یہ وہ zone استعمال کرتا ہے جس سے incoming interface منسلک ہو۔ اگر interface کسی zone سے منسلک نہ ہو تو packet default zone میں چلا جاتا ہے۔

sudo firewall-cmd --get-default-zone
sudo firewall-cmd --get-active-zones

ایک network interface والے VPS پر پہلا جواب تقریباً ہمیشہ public ہوتا ہے، اور یہی واحد zone ہے جسے آپ استعمال کریں گے۔ firewall-cmd، جب --zone= argument کے بغیر چلایا جائے، default zone پر عمل کرتا ہے۔ اسی لیے اس guide میں ہر مختصر command کسی zone کا نام دیے بغیر کام کرتی ہے۔

یہ وہ خرابی ہے جو پورا دن ضائع کر دیتی ہے۔ اگر interface کسی دوسرے zone سے منسلک ہو تو آپ کے rules public میں شامل ہوتے ہیں، جبکہ traffic کہیں اور handle ہو رہا ہوتا ہے۔ اس لیے آپ کی شامل کردہ کسی چیز کا اثر نہیں ہوتا اور کوئی warning بھی نہیں ملتی۔ --get-active-zones یہ binding دکھاتا ہے:

public
  interfaces: eth0

اگر interface کسی مختلف zone name کے تحت نظر آئے تو یا تو --zone= کے ساتھ وہیں اپنے rules لکھیں، یا interface کو منتقل کریں۔

sudo firewall-cmd --permanent --zone=public --change-interface=eth0
sudo firewall-cmd --reload

Rocky اور AlmaLinux پر NetworkManager interfaces manage کرتا ہے، اور connection فعال ہونے پر zone دوبارہ نافذ کرتا ہے۔ اسے وہاں بھی set کریں تاکہ reboot کے بعد آپ کی configuration ختم نہ ہو۔ connection name پہلی command سے حاصل کریں، کیونکہ یہ عموماً device name جیسا نہیں ہوتا۔

sudo nmcli connection show
sudo nmcli connection modify "System eth0" connection.zone public

Source matching کو interface matching پر ترجیح حاصل ہے۔ اسی طریقے سے ایک address کے لیے مختلف policy مقرر کی جا سکتی ہے۔ built-in trusted zone ہر چیز قبول کرتا ہے۔

sudo firewall-cmd --permanent --zone=trusted --add-source=203.0.113.10/32
sudo firewall-cmd --reload

اس کے ساتھ محتاط رہیں۔ یہ اس address کے لیے server کا ہر port کھول دیتا ہے، جس میں وہ database بھی شامل ہے جسے آپ private سمجھتے تھے۔ جب آپ کو ایک host کے بجائے صرف ایک port کھولنا ہو تو rich rule استعمال کریں۔

firewalld سروس کیا ہے؟

سروس ports کا نام زد bundle ہے، جو XML file کے طور پر فراہم ہوتا ہے۔ --add-service=https، 443/tcp کھولتا ہے کیونکہ /usr/lib/firewalld/services/https.xml یہ متعین کرتا ہے کہ https سے کیا مراد ہے۔

sudo firewall-cmd --get-services
sudo firewall-cmd --info-service=https

--info-service، اس نام کے پیچھے موجود ports دکھاتا ہے:

https
  ports: 443/tcp

جب کوئی نام موجود ہو تو اسے استعمال کریں۔ چھ ماہ بعد --list-all میں بھی یہ واضح طور پر سمجھ آتا ہے، اور Cockpit جیسے packages اپنی service file خود install کرتے ہیں۔ جس چیز کی کوئی definition نہ ہو، اس کے لیے --add-port استعمال کریں۔

جس بات پر نظر رکھنی ہے وہ یہ ہے: ssh سروس سے مراد 22/tcp اور اس کے علاوہ کچھ نہیں ہے۔ اگر آپ نے سرور پر SSH رسائی سخت بنانے کے دوران SSH کو کسی دوسرے port پر منتقل کیا ہے، تو --add-service=ssh وہ port نہیں کھولتا جسے آپ حقیقت میں استعمال کرتے ہیں۔

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload

RHEL rebuild پر اس port کے لیے ایک دوسری پابندی بھی ہوتی ہے۔ SELinux (security-enhanced Linux)، port numbers کو labels دیتا ہے، اور sshd کو اپنے labels سے باہر کسی port پر bind ہونے کی اجازت نہیں ہوتی۔ اس کے بعد یہ start ہونے سے انکار کر دیتا ہے اور log میں error: Bind to port 2222 on 0.0.0.0 failed: Permission denied. لکھا ہوتا ہے۔ پہلے port کو label دیں۔

sudo dnf install -y policycoreutils-python-utils
sudo semanage port -a -t ssh_port_t -p tcp 2222

اس وقت کون سی ports کھلی ہیں، یہ کیسے دیکھوں؟

sudo firewall-cmd --list-all
sudo firewall-cmd --list-rich-rules
sudo nft list table inet firewalld | head -n 40

پہلی دو کمانڈز وہ حالت دکھاتی ہیں جسے firewalld درست سمجھتا ہے۔ تیسری کمانڈ اس table میں kernel کے پاس موجود اصل rules پڑھتی ہے جس کا انتظام firewalld کرتا ہے۔ ان تینوں کا نتیجہ ایک جیسا ہونا چاہیے۔

یہ میں سے کوئی بھی چیز مکمل ثبوت نہیں ہے۔ کسی دوسری machine سے test کریں:

nc -zv 203.0.113.20 443

یہ test خود server پر نہ چلائیں۔ firewalld loopback interface سے آنے والی ہر چیز قبول کرتا ہے، اس لیے curl http://localhost:8080 آپ کے rules کچھ بھی کہتے ہوں، کامیاب ہو جائے گا۔ اس test سے صرف یہ معلوم ہوتا ہے کہ service چل رہی ہے۔ firewall کے بارے میں اس سے کچھ معلوم نہیں ہوتا۔

ویب پورٹ کی اجازت دیں

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-services

اب آخری کمانڈ کو پہلے سے موجود اندراجات کے ساتھ http https بھی دکھانا چاہیے۔ اگر سائٹ اب بھی جواب نہیں دیتی تو ممکن ہے مسئلہ firewall کا نہ ہو۔ rule کسی packet کو گزرنے کی اجازت دیتا ہے۔ اسے قبول کرنے کے لیے کوئی process اس port پر listening بھی کر رہا ہو۔

sudo ss -tlnp

0.0.0.0:443 یا *:443 کے طور پر دکھایا گیا socket کسی بھی address سے connections قبول کرتا ہے۔ 127.0.0.1:443 کے طور پر دکھایا گیا socket صرف loopback پر جواب دیتا ہے، اور کوئی firewall rule اسے باہر سے قابل رسائی نہیں بنا سکتا۔ Linux میں ports اور listening sockets اس فرق کی مزید وضاحت کرتا ہے۔

پورٹ دوبارہ کیسے بند کروں؟

sudo firewall-cmd --permanent --remove-service=http
sudo firewall-cmd --reload

یہاں بھی --permanent rule لاگو ہوتا ہے، اور اس سمت میں اس کے نتائج زیادہ سنگین ہوتے ہیں۔ صرف runtime سے service ہٹا دیں تو port بند دکھائی دیتا ہے، لیکن اگلے reload یا reboot پر saved file سے دوبارہ کھل جاتا ہے۔ یہ ایک ایسی خامی ہے جس کا آپ کو پتا نہیں چلے گا، کیونکہ آپ کی چلائی ہوئی جانچ کامیاب رہی تھی۔

جو چیز کبھی موجود ہی نہ ہو، اسے ہٹانے پر Warning: NOT_ENABLED: http ظاہر ہوتا ہے اور پھر بھی exit status 0 رہتا ہے۔ اسی چیز کو دوسری بار شامل کرنے پر Warning: ALREADY_ENABLED: http ظاہر ہوتا ہے۔ دونوں صورتیں محفوظ ہیں۔ غلط املا والا نام مختلف معاملہ ہے: Error: INVALID_SERVICE کا مطلب ہے کہ firewalld کے پاس اس نام کی کوئی definition نہیں، اس لیے کچھ بھی تبدیل نہیں ہوا۔

اگر آپ کے --list-all میں cockpit دکھائی دے اور آپ port 9090 پر Cockpit web console استعمال نہ کرتے ہوں تو اسے ہٹا دیں۔ ہر کھلا port ایک ایسی service ہے جس کے patches آپ کو باقاعدگی سے install کرنے ہوتے ہیں۔ جن ports کو آپ برقرار رکھنے کا فیصلہ کریں، ان کے لیے dnf-automatic timer کے ذریعے security updates install کر سکتا ہے، تاکہ یہ کام آپ کے یاد رکھنے پر منحصر نہ رہے۔ تاہم patch install کرنا اسے چلانے کے برابر نہیں ہے، اور needs-restarting دکھاتا ہے کہ updates کے بعد کون سی services اب بھی پرانی libraries استعمال کر رہی ہیں۔

ایک source address تک port محدود کریں

Rich rules طویل syntax استعمال کرتی ہیں، جب عام service name آپ کی مطلوبہ پالیسی بیان نہ کر سکے۔ SSH کو ایک office address تک محدود کرنے کے لیے دو commands درکار ہوتی ہیں، اور عموماً لوگ دوسری command بھول جاتے ہیں۔

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" service name="ssh" accept'
sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --reload

Zone permissions کا مجموعہ ہوتا ہے، ایسی numbered list نہیں جو پہلے match پر رک جائے۔ Rich rule ایک address کے لیے accept شامل کرتی ہے۔ یہ کسی کو deny نہیں کرتی۔ جب تک ssh، services: line میں موجود ہے، پورا internet اب بھی port 22 تک پہنچ سکتا ہے، اور rich rule سے کوئی قابلِ پیمائش تبدیلی نہیں آئے گی۔ وسیع entry حذف کریں، ورنہ محدود rule محض دکھاوا ہے۔

ایسے port کے لیے جس کا کوئی service name نہ ہو، port کو براہِ راست نامزد کریں۔

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" port port="5432" protocol="tcp" accept'

شور پیدا کرنے والے network کو drop کرتے ہوئے اس کا record رکھنے کے لیے log element کو action سے پہلے لکھیں۔ Rich rule language اسی ترتیب کی توقع کرتی ہے۔

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="198.51.100.0/24" log prefix="fw-drop " level="info" limit value="3/m" drop'
sudo firewall-cmd --reload
sudo journalctl -k -g fw-drop

limit value packets کے سیلاب کو journal بھرنے سے روکتی ہے۔ SSH کو ایک address تک محدود کرنے سے پہلے یقینی بنائیں کہ وہ address مستقل ہے۔ بدلتے ہوئے IP address والا home connection، address بدلنے کے دن آپ کی رسائی بند کر دے گا۔ اس لیے پہلے provider کے console access کو آزما کر فعال ہونے کی تصدیق کریں۔

ufw کمانڈز اور ان کے firewall-cmd متبادل

کام ایک جیسے ہیں، ٹول مختلف ہے۔ ہر --permanent لائن کے بعد sudo firewall-cmd --reload ہونا ضروری ہے، اور یہی وہ بات ہے جو ایسی فہرست نہیں دکھا سکتی۔

• sudo ufw enable تبدیل ہو کر sudo systemctl enable --now firewalld بن جاتا ہے
• sudo ufw disable تبدیل ہو کر sudo systemctl disable --now firewalld بن جاتا ہے
• sudo ufw status verbose تبدیل ہو کر sudo firewall-cmd --list-all بن جاتا ہے
• sudo ufw allow OpenSSH تبدیل ہو کر sudo firewall-cmd --permanent --add-service=ssh بن جاتا ہے
• sudo ufw allow 443/tcp تبدیل ہو کر sudo firewall-cmd --permanent --add-port=443/tcp بن جاتا ہے
• sudo ufw delete allow 443/tcp تبدیل ہو کر sudo firewall-cmd --permanent --remove-port=443/tcp بن جاتا ہے
• sudo ufw allow from 203.0.113.10 to any port 22 اوپر دکھائے گئے rich rule میں تبدیل ہو جاتا ہے
• sudo ufw reload تبدیل ہو کر sudo firewall-cmd --reload بن جاتا ہے
• sudo ufw default deny incoming پہلے ہی اسی طرح ہے جیسے public zone کام کرتا ہے، اور --set-target=DROP اس کا خاموش ورژن ہے
• sudo ufw logging on تبدیل ہو کر sudo firewall-cmd --set-log-denied=all بن جاتا ہے

ایک فرق واضح طور پر بیان کرنا ضروری ہے۔ ufw نمبروں والی فہرست برقرار رکھتا ہے، اور آپ rule کو position 1 پر داخل کر سکتے ہیں۔ firewalld میں rule numbers نہیں ہوتے، اس لیے یہاں "اس rule کو پہلے رکھیں" کا کوئی مطلب نہیں۔ جب firewalld کی دو entries بظاہر ایک دوسرے سے متصادم ہوں، تو وسیع accept غالب رہتا ہے، کیونکہ set میں کوئی deny موجود نہیں ہوتا۔ وسیع entry آپ کو خود remove کرنی ہوگی۔

میرا Docker container اس وقت قابلِ رسائی کیوں ہے جب firewall بظاہر بند ہے؟

کیونکہ شائع شدہ container port firewall کے اس حصے تک نہیں پہنچتا جسے آپ کا zone کنٹرول کرتا ہے۔ docker run -d -p 8080:80 nginx Docker کو اپنے NAT (network address translation) اور forwarding rules لکھنے کی ہدایت دیتا ہے۔ 8080 پر آنے والے packet کو دوبارہ لکھ کر container کی طرف route کیا جاتا ہے، اس لیے اسے host تک پہنچانے کے بجائے forward کیا جاتا ہے۔ آپ کے zone میں موجود services: اور ports: کی سطریں host تک پہنچنے والے packets کو کنٹرول کرتی ہیں۔ Docker کے rules forward path کو کنٹرول کرتے ہیں، اور وہ packets قبول کر لیتے ہیں۔

نتیجہ یہ server ہے جہاں sudo firewall-cmd --list-all میں port 8080 ظاہر نہیں ہوتا، لیکن کسی دوسری machine سے nc -zv 203.0.113.20 8080 کے ذریعے connection قائم ہو جاتا ہے۔ دیکھیں کہ Docker نے کیا نصب کیا ہے:

sudo iptables -t nat -L DOCKER -n

اس مسئلے کا حل publish flag میں ہے۔ port کو loopback سے bind کریں اور اس کے سامنے reverse proxy رکھیں۔

docker run -d -p 127.0.0.1:8080:80 nginx

اب container server پر curl http://127.0.0.1:8080 کا جواب دیتا ہے، جبکہ باہر سے آنے والی کسی درخواست کا جواب نہیں دیتا۔ Ubuntu users کو بھی یہی مسئلہ درپیش آتا ہے، جس کی وضاحت Docker containers، ports کو ufw سے براہِ راست باہر کیوں شائع کرتے ہیں میں کی گئی ہے۔ Rootful Podman، جسے Rocky اور AlmaLinux base repositories میں فراہم کرتے ہیں، ports کو اسی NAT طریقے سے شائع کرتا ہے۔ اس لیے zone list پر بھروسا کرنے کے بجائے کسی دوسری machine سے test کریں۔ یہی مماثلت اس وجہ کی بھی ہے کہ ان distributions پر Docker Engine install کرنا چند اضافی steps کا تقاضا کرتا ہے جن کا Ubuntu guide میں ذکر نہیں ہوتا، اور ابتدا اس بات سے ہوتی ہے کہ Podman پہلے ہی docker command استعمال کر رہا ہوتا ہے۔

ریبوٹ کے بعد بھی firewall چلانا، اور سامنے آنے والی خرابیوں کو سمجھنا

sudo systemctl is-enabled firewalld
sudo systemctl status firewalld

enabled اور active (running) وہ نتائج ہیں جو آپ چاہتے ہیں۔ چل رہا لیکن enabled نہ کیا گیا firewall صرف پہلے reboot تک تحفظ فراہم کرتا ہے۔ یہ جانچ ان کاموں کی فہرست میں شامل ہونی چاہیے جنہیں آپ نئے VPS کے پہلے دس منٹ میں مکمل کرتے ہیں، اور اسی فہرست میں SSH keys اور updates بھی شامل ہوتے ہیں۔

Raw nftables commands اور firewalld کو یکجا استعمال نہ کریں۔ firewalld ایک table کا مالک ہوتا ہے جس کا نام inet firewalld ہے۔ sudo nft flush ruleset اسے حذف کر دیتا ہے، جس کے بعد server ہر قسم کے traffic کے لیے کھل جاتا ہے۔ اس کے باوجود firewall-cmd --list-all آپ کی مطلوبہ configuration دکھاتا رہتا ہے، کیونکہ firewalld وہ configuration رپورٹ کرتا ہے جسے وہ درست سمجھتا ہے، نہ کہ وہ جو kernel میں موجود ہو۔ sudo firewall-cmd --reload rules دوبارہ نصب کرتا ہے۔ rules کو firewall-cmd کے ذریعے لکھیں تاکہ reload کے بعد وہ دوبارہ لاگو ہو جائیں۔

ایک ہی server پر دو firewall managers۔ firewalld کے ساتھ ufw یا iptables-services نصب کرنے سے دو پروگرام ایسے rules لکھنے لگتے ہیں جنہیں ایک دوسرے کا علم نہیں ہوتا۔ نتیجہ اس بات پر منحصر ہوتا ہے کہ آخر میں کون سی service شروع ہوئی۔ صرف ایک منتخب کریں۔ Rocky اور AlmaLinux پر distribution support کے ساتھ firewalld دستیاب ہے۔

Server کے سامنے provider firewall۔ بہت سے VPS panels میں الگ network firewall ہوتا ہے۔ اگر --list-all کسی port کو open دکھائے لیکن باہر سے آنے والا connection پھر بھی ناکام ہو، تو server پر کچھ تبدیل کرنے سے پہلے panel کی settings دیکھیں۔ اس کے برعکس بھی یہی بات درست ہے: panel میں open rule کا کوئی فائدہ نہیں ہوتا اگر firewalld packet مسترد کر رہا ہو۔

sudo کے بغیر firewall-cmd چلانا۔ ہر تبدیلی کے لیے root درکار ہے۔ اس کے بغیر authorization check درخواست مسترد کر دیتا ہے اور کچھ بھی تبدیل نہیں ہوتا۔ بظاہر ایسا لگتا ہے جیسے command کو نظرانداز کر دیا گیا ہو۔

روزمرہ کے زیادہ تر کاموں کے لیے چھ commands کافی ہیں: state دیکھنے کے لیے --list-all، کسی چیز کو open کرنے کے لیے --permanent --add-service یا --add-port، اسے close کرنے کے لیے --permanent --remove-service، محفوظ file لاگو کرنے کے لیے --reload، اور تجربات کے ایک دور کے بعد --runtime-to-permanent۔ zone public ہے، flag --permanent ہے، اور درست جانچ صرف کسی دوسرے machine سے کی جا سکتی ہے۔

FAQ

میری firewalld rule reboot کے بعد کیوں غائب ہو گئی؟

Rule صرف runtime configuration میں شامل ہوئی تھی۔ sudo firewall-cmd --add-service=http اسے فوراً نافذ کرتا ہے، لیکن اگلے reload یا boot پر خارج ہو جاتی ہے، کیونکہ /etc/firewalld/zones/public.xml میں محفوظ configuration میں کوئی تبدیلی نہیں کی گئی تھی۔ --permanent شامل کریں، پھر sudo firewall-cmd --reload چلائیں۔ جو rules آپ پہلے ہاتھ سے شامل کر چکے ہیں، انہیں محفوظ رکھنے کے لیے sudo firewall-cmd --runtime-to-permanent چلائیں۔ یہ live set کو محفوظ file میں copy کر دیتا ہے۔

--permanent کے ساتھ rule شامل کرنے کے بعد کچھ تبدیل کیوں نہیں ہوتا؟

کیونکہ --permanent file میں تبدیلی کرتا ہے، لیکن چلتے ہوئے firewall کو تبدیل نہیں کرتا۔ Port اس وقت تک بند رہتا ہے جب تک sudo firewall-cmd --reload محفوظ configuration کو kernel میں load نہ کر دے۔ sudo firewall-cmd --list-services اور sudo firewall-cmd --permanent --list-services کا موازنہ کریں۔ اگر محفوظ فہرست میں ایسی entry موجود ہو جو live فہرست میں نہ ہو، تو آپ سے reload رہ گیا ہے۔

کیا مجھے --add-service یا --add-port استعمال کرنا چاہیے؟

جب آپ جو سروس چلا رہے ہیں اس کے لیے کوئی نام موجود ہو تو --add-service استعمال کریں۔ اس سے مقصد واضح ہوتا ہے، اور sudo firewall-cmd --info-service=https دکھاتا ہے کہ وہ نام کن ports کا احاطہ کرتا ہے۔ جب آپ کی سروس کی تعریف موجود نہ ہو، یا سروس non-standard port پر listening کر رہی ہو، تو --add-port استعمال کریں۔ ssh service صرف 22/tcp ہے۔ اس لیے SSH کو 2222 پر منتقل کرنے کے لیے --add-port=2222/tcp اور اس port کے لیے SELinux label درکار ہے۔

Docker container اس وقت reachable کیوں ہے جب firewalld port کو closed دکھاتا ہے؟

Published port کو Docker کے اپنے NAT rules rewrite کرتے ہیں اور container تک forward کرتے ہیں۔ اس لیے packet host تک deliver نہیں ہوتا، اور zone کی service اور port lists صرف ان packets پر لاگو ہوتی ہیں جو host تک deliver ہوں۔ --list-all کچھ نہیں دکھاتا، لیکن container internet سے جواب دیتا ہے۔ docker run -d -p 127.0.0.1:8080:80 nginx کے ساتھ port کو صرف loopback پر publish کریں، اور اس کے سامنے reverse proxy رکھیں۔

کیا firewalld کے بجائے Rocky Linux پر ufw install کیا جا سکتا ہے؟

ایک ہی server پر موجود دو firewall managers ایک دوسرے سے لاعلم رہ کر rules لکھتے ہیں، اور کون سا rule set برقرار رہے گا یہ اس بات پر منحصر ہوتا ہے کہ آخر میں کون سی service start ہوئی۔ Rocky Linux اور AlmaLinux پر firewalld supported tool ہے، یہ پہلے سے installed ہوتا ہے، اور اسی nftables backend کو چلاتا ہے جسے ufw چلاتا۔ Default zone اور --permanent flag ایک بار سمجھ لیں تو پورا tool استعمال کر سکتے ہیں۔