Rocky یا AlmaLinux VPS پر firewalld کی بنیادی ترتیب

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

firewalld، Rocky Linux، AlmaLinux اور Red Hat Enterprise Linux (RHEL) کے دیگر rebuilds میں پہلے سے نصب firewall manager ہے۔ یہ خود packets کا معائنہ نہیں کرتا۔ یہ محفوظ شدہ configuration برقرار رکھتا ہے اور اس configuration کو nftables rules میں تبدیل کرتا ہے۔ ایک command، firewall-cmd، سرور کو online رکھتے ہوئے اس configuration میں ترمیم کرتی ہے۔

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

ذیل میں موجود ہر command آپ اپنے سرور پر چلاتے ہیں۔ ہر تبدیلی کو دوسری machine سے test کریں، کیونکہ سرور پر درست نظر آنے والا 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 بند ہو تو ہر دوسری firewall-cmd call، FirewallD is not running کا جواب دیتی ہے اور non-zero کے ساتھ exit ہوتی ہے۔ جب کوئی 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 کا مطلب ہے کہ جس packet کے لیے کوئی rule match نہ ہو اسے ICMP (internet control message protocol) کی host-prohibited reply کے ساتھ reject کیا جاتا ہے، اس لیے بند port سے connect کرنے والے 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 دکھاتی ہے۔

ہر بار یہ جوڑا لکھیں۔

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

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

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

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

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

ایک حفاظتی طریقہ پہلے سے موجود ہے۔ runtime rule خود بخود ختم ہو سکتا ہے۔

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

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

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

zone اجازتوں کا نامزد مجموعہ ہوتا ہے، جس کے ساتھ 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 کا نام دیے بغیر کام کرتی ہے۔

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

public
  interfaces: eth0

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

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

Rocky اور AlmaLinux پر NetworkManager interfaces manage کرتا ہے، اور connection کے active ہونے پر zone دوبارہ نافذ کرتا ہے۔ اسے وہاں بھی set کریں تاکہ reboot کے بعد آپ کی configuration ختم نہ ہو۔ connection name پہلی command کے output سے لیں، کیونکہ یہ 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 کا نامزد مجموعہ ہوتی ہے، جو XML فائل کے طور پر فراہم کی جاتی ہے۔ --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 access کو سخت محفوظ بنایا کے دوران 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

اس وقت کون سی چیزیں کھلی ہیں؟

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

پہلی دو کمانڈز وہ رپورٹ کرتی ہیں جو firewalld کے خیال میں موجود ہے۔ تیسری کمانڈ وہ rules پڑھتی ہے جو kernel نے حقیقت میں رکھے ہوئے ہیں، یعنی اس table میں جس کا انتظام 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

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

sudo ss -tlnp

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

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

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

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

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

اگر آپ کے --list-all میں cockpit دکھائی دے اور آپ port 9090 پر Cockpit web console استعمال نہ کرتے ہوں تو اسے ہٹا دیں۔ ہر کھلا پورٹ ایک ایسی service ہے جس کے patches آپ کو باقاعدگی سے انسٹال کرنے ہوں گے۔

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

Rich rules اس وقت استعمال ہوتی ہیں جب سادہ service name آپ کی مطلوبہ configuration کو بیان نہ کر سکے۔ 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'

کسی noisy network کے packets 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 journal میں packets کی بھرمار کو روکتی ہے۔ SSH کو ایک ہی address تک محدود کرنے سے پہلے یقینی بنائیں کہ وہ address مستحکم ہے۔ بدلتے ہوئے IP address والا home connection تبدیل ہوتے ہی آپ کو lock out کر سکتا ہے۔ اس لیے پہلے اپنے provider کے console access کو آزما کر فعال رکھیں۔

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

کام ایک ہی ہے، لیکن tool مختلف ہے۔ ہر --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 قواعد کی numbered فہرست برقرار رکھتا ہے، اور آپ کوئی rule position 1 پر insert کر سکتے ہیں۔ firewalld میں rule numbers نہیں ہوتے، اس لیے "اس rule کو پہلے رکھیں" یہاں کوئی معنی نہیں رکھتا۔ جب firewalld کی دو entries بظاہر ایک دوسرے سے متصادم ہوں، تو broad accept جیتتا ہے، کیونکہ ruleset میں کوئی چیز deny نہیں کرتی۔ broad entry آپ کو خود remove کرنی ہوگی۔

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

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

نتیجہ ایسا server ہوتا ہے جہاں sudo firewall-cmd --list-all میں port 8080 نظر نہیں آتا، لیکن دوسری machine سے nc -zv 203.0.113.20 8080 پھر بھی connect ہو جاتا ہے۔ دیکھیں کہ Docker نے کیا install کیا ہے:

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 صارفین کو بھی یہی مسئلہ درپیش ہوتا ہے، جس کی وضاحت Docker containers ports کو براہِ راست ufw کے ذریعے publish کیوں کرتے ہیں میں کی گئی ہے۔ Rootful Podman، جسے Rocky اور AlmaLinux اپنے base repositories میں فراہم کرتے ہیں، ports publish کرنے کے لیے یہی NAT طریقہ استعمال کرتا ہے۔ اس لیے zone list پر بھروسا کرنے کے بجائے دوسری machine سے test کریں۔

اسے reboot کے بعد بھی چلتا رکھنا، اور وہ errors جو آپ دیکھیں گے

sudo systemctl is-enabled firewalld
sudo systemctl status firewalld

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

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

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

سرور کے سامنے provider firewall۔ بہت سے VPS panels میں الگ network firewall ہوتا ہے۔ اگر --list-all کسی port کو open دکھائے لیکن باہر سے connection پھر بھی fail ہو، تو سرور پر کچھ تبدیل کرنے سے پہلے panel check کریں۔ معاملہ الٹا بھی ہو سکتا ہے: panel میں open rule ہونے کے باوجود firewalld packet reject کر سکتا ہے۔

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

چھ commands روزمرہ کے زیادہ تر کاموں کے لیے کافی ہیں: state پڑھنے کے لیے --list-all، کچھ open کرنے کے لیے --permanent --add-service یا --add-port، اسے close کرنے کے لیے --permanent --remove-service، saved file apply کرنے کے لیے --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 کو saved file میں نقل کر دیتا ہے۔

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

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

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

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

firewalld-cmd port کو closed دکھاتا ہے، پھر میرا Docker container قابل رسائی کیوں ہے؟

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 کے ساتھ اسے صرف 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 سمجھ آ جاتا ہے۔