Rocky और AlmaLinux पर firewalld कैसे कॉन्फ़िगर करें

firewalld क्या है, और Rocky तथा AlmaLinux इसे क्यों प्रदान करते हैं

firewalld एक firewall manager है जो Rocky Linux, AlmaLinux और Red Hat Enterprise Linux (RHEL) के अन्य rebuilds पर डिफ़ॉल्ट रूप से इंस्टॉल रहता है। यह स्वयं packets का निरीक्षण नहीं करता है। यह एक saved configuration रखता है और उस configuration को nftables नियमों में बदल देता है। एक command, firewall-cmd, सर्वर के ऑनलाइन रहते हुए ही इसमें बदलाव करने की सुविधा देती है।

यदि आप पहले से ही जानते हैं कि Ubuntu VPS पर ufw कैसे काम करता है, तो आप इसके कार्य को समझते हैं। firewalld दो ऐसी अवधारणाएं जोड़ता है जो ufw में नहीं हैं। पहली है zones: एक नामित नीति (named policy) जिसमें packets को वर्गीकृत किया जाता है। दूसरी है live rules और saved rules के बीच का विभाजन, जो --permanent flag है और इस टूल में भ्रम का सबसे बड़ा कारण है।

नीचे दिए गए सभी commands वे हैं जिन्हें आप अपने सर्वर पर चलाते हैं। प्रत्येक बदलाव का परीक्षण किसी दूसरी मशीन से करें, क्योंकि जो नियम सर्वर पर सही दिखता है, वह इंटरनेट से गलत हो सकता है।

किसी भी अन्य कार्य से पहले SSH खोलें

अधिकांश Rocky और AlmaLinux इंस्टॉलेशन में firewalld पहले से मौजूद और चालू रहता है, और डिफ़ॉल्ट कॉन्फ़िगरेशन SSH की अनुमति देता है। कुछ न्यूनतम क्लाउड इमेजेस में इसे हटा दिया जाता है। मान लेने के बजाय जाँच करें।

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

firewall-cmd --state कमांड running को प्रिंट करता है। यदि सर्विस बंद है, तो हर अन्य firewall-cmd कॉल FirewallD is not running उत्तर देती है और नॉन-जीरो एक्जिट कोड के साथ समाप्त हो जाती है। जब कोई कमांड बिल्कुल काम करती हुई न दिखे, तो सबसे पहले यही जाँचें।

अब पढ़ें कि वर्तमान में क्या अनुमति प्राप्त है।

sudo firewall-cmd --list-all

वास्तविक आउटपुट में कुछ और पंक्तियाँ होती हैं। ये वे पंक्तियाँ हैं जो मायने रखती हैं:

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

services: लाइन में ssh का होना ही कारण है कि आपका सेशन अभी भी काम कर रहा है। यदि यह गायब है, तो किसी भी अन्य चीज़ को छूने से पहले इसे जोड़ें, क्योंकि बिना SSH नियम के फ़ायरवॉल शुरू करने से आपका सेशन समाप्त हो जाएगा और आप वापस अंदर नहीं आ पाएंगे।

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

target: default का अर्थ है कि जो पैकेट किसी नियम से मेल नहीं खाते, उन्हें ICMP (इंटरनेट कंट्रोल मैसेज प्रोटोकॉल) host-prohibited रिप्लाई के साथ रिजेक्ट कर दिया जाता है, इसलिए बंद पोर्ट पर हिट करने वाले क्लाइंट को तुरंत No route to host दिखाई देता है। टारगेट को DROP पर सेट करने से सर्वर चुप हो जाता है और स्कैनर्स टाइमआउट की प्रतीक्षा करते हैं।

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

इसे चलाने से पहले इसके परिणाम को समझें: DROP सर्वर को ping का उत्तर देने से भी रोकता है, इसलिए आपकी अपनी मॉनिटरिंग भी शांत हो जाएगी।

मेरा नियम गायब क्यों हो गया? --permanent फ्लैग

firewalld एक साथ दो कॉन्फ़िगरेशन रखता है। रनटाइम कॉन्फ़िगरेशन वह है जिसे कर्नेल इस समय लागू कर रहा है। परमानेंट कॉन्फ़िगरेशन वह है जो /etc/firewalld/zones/public.xml में रहता है और रीलोड या रीबूट के बाद वापस आता है।

--permanent के बिना दिया गया कमांड केवल रनटाइम को बदलता है। यह तुरंत काम करता है और अगले रीलोड या बूट पर हट जाता है। --permanent के साथ दिया गया कमांड फ़ाइल में लिखता है और चल रही किसी चीज़ को नहीं बदलता है, इसलिए जब तक आप रीलोड नहीं करते, पोर्ट बंद रहता है। इनमें से कोई भी व्यवहार बग नहीं है। दोनों ही लोगों को हैरान करते हैं, क्योंकि कमांड दोनों ही स्थितियों में success प्रिंट करता है।

हर बार दोनों का उपयोग करें।

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

आप दोनों कॉन्फ़िगरेशन पढ़ सकते हैं, जो यह पता लगाने का सबसे तेज़ तरीका है कि आपने इन दो गलतियों में से कौन सी की है।

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

पहला कमांड लाइव सेट को प्रिंट करता है। दूसरा कमांड सहेजे गए सेट को प्रिंट करता है। यदि लाइव सेट में कोई ऐसी सर्विस है जो सहेजे गए सेट में नहीं है, तो वह नियम अगले रीलोड पर हट जाएगा। यदि सहेजे गए सेट में कोई ऐसी सर्विस है जो लाइव सेट में नहीं है, तो आप रीलोड करना भूल गए हैं। sudo firewall-cmd --runtime-to-permanent लाइव सेट की हर चीज़ को सहेजी गई फ़ाइल में कॉपी कर देता है, जो प्रयोगों के सत्र के बाद उपयोगी होता है।

--reload कनेक्शन ट्रैकिंग स्टेट को बनाए रखता है, इसलिए आपका SSH सत्र बना रहता है। --complete-reload कर्नेल मॉड्यूल को भी रीलोड करता है और उस स्टेट को खो देता है, जिससे आमतौर पर आपका अपना कनेक्शन सहित हर खुला कनेक्शन समाप्त हो जाता है। साधारण रीलोड का उपयोग करें।

एक सुरक्षा जाल (safety net) पहले से मौजूद है। रनटाइम नियम अपने आप समाप्त हो सकता है।

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

वह नियम पांच मिनट बाद खुद को हटा देता है। इसे --permanent के साथ नहीं जोड़ा जा सकता है, और यही इसका उद्देश्य है: यह किसी ऐसे बदलाव का परीक्षण करने के लिए मौजूद है जिसके बारे में आप सुनिश्चित नहीं हैं। पुराना सुरक्षा जाल बेहतर है। नियमों को संपादित करते समय एक दूसरा SSH सत्र खुला रखें, और उसे तब तक बंद न करें जब तक कि एक नया लॉगिन यह साबित न कर दे कि नए नियम काम कर रहे हैं।

Zones, और VPS पर केवल default zone ही क्यों मायने रखता है

Zone अनुमतियों का एक नामित समूह है जिसके साथ एक trust level जुड़ा होता है। firewalld प्रत्येक आने वाले packet को ठीक एक zone में डालता है। यह सबसे पहले packet के source address का मिलान प्रत्येक zone की sources: सूची से करता है। यदि कोई मिलान नहीं होता है, तो यह उस 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 है जिसका आप उपयोग करेंगे। बिना किसी --zone= argument के firewall-cmd default zone पर काम करता है, यही कारण है कि इस गाइड में हर छोटा command बिना किसी zone का नाम लिए काम करता है।

यहाँ वह विफलता है जो एक पूरी दोपहर बर्बाद कर देती है। यदि interface किसी अन्य zone से जुड़ा है, तो आपके rules public में चले जाते हैं जबकि traffic कहीं और handle हो रहा होता है, इसलिए आपके द्वारा जोड़ी गई किसी भी चीज़ का कोई प्रभाव नहीं पड़ता और आपको कोई चेतावनी भी नहीं मिलती। --get-active-zones binding दिखाता है:

public
  interfaces: eth0

यदि interface किसी अलग zone नाम के अंतर्गत दिखाई देता है, तो या तो अपने rules को --zone= के साथ वहाँ लिखें, या interface को move करें।

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

NetworkManager Rocky और AlmaLinux पर interfaces को manage करता है, और जब connection active होता है तो यह zone को फिर से लागू करता है। इसे वहाँ भी set करें ताकि reboot आपके काम को न मिटा दे। पहले command से connection का नाम लें, क्योंकि यह शायद ही कभी device के नाम के समान होता है।

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

Source matching, interface matching से बेहतर काम करती है, यही कारण है कि एक address को अलग policy मिलती है। अंतर्निहित trusted zone सब कुछ स्वीकार करता है।

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

उस एक के साथ सावधान रहें। यह उस address के लिए सर्वर पर हर port खोल देता है, जिसमें वह database भी शामिल है जिसे आप private मानते थे। जब आप एक port चाहते हैं, न कि एक host, तो rich rule का उपयोग करें।

firewalld service क्या है?

एक service पोर्ट्स का एक नामित बंडल है जिसे 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 नाम के पीछे छिपे पोर्ट्स को प्रिंट करता है:

https
  ports: 443/tcp

जब कोई नाम मौजूद हो तो उसका उपयोग करें। यह छह महीने बाद --list-all में स्पष्ट रूप से पढ़ने में आता है, और Cockpit जैसे पैकेज अपनी स्वयं की service फ़ाइल इंस्टॉल करते हैं। जिसका कोई विवरण न हो उसके लिए --add-port का उपयोग करें।

ध्यान देने वाली कमी: ssh service का अर्थ केवल 22/tcp है और कुछ नहीं। यदि आपने सर्वर पर SSH एक्सेस को सुरक्षित करने के दौरान SSH को किसी अन्य पोर्ट पर स्थानांतरित कर दिया है, तो --add-service=ssh उस पोर्ट को नहीं खोलता है जिसका आप वास्तव में उपयोग कर रहे हैं।

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

RHEL रीबिल्ड पर उस दरवाजे पर दूसरा लॉक होता है। SELinux (security-enhanced Linux) पोर्ट नंबरों को लेबल करता है, और sshd को अपने लेबल के बाहर किसी पोर्ट से बाइंड करने की अनुमति नहीं है। तब यह स्टार्ट होने से मना कर देता है और लॉग में error: Bind to port 2222 on 0.0.0.0 failed: Permission denied. दिखाई देता है। पहले पोर्ट को लेबल करें।

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 क्या मानता है। तीसरी कमांड उन नियमों को पढ़ती है जो वास्तव में kernel के पास हैं, उस table में जिसका स्वामित्व firewalld के पास है। इन तीनों का परिणाम एक समान होना चाहिए।

इनमें से कोई भी अंतिम प्रमाण नहीं है। किसी दूसरी मशीन से परीक्षण करें:

nc -zv 203.0.113.20 443

परीक्षण को स्वयं सर्वर पर न चलाएं। firewalld loopback interface पर आने वाले सभी traffic को स्वीकार करता है, इसलिए curl http://localhost:8080 आपके नियमों के बावजूद सफल हो जाएगा। यह परीक्षण केवल यह बताता है कि 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 भी दिखाई देना चाहिए। यदि साइट अभी भी रिस्पॉन्स नहीं दे रही है, तो समस्या फायरवॉल में नहीं हो सकती है। एक नियम केवल पैकेट को अनुमति देता है। इसके लिए किसी प्रोसेस का लिसनिंग मोड में होना अभी भी आवश्यक है।

sudo ss -tlnp

0.0.0.0:443 या *:443 के रूप में दिखाया गया सॉकेट किसी भी एड्रेस से कनेक्शन स्वीकार करता है। 127.0.0.1:443 के रूप में दिखाया गया सॉकेट केवल लूपबैक पर उत्तर देता है, और कोई भी फायरवॉल नियम इसे बाहर से एक्सेस करने योग्य नहीं बना पाएगा। Linux पर पोर्ट और लिसनिंग सॉकेट्स इस अंतर को अधिक विस्तार से कवर करता है।

मैं किसी पोर्ट को दोबारा कैसे बंद करूँ?

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

यहाँ भी --permanent नियम लागू होता है, और इस दिशा में यह अधिक प्रभावी है। यदि आप किसी सर्विस को केवल रनटाइम से हटाते हैं, तो पोर्ट बंद दिखाई देगा, लेकिन अगली बार रीलोड या रीबूट करने पर यह सेव की गई फाइल से दोबारा खुल जाएगा। यह एक ऐसी खामी है जिसे आप नोटिस नहीं कर पाएंगे, क्योंकि आपके द्वारा चलाया गया चेक सफल रहा होगा।

ऐसी चीज़ को हटाना जो पहले से मौजूद नहीं थी, Warning: NOT_ENABLED: http प्रिंट करता है और फिर भी 0 के साथ एक्जिट होता है। एक ही चीज़ को दो बार जोड़ने पर Warning: ALREADY_ENABLED: http प्रिंट होता है। दोनों ही सुरक्षित हैं। गलत वर्तनी वाला नाम अलग है: Error: INVALID_SERVICE का अर्थ है कि firewalld के पास उस नाम की कोई परिभाषा नहीं है और कुछ भी बदला नहीं गया है।

यदि आपका --list-all यह दिखाता है कि cockpit खुला है और आप पोर्ट 9090 पर Cockpit वेब कंसोल का उपयोग नहीं करते हैं, तो इसे हटा दें। हर खुला पोर्ट एक ऐसी सर्विस है जिसे आपको पैच करते रहना होगा।

किसी पोर्ट को एक सोर्स एड्रेस तक सीमित करना

Rich rules विस्तृत निर्देश होते हैं, जिनका उपयोग तब किया जाता है जब कोई साधारण सर्विस नाम आपकी आवश्यकता को स्पष्ट न कर सके। SSH को केवल एक ऑफिस एड्रेस तक सीमित करने के लिए दो 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 अनुमतियों का एक समूह है, न कि कोई ऐसी क्रमिक सूची जो पहले मैच पर रुक जाए। Rich rule एक विशिष्ट एड्रेस के लिए accept जोड़ता है। यह किसी को deny नहीं करता है। जब तक ssh, services: लाइन में मौजूद है, तब तक पूरा इंटरनेट पोर्ट 22 तक पहुँच सकता है और rich rule से कोई भी मापने योग्य बदलाव नहीं होगा। व्यापक (broad) एंट्री को हटा दें, अन्यथा संकीर्ण (narrow) एंट्री केवल दिखावटी रह जाएगी।

बिना सर्विस नाम वाले पोर्ट के लिए, सर्विस के बजाय पोर्ट का नाम निर्दिष्ट करें।

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

किसी शोर मचाने वाले नेटवर्क को drop करने और उसका रिकॉर्ड रखने के लिए, log एलिमेंट को action से पहले रखें, क्योंकि rich rule भाषा इसी क्रम की अपेक्षा करती है।

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 मान पैकेट की बाढ़ को journal भरने से रोकता है। SSH को एक ही एड्रेस पर लॉक करने से पहले, सुनिश्चित करें कि वह एड्रेस स्थिर है। बदलते IP एड्रेस वाला होम कनेक्शन उस दिन आपको लॉक कर देगा जिस दिन वह बदल जाएगा, इसलिए पहले अपने प्रोवाइडर के console access का परीक्षण करें और सुनिश्चित करें कि वह काम कर रहा है।

ufw commands और उनके 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 इसका silent संस्करण है
• sudo ufw logging on का रूपांतरण sudo firewall-cmd --set-log-denied=all में होता है

एक अंतर को स्पष्ट रूप से बताना आवश्यक है। ufw एक क्रमांकित सूची रखता है और आप स्थिति 1 पर कोई नियम डाल सकते हैं। firewalld में कोई नियम संख्या नहीं होती है, इसलिए "इस नियम को सबसे पहले रखें" का यहाँ कोई अर्थ नहीं है। जब दो firewalld प्रविष्टियाँ एक-दूसरे का खंडन करती हुई प्रतीत होती हैं, तो व्यापक accept नियम जीत जाता है, क्योंकि सेट में कोई भी चीज़ deny नहीं करती है। आप स्वयं व्यापक प्रविष्टि को हटाते हैं।

मेरा Docker container तब भी क्यों पहुँच योग्य है जब firewall बंद दिख रहा है?

इसका कारण यह है कि एक published container port कभी भी firewall के उस हिस्से तक नहीं पहुँचता जिसे आपकी zone नियंत्रित करती है। docker run -d -p 8080:80 nginx Docker को अपने स्वयं के NAT (network address translation) और forwarding नियम लिखने का निर्देश देता है। 8080 पर आने वाला packet rewrite होकर container की ओर भेज दिया जाता है, इसलिए इसे host तक पहुँचाने के बजाय forward किया जाता है। आपकी zone में services: और ports: लाइनें केवल host तक पहुँचने वाले packets को नियंत्रित करती हैं। Docker के नियम forward path को नियंत्रित करते हैं, और वे इसे स्वीकार (accept) कर लेते हैं।

परिणामस्वरूप, एक ऐसा सर्वर मिलता है जहाँ sudo firewall-cmd --list-all में port 8080 नहीं दिखता, लेकिन किसी अन्य machine से nc -zv 203.0.113.20 8080 करने पर connection बन जाता है। देखें कि 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 सर्वर पर केवल curl http://127.0.0.1:8080 का उत्तर देता है और बाहर से कुछ भी नहीं। Ubuntu users भी इसी समस्या का सामना करते हैं, जिसका वर्णन why Docker containers publish ports straight past ufw में किया गया है। Rootful Podman, जो Rocky और AlmaLinux के base repositories में उपलब्ध है, समान NAT दृष्टिकोण के साथ ports publish करता है, इसलिए zone list पर भरोसा करने के बजाय किसी अन्य machine से test करें।

इसे रीबूट के बाद भी चालू रखना, और वे त्रुटियाँ जो आपको दिखाई देंगी

sudo systemctl is-enabled firewalld
sudo systemctl status firewalld

enabled और active (running) वे कमांड हैं जिनकी आपको आवश्यकता है। एक फायरवॉल जो चल तो रहा है लेकिन enabled नहीं है, वह पहले रीबूट तक ही आपकी सुरक्षा करता है। यह जाँच उस सूची में होनी चाहिए जिसे आप नए VPS पर पहले दस मिनट के दौरान पूरा करते हैं, SSH keys और अपडेट्स के साथ।

Raw nftables कमांड और firewalld एक साथ काम नहीं करते। firewalld का inet firewalld नामक टेबल पर स्वामित्व होता है। sudo nft flush ruleset इसे हटा देता है, जिसके बाद सर्वर हर चीज़ के लिए खुल जाता है, और firewall-cmd --list-all अभी भी आपके इच्छित कॉन्फ़िगरेशन को ही प्रिंट करता है, क्योंकि firewalld वही रिपोर्ट करता है जो वह मानता है, न कि वह जो kernel में वास्तव में मौजूद है। sudo firewall-cmd --reload नियमों को फिर से इंस्टॉल करता है। नियमों को firewall-cmd के साथ लिखें ताकि वे रीलोड के बाद वापस आ जाएं।

एक सर्वर पर दो फायरवॉल मैनेजर। firewalld के साथ ufw या iptables-services इंस्टॉल करने से आपको दो ऐसे प्रोग्राम मिल जाते हैं जो एक-दूसरे की जानकारी के बिना नियम लिखते हैं, और विजेता वह होता है जिसकी सर्विस अंत में शुरू होती है। किसी एक को चुनें। Rocky और AlmaLinux पर, firewalld ही वह है जिसे डिस्ट्रीब्यूशन का समर्थन प्राप्त है।

सर्वर के सामने प्रदाता का फायरवॉल। कई VPS पैनल में एक अलग नेटवर्क फायरवॉल होता है। यदि --list-all कोई पोर्ट खुला दिखाता है और बाहर से कनेक्शन फिर भी विफल रहता है, तो सर्वर पर कुछ भी बदलने से पहले पैनल की जाँच करें। यह दूसरी तरफ भी काम करता है: पैनल का खुला नियम तब तक कुछ नहीं करता जब तक firewalld पैकेट को अस्वीकार (reject) कर रहा हो।

sudo के बिना firewall-cmd चलाना। हर बदलाव के लिए root की आवश्यकता होती है। इसके बिना, ऑथराइजेशन चेक द्वारा अनुरोध को अस्वीकार कर दिया जाता है और कुछ भी संशोधित नहीं होता है, जो पहली नज़र में ऐसा लगता है जैसे कमांड को अनदेखा कर दिया गया हो।

छह कमांड अधिकांश दिनों के लिए पर्याप्त हैं: स्थिति पढ़ने के लिए --list-all, कुछ खोलने के लिए --permanent --add-service या --add-port, इसे बंद करने के लिए --permanent --remove-service, सहेजी गई फ़ाइल को लागू करने के लिए --reload, और प्रयोगों के दौर के बाद --runtime-to-permanent। ज़ोन public है, फ्लैग --permanent है, और एकमात्र सटीक जाँच किसी अन्य मशीन से ही होती है।

FAQ

Reboot के बाद मेरा firewalld rule क्यों गायब हो गया?

यह 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 को सेव की गई फाइल में कॉपी कर देता है।

--permanent के साथ rule जोड़ने के बाद भी कुछ क्यों नहीं बदलता?

क्योंकि --permanent फाइल में लिखता है और चल रहे firewall को प्रभावित नहीं करता है। port तब तक बंद रहता है जब तक sudo firewall-cmd --reload सेव की गई configuration को kernel में लोड नहीं करता। 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 को कवर करता है। जब आपकी service के लिए कोई परिभाषा न हो, या वह non-standard port पर listen कर रही हो, तो --add-port का उपयोग करें। ssh service का मतलब केवल 22/tcp है, इसलिए यदि SSH को 2222 पर ले जाया गया है, तो --add-port=2222/tcp के साथ उस port के लिए एक SELinux label की भी आवश्यकता होगी।

firewall-cmd में port बंद दिखाने के बावजूद मेरा Docker container कैसे पहुँच योग्य है?

Published port को Docker के अपने NAT rules द्वारा rewrite किया जाता है और container तक forward किया जाता है, इसलिए packet कभी host तक नहीं पहुँचता है। zone की service और port सूचियाँ केवल उन packets को कवर करती हैं जो host तक पहुँचते हैं। container internet से जवाब देता है जबकि --list-all कुछ नहीं दिखाता है। इसके बजाय docker run -d -p 127.0.0.1:8080:80 nginx के साथ loopback पर publish करें और उसके सामने एक reverse proxy रखें।

क्या मैं firewalld के बजाय Rocky Linux पर ufw इंस्टॉल कर सकता हूँ?

एक ही सर्वर पर दो firewall managers एक-दूसरे की जानकारी के बिना rules लिखते हैं, और कौन सा set प्रभावी रहेगा यह इस पर निर्भर करता है कि कौन सी service अंत में शुरू हुई। firewalld, Rocky Linux और AlmaLinux पर समर्थित टूल है, यह पहले से इंस्टॉल होता है, और यह उसी nftables backend को चलाता है जिसे ufw चलाता। default zone और --permanent flag को एक बार सीख लें, तो आप पूरे टूल को समझ जाएंगे।