أساسيات firewalld لخادم Rocky أو AlmaLinux VPS

ما هو firewalld، ولماذا يأتي مضمّناً في Rocky وAlmaLinux

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

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

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

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

تكون firewalld موجودة وتعمل مسبقاً في معظم عمليات تثبيت Rocky وAlmaLinux، كما يسمح الإعداد المرفق باتصالات SSH. لكن بعض صور السحابة minimal تزيلها. تحقّق بدلاً من الافتراض.

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

توجد آلية أمان مضمّنة. يمكن لقاعدة في إعداد التشغيل أن تنتهي تلقائياً.

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، فأزله. كل منفذ مفتوح هو خدمة يجب أن تحافظ على تحديثها الأمني.

تقييد منفذ بعنوان مصدر واحد

القواعد الغنية هي الصيغة المطوّلة، وتُستخدم عندما لا يكفي اسم خدمة عادي للتعبير عن المطلوب. يتطلب تقييد 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 تدفقاً كبيراً من الحزم من ملء السجل. قبل تقييد 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 يصبح القاعدة الغنية الموضحة أعلاه
• 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 نفسه. لذلك اختبر من جهاز آخر بدلاً من الاعتماد على قائمة المنطقة.

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

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 رغم أن firewalld-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 مرة واحدة، وستكون لديك الأداة كاملة.