شرح firewalld على خادم Rocky أو AlmaLinux

ماهية firewalld وسبب تضمينه في Rocky وAlmaLinux

firewalld هو مدير جدار الحماية المثبّت افتراضياً في Rocky Linux وAlmaLinux والإصدارات الأخرى المعاد بناؤها من Red Hat Enterprise Linux (RHEL). ورث التوزيعان هذا الخيار الافتراضي بدلاً من اختياره، ويصبح ذلك أكثر منطقية بعد معرفة كيف أعاد Rocky وAlmaLinux بناء عمل Red Hat بعد تغيير CentOS لمساره. لا يفحص الحزم بنفسه. بل يحتفظ بإعداد محفوظ ويحوّل هذا الإعداد إلى قواعد nftables. ويعدّل الأمر firewall-cmd هذه القواعد بينما يظل الخادم متصلاً بالإنترنت. لا يتغير شيء في هذا الدليل بين التوزيعين، لأن الأمور التي تميّز Rocky عن AlmaLinux فعلياً هي وعد التوافق ونطاق المعالجات التي لا تزال مدعومة، وليس جدار الحماية.

إذا كنت تعرف مسبقاً كيفية عمل ufw على خادم Ubuntu افتراضي، فأنت تعرف وظيفته الأساسية. يضيف firewalld مفهومين لا يوفرهما ufw. الأول هو المناطق: سياسة مسماة تُصنَّف الحزم ضمنها. والثاني هو الفصل بين القواعد النشطة والقواعد المحفوظة، ويمثله الخيار --permanent، وهو أكبر مصدر للالتباس في هذه الأداة.

كل ما يلي عبارة عن أوامر تشغّلها على خادمك بنفسك. اختبر كل تغيير من جهاز ثانٍ، لأن القاعدة التي تبدو صحيحة على الخادم قد تظل خاطئة عند الوصول من الإنترنت.

افتح SSH قبل تنفيذ أي شيء آخر

تكون firewalld موجودة وقيد التشغيل في معظم عمليات تثبيت Rocky وAlmaLinux، كما يسمح الإعداد المُضمَّن باتصالات 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:

وجود ssh في السطر services: هو سبب استمرار جلستك في العمل. إذا كان مفقوداً، فأضِفه قبل تنفيذ أي شيء آخر، لأن تشغيل جدار ناري من دون قاعدة 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 بإعدادين في الوقت نفسه. يحدد إعداد التشغيل القواعد التي يفرضها kernel في هذه اللحظة. أما الإعداد الدائم، فيُحفظ في /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 فيعيد تحميل وحدات kernel أيضاً ويفقد تلك الحالة، ما يؤدي عادةً إلى إنهاء كل الاتصالات المفتوحة، بما فيها اتصالك. استخدم إعادة التحميل العادية.

تتضمن firewalld وسيلة أمان تلقائية. يمكن لقاعدة تشغيلية أن تنتهي تلقائياً.

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

تزيل هذه القاعدة نفسها بعد خمس دقائق. ولا يمكن دمجها مع --permanent، وهذا هو الهدف منها: اختبار تغيير لست متأكداً منه. لكن وسيلة الأمان الأقدم أفضل. أبقِ جلسة SSH ثانية مفتوحة أثناء تعديل القواعد، ولا تغلقها حتى يثبت تسجيل دخول جديد أن القواعد الجديدة تعمل.

المناطق، ولماذا تهم المنطقة الافتراضية وحدها على VPS

المنطقة هي مجموعة مسمّاة من الأذونات مرتبطة بمستوى ثقة. يضع firewalld كل حزمة واردة في منطقة واحدة فقط. ويطابق عنوان مصدر الحزمة مع قائمة sources: الخاصة بكل منطقة أولاً. إذا لم يحدث أي تطابق، يستخدم المنطقة المرتبطة بها واجهة الشبكة الواردة. وإذا لم تكن الواجهة مرتبطة بأي منطقة، تنتقل الحزمة إلى المنطقة الافتراضية.

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

على VPS ذي واجهة شبكة واحدة، تكون الإجابة الأولى في الغالب public، وهذه هي المنطقة الوحيدة التي ستستخدمها. يعمل firewall-cmd من دون وسيطة --zone= على المنطقة الافتراضية، ولذلك تعمل كل الأوامر المختصرة في هذا الدليل من دون تحديد منطقة.

إليك الخطأ الذي قد يهدر فترة بعد الظهر. إذا كانت الواجهة مرتبطة بمنطقة أخرى، فستُطبَّق قواعدك في public بينما تُعالَج حركة الشبكة في مكان آخر، لذلك لن يؤثر أي شيء تضيفه ولن يظهر أي تحذير. يعرض --get-active-zones الارتباط:

public
  interfaces: eth0

إذا ظهرت الواجهة تحت اسم منطقة مختلف، فاكتب قواعدك فيها باستخدام --zone=، أو انقل الواجهة.

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

يدير NetworkManager الواجهات على Rocky وAlmaLinux، ويعيد فرض المنطقة عند تفعيل الاتصال. اضبطها هناك أيضاً حتى لا يؤدي إعادة التشغيل إلى التراجع عن عملك. خذ اسم الاتصال من الأمر الأول، لأنه نادراً ما يكون مطابقاً لاسم الجهاز.

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

تتغلب مطابقة المصدر على مطابقة الواجهة، وهذا ما يتيح تطبيق سياسة مختلفة على عنوان واحد. تقبل المنطقة المضمّنة trusted كل شيء.

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

انتبه عند استخدام هذه المنطقة. فهي تفتح كل منفذ على الخادم لذلك العنوان، بما في ذلك قاعدة البيانات التي كنت تظن أنها خاصة. استخدم قاعدة غنية عندما تريد فتح منفذ واحد، لا مضيف واحد.

ما هي خدمة firewalld؟

الخدمة هي مجموعة مسماة من المنافذ، تُوفَّر في ملف 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 ملف الخدمة الخاص بها. استخدم --add-port لأي شيء لا يملك تعريفاً.

انتبه إلى هذه الفجوة: تعني خدمة ssh المنفذ 22/tcp ولا شيء آخر. إذا نقلت SSH إلى منفذ آخر أثناء تشديد الوصول إلى SSH على الخادم، فلن يفتح --add-service=ssh المنفذ الذي تستخدمه فعلياً.

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

عند إعادة بناء نظام RHEL، توجد طبقة تقييد ثانية. يضع SELinux (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 فعلياً، ضمن الجدول الذي يديره firewalld. يجب أن تتطابق النتائج.

لكن لا يثبت أيٌّ من ذلك شيئاً. اختبر من جهاز آخر:

nc -zv 203.0.113.20 443

لا تُجرِ الاختبار على الخادم نفسه. يقبل firewalld كل ما يصل عبر واجهة loopback، لذلك ينجح curl http://localhost:8080 مهما كانت القواعد التي ضبطتها. يوضح هذا الاختبار أن الخدمة تعمل. لكنه لا يخبرك بأي شيء عن جدار الحماية.

السماح بمنفذ الويب

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 فيستجيب عبر loopback فقط، ولن تجعل أي قاعدة جدار ناري هذا المنفذ متاحاً من خارج الخادم. يشرح المنافذ والمقابس التي تستمع على 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، ولم تكن تستخدم وحدة تحكم Cockpit على الويب عبر المنفذ 9090، فأزله. كل منفذ مفتوح يمثل خدمة يجب أن تحافظ على تحديثها الأمني، وبالنسبة إلى الخدمات التي تقرر إبقاءها، يمكن لـdnf-automatic تثبيت التحديثات الأمنية وفق مؤقت، بحيث لا تعتمد هذه المهمة على تذكّرك لها. لكن تثبيت التصحيح ليس مماثلاً لتشغيله، إذ يوضح needs-restarting الخدمات التي لا تزال تستخدم المكتبات القديمة بعد تثبيت هذه التحديثات.

قيِّد منفذاً بعنوان مصدر واحد

القواعد الغنية هي الصيغة المطوّلة، وتُستخدم عندما لا يستطيع اسم خدمة عادي التعبير عما تريده. يتطلب تقييد SSH على عنوان مكتب واحد أمرين، والثاني هو الذي ينساه الناس عادةً.

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

المنطقة هي مجموعة من الصلاحيات، وليست قائمة مرقّمة تتوقف عند أول تطابق. تضيف القاعدة الغنية سماحاً لعنوان واحد. ولا تمنع أي عنوان آخر. ما دام ssh موجوداً في سطر services:، فسيظل الإنترنت بأكمله يصل إلى المنفذ 22، ولن تغيّر القاعدة الغنية شيئاً يمكن قياسه. أزل الإدخال العام، وإلا أصبحت القاعدة المقيّدة بلا تأثير.

إذا لم يكن للمنفذ اسم خدمة، فاذكر المنفذ نفسه.

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

لإسقاط شبكة صاخبة والاحتفاظ بسجل، ضع عنصر السجل قبل الإجراء. هذا هو الترتيب الذي تتطلبه لغة القواعد الغنية.

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 الخاص به من الوصول في يوم تغيّره، لذلك اختبر أولاً إمكانية الوصول إلى وحدة تحكم الموفر وتأكد من عملها.

أوامر 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، و--set-target=DROP هو الإصدار الصامت منه
• يتحول sudo ufw logging on إلى sudo firewall-cmd --set-log-denied=all

يجدر توضيح فرق واحد صراحةً. يحتفظ ufw بقائمة مرقمة، ويمكنك إدراج قاعدة في الموضع 1. لا يملك firewalld أرقاماً للقواعد، لذلك لا معنى لعبارة «ضع هذه القاعدة أولاً» هنا. عندما تبدو إدخالات firewalld متعارضة، تسود قاعدة السماح العامة، لأن المجموعة لا تتضمن أي قاعدة رفض. عليك إزالة الإدخال العام بنفسك.

لماذا يمكن الوصول إلى حاوية Docker عندما يبدو الجدار الناري مغلقاً؟

لأن منفذ الحاوية المنشور لا يمر أبداً عبر الجزء من الجدار الناري الذي تتحكم فيه منطقتك. يطلب docker run -d -p 8080:80 nginx من Docker كتابة قواعد NAT (ترجمة عناوين الشبكة) وإعادة التوجيه الخاصة به. يُعاد توجيه الحزمة التي تصل إلى 8080 وتُرسل إلى الحاوية، لذلك تُعاد توجيهها بدلاً من تسليمها إلى المضيف. تتحكم سطورا services: وports: في منطقتك بالحزم المسلّمة إلى المضيف. أما قواعد Docker فتتحكم في مسار إعادة التوجيه، وتقبل الحزم.

النتيجة خادم يعرض فيه sudo firewall-cmd --list-all عدم وجود منفذ 8080، بينما يتصل nc -zv 203.0.113.20 8080 من جهاز آخر على أي حال. اعرض ما ثبّته Docker:

sudo iptables -t nat -L DOCKER -n

يوجد الإصلاح في خيار النشر. اربط المنفذ بواجهة loopback وضع reverse proxy أمامه.

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

تستجيب الحاوية الآن لـ curl http://127.0.0.1:8080 على الخادم، ولا تستجيب لأي اتصال من خارج الخادم. يواجه مستخدمو Ubuntu المشكلة نفسها، كما هو موضح في لماذا تنشر حاويات Docker المنافذ مباشرة متجاوزة ufw. ينشر Podman بصلاحيات root، الذي توفره Rocky وAlmaLinux في المستودعات الأساسية، المنافذ باستخدام أسلوب NAT نفسه. لذلك اختبر من جهاز آخر بدلاً من الوثوق بقائمة المنطقة. وهذا التداخل هو أيضاً سبب حاجة تثبيت Docker Engine على هذه التوزيعات إلى بضع خطوات لا يذكرها دليل Ubuntu، بدءاً من امتلاك Podman للأمر docker مسبقاً.

جعل الإعدادات تستمر بعد إعادة التشغيل، والأخطاء التي ستراها

sudo systemctl is-enabled firewalld
sudo systemctl status firewalld

enabled وactive (running) هما ما تحتاج إليه. يحميك جدار ناري قيد التشغيل لكنه غير مفعّل حتى أول إعادة تشغيل فقط. يجب أن يكون هذا الفحص ضمن قائمة الخطوات التي تنفذها خلال الدقائق العشر الأولى على VPS جديد، إلى جانب مفاتيح SSH والتحديثات.

لا تخلط أوامر nftables الخام مع firewalld. يملك firewalld جدولاً يسمى inet firewalld. يحذفه sudo nft flush ruleset، فيصبح الخادم مكشوفاً لكل الاتصالات، بينما يظل firewall-cmd --list-all يعرض إعداداتك المقصودة، لأن firewalld يعرض ما يعتقد أنه مطبّق، لا ما يحتفظ به kernel فعلياً. يعيد sudo firewall-cmd --reload تثبيت القواعد. اكتب القواعد باستخدام firewall-cmd كي تعود بعد إعادة التحميل.

استخدام مديري جدار ناري على خادم واحد. يؤدي تثبيت ufw أو iptables-services إلى جانب firewalld إلى وجود برنامجين يكتبان القواعد من دون معرفة أحدهما بالآخر، ويتوقف البرنامج الفعّال على الخدمة التي بدأت أخيراً. اختر واحداً منهما. في Rocky وAlmaLinux، يحظى firewalld بدعم التوزيعة.

جدار الحماية لدى مزود الخدمة أمام الخادم. تحتوي كثير من لوحات VPS على جدار حماية شبكي منفصل. إذا أظهر --list-all أن منفذاً مفتوح، وفشل اتصال من خارج الخادم، فتحقق من اللوحة قبل تغيير أي شيء على الخادم. وينطبق العكس أيضاً: لا تؤثر قاعدة مفتوحة في اللوحة عندما يرفض firewalld الحزمة.

تشغيل firewall-cmd من دون sudo. يتطلب كل تغيير صلاحيات root. من دونها، يرفض فحص التفويض الطلب ولا يُعدَّل أي شيء، وقد يبدو للوهلة الأولى أن الأمر جرى تجاهله.

تغطي ستة أوامر معظم الاستخدامات اليومية: --list-all لعرض الحالة، و--permanent --add-service أو --add-port لفتح شيء، و--permanent --remove-service لإغلاقه، و--reload لتطبيق الملف المحفوظ، و--runtime-to-permanent بعد إجراء مجموعة من التجارب. المنطقة هي public، والعلامة هي --permanent، ولا يأتي الفحص الموثوق إلا من جهاز آخر.

FAQ

لماذا اختفت قاعدة firewalld بعد إعادة التشغيل؟

أُضيفت القاعدة إلى إعدادات التشغيل فقط. يطبّق sudo firewall-cmd --add-service=http القاعدة فوراً، لكن تُحذف عند إعادة التحميل أو الإقلاع التالي، لأن الإعدادات المحفوظة في /etc/firewalld/zones/public.xml لم تتغير. أضف --permanent، ثم شغّل sudo firewall-cmd --reload. للاحتفاظ بالقواعد التي أضفتها يدوياً، شغّل sudo firewall-cmd --runtime-to-permanent، فهذا ينسخ المجموعة النشطة إلى الملف المحفوظ.

لماذا لا يتغير شيء بعد إضافة قاعدة باستخدام --permanent؟

لأن --permanent يكتب القاعدة في الملف ولا يغيّر جدار الحماية قيد التشغيل. يظل المنفذ مغلقاً إلى أن يحمّل sudo firewall-cmd --reload الإعدادات المحفوظة في النواة. قارن sudo firewall-cmd --list-services مع sudo firewall-cmd --permanent --list-services. إذا احتوت القائمة المحفوظة على إدخال غير موجود في القائمة النشطة، فأنت تحتاج إلى إعادة التحميل.

هل أستخدم --add-service أم --add-port؟

استخدم --add-service عندما يوجد اسم للخدمة التي تشغّلها. يوضح ذلك الغرض، ويعرض sudo firewall-cmd --info-service=https المنافذ التي يغطيها الاسم بدقة. استخدم --add-port عندما لا يعرّف شيء خدمتك، أو عندما تستمع على منفذ غير قياسي. تعني خدمة ssh المنفذ 22/tcp فقط، لذلك يتطلب نقل SSH إلى 2222 استخدام --add-port=2222/tcp، بالإضافة إلى تسمية SELinux لهذا المنفذ.

لماذا يمكن الوصول إلى حاوية Docker لدي رغم أن firewall-cmd يعرض المنفذ مغلقاً؟

يعيد Docker كتابة المنفذ المنشور باستخدام قواعد NAT الخاصة به، ثم يوجّه الحزم إلى الحاوية. لذلك لا تُسلَّم الحزمة إلى المضيف، كما أن قوائم الخدمات والمنافذ في المنطقة تغطي فقط الحزم التي تُسلَّم إلى المضيف. تستجيب الحاوية من الإنترنت، بينما لا يعرض --list-all أي شيء. انشر المنفذ على loopback بدلاً من ذلك باستخدام docker run -d -p 127.0.0.1:8080:80 nginx، وضع reverse proxy أمامها.

هل يمكنني تثبيت ufw على Rocky Linux بدلاً من firewalld؟

يكتب مديرا جدار حماية على خادم واحد قواعدهما من دون معرفة أحدهما بالآخر، ويعتمد تحديد المجموعة التي تبقى على الخدمة التي بدأت أخيراً. يُعد firewalld الأداة المدعومة على Rocky Linux وAlmaLinux، وهو مثبت مسبقاً، ويستخدم واجهة nftables الخلفية نفسها التي كان سيستخدمها ufw. تعلّم المنطقة الافتراضية والعَلَمة --permanent مرة واحدة، وستمتلك كل ما تحتاج إليه من الأداة.