استعد الوصول بعد تعطّل قواعد ufw

العودة أولاً

إذا منعك ufw من الوصول إلى VPS، فطريقة العودة هي استخدام وحدة تحكم المزوّد أو وضع الإنقاذ، لأنه لا يوجد إصلاح عبر SSH بعد تفعيل قاعدة الحظر. تُسقط النواة حزمة الشبكة قبل أن يراها sshd، لذلك لا يوجد ما يمكنك تسجيل الدخول إليه ولا ما يمكنك إصلاحه عبر الشبكة. افتح وحدة التحكم من لوحة تحكم المزوّد، وسجّل الدخول عند موجّه الأوامر، ثم نفّذ أمراً واحداً.

sudo ufw disable

يُفترض أن ترى Firewall stopped and disabled on system startup. ستعمل اتصالات SSH الجديدة مجدداً خلال ثانية أو ثانيتين. لا يضيع أي شيء مما ضبطته: يزيل disable القواعد من النواة ويكتب ENABLED=no في /etc/ufw/ufw.conf، بينما تبقى قواعدك على القرص في /etc/ufw/user.rules، بانتظار عملية ufw enable التالية.

لا تعِد التشغيل على أمل أن تُحل المشكلة. يبدأ ufw تلقائياً عند الإقلاع، لذلك يعني ENABLED=yes تحميل مجموعة القواعد نفسها مجدداً قبل تشغيل الشبكة. لا يغيّر إعادة التشغيل شيئاً في حالة فقدان الوصول بسبب ufw.

تتطلب وحدة التحكم كلمة مرور قد لا تملكها

وحدة التحكم عبر الويب، سواء كانت VNC أو تسلسلية، هي لوحة مفاتيح متصلة بالجهاز. وليست مساراً شبكياً، لذلك لا يمكن لأي قاعدة جدار ناري حجبها. لكنها تتطلب تسجيل دخول محلياً، وهنا تفشل إعدادات المصادقة بالمفتاح فقط: إذا لم تعيّن كلمة مرور لمستخدم sudo، وكان تسجيل دخول root مقفلاً، فستعرض وحدة التحكم مطالبة لا يمكنك الإجابة عنها. عيّن كلمة المرور الآن، ما دمت لا تزال متصلاً عبر SSH: sudo passwd yourname. ويمكن لمعظم لوحات التحكم أيضاً إعادة تعيين كلمة مرور root، وهذا يؤدي عادةً إلى إعادة التشغيل.

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

lsblk
sudo mount /dev/vda1 /mnt
sudo sed -i 's/^ENABLED=yes/ENABLED=no/' /mnt/etc/ufw/ufw.conf
sudo umount /mnt

نفّذ lsblk أولاً، لأن قسم root ليس دائماً /dev/vda1. أعد التشغيل إلى النظام العادي، وسيبقى ufw معطلاً إلى أن تفعّله يدوياً.

تسلسل الاسترداد الأدنى

نفّذ الخطوات بهذا الترتيب. الخطوات الأربع الأولى آمنة. أما الخطوة التالية فليست آمنة.

1. sudo ufw disable لإلغاء تحميل القواعد واستعادة وصولك.
2. sudo ufw show added لطباعة القواعد التي أضفتها بصيغة الأوامر التي أضافتها. يعمل هذا الأمر بينما تكون ufw غير مفعّلة، بخلاف ufw status.
3. sudo sshd -T | grep -i '^port' للتأكد من المنفذ الذي يستمع عليه sshd فعلياً. يطبع port 22 ما لم تغيّره.
4. sudo ufw allow 22/tcp باستخدام منفذك الفعلي، حتى لا تؤدي عملية التفعيل التالية إلى تكرار فقدان الوصول.
5. sudo ufw enable بعد جدولة التراجع أولاً. يرد شرح ذلك لاحقاً في هذه الصفحة.

ما الذي يفعله ufw reset فعلياً

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

Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'

بعد إعادة الضبط، لن تتضمن القواعد أي قواعد سماح، لذلك نفّذ الأمر من وحدة التحكم بدلاً من تنفيذه عبر SSH، وأضف قاعدة SSH قبل إعادة التمكين. تكون هذه النسخ الاحتياطية نصية عادية. يعرض sudo grep -n dport /etc/ufw/user.rules.20260813_101500 القواعد القديمة، وبذلك يمكنك إعادة بناء مجموعة قواعد لم تكن تقصد حذفها.

موضع احتفاظ ufw بقواعده

تساعد قراءة الملفات على تجنب التخمين. تحتوي خمسة مسارات على الحالة الكاملة:

• /etc/ufw/user.rules و/etc/ufw/user6.rules: القواعد التي أضفتها، بالترتيب الذي تُقيَّم به.
• /etc/ufw/before.rules و/etc/ufw/after.rules، إضافة إلى المتغيرات 6: الإطار الذي يغلّفه ufw حول قواعدك، بما في ذلك قاعدة السماح للاتصالات القائمة وقواعد loopback.
• /etc/default/ufw: السياسات الافتراضية ومفتاح IPV6.
• /etc/ufw/ufw.conf: ENABLED ومستوى السجل.
• /var/log/ufw.log: ما جرى حظره بعد تفعيل التسجيل.

ينشئ ufw نسخة مؤرخة من الملف قبل إعادة كتابته، لذلك يمتلئ ls /etc/ufw/ بأسماء مثل user.rules.20260813_101500. هذا هو سجل التراجع، ومن المفيد قراءته قبل البدء في إعادة تغيير الإعدادات.

لعرض ما حُمِّل في kernel بدلاً مما هو موجود على القرص، استخدم sudo ufw show raw، أو sudo iptables -S وsudo ip6tables -S. في Ubuntu 22.04 و24.04، هذه الأوامر هي الإصدارات المدعومة من nft، لذلك يعرض sudo nft list ruleset القواعد نفسها بالصياغة الأحدث.

لماذا أدّى تفعيل ufw إلى قطع جلسة SSH؟

تكون السياسة الافتراضية للاتصالات الواردة هي الرفض. يؤدي تفعيل ufw من دون قاعدة لمنفذ SSH إلى قطع كل اتصال جديد. يعرض ufw تحذيراً أيضاً: Command may disrupt existing ssh connections. Proceed with operation (y|n)? إن الإجابة عن y من دون وجود قاعدة سماح لـSSH هي السبب الأكثر شيوعاً لكل ما يرد في هذه الصفحة.

الجزء المربك هو التأخير. يقبل /etc/ufw/before.rules الحزمَ التي تكون حالتها ESTABLISHED,RELATED قبل تطبيق قواعدك، لذلك تستمر الجلسة التي نفذت فيها الأمر بالعمل بصورة طبيعية. لا يظهر انقطاع الوصول إلا عند إنشاء الاتصال التالي، وقد يحدث ذلك بعد ساعات. عندها قد لا يبدو تغيير الجدار الناري مرتبطاً بالمشكلة. افتح دائماً جلسة SSH ثانية وتأكد من أنها تعمل قبل إغلاق الجلسة الأولى.

لماذا توقّف apt وDNS عن العمل بعد تغيير إحدى السياسات؟

تحظر sudo ufw default deny outgoing استعلامات DNS الصادرة وتحظر HTTP الصادر، لذلك يتوقف تحليل الأسماء وتتوقف تحديثات الحزم. تُظهر apt update ‏Temporary failure resolving 'archive.ubuntu.com'. يظل SSH الوارد يعمل، لأن ردوده تكون في حالة ESTABLISHED وتسمح بها قواعد الإطار، ما يجعل جدار الحماية يبدو غير مسؤول عن المشكلة، مع أنه سببها.

إذا أردت تطبيق سياسة لمنع الاتصالات الصادرة، فاسمح بالاتصالات التي تحتاج إليها الآلة فعلياً:

sudo ufw allow out 53
sudo ufw allow out 80/tcp
sudo ufw allow out 443/tcp
sudo ufw allow out 123/udp

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

لماذا لا تنطبق قاعدة ufw لدي مطلقاً؟

يقيّم ufw قواعد المستخدم بالترتيب ويتوقف عند أول تطابق. لا تُطبَّق قاعدة deny تُضاف بعد قاعدة allow عامة، لأن قاعدة السماح تكون قد حسمت مصير الحزمة مسبقاً. اعرض الترتيب مع أرقامه، ثم أدرج القاعدة في الموضع المطلوب.

sudo ufw status numbered
sudo ufw insert 1 deny from 203.0.113.10 to any port 22
sudo ufw delete 4

يطبع sudo ufw --dry-run allow 8080/tcp القواعد التي ستُكتب، ولا يغيّر أي شيء. هذه هي الطريقة الآمنة لقراءة القاعدة قبل تفعيلها.

يوجد فخ آخر في ملفات تعريف التطبيقات. يستخدم sudo ufw allow OpenSSH ملف التعريف الموجود في /etc/ufw/applications.d/openssh-server، ويعني ذلك الملف المنفذ 22. إذا كان sshd يستمع على 2222، تفتح القاعدة منفذاً لا تستخدمه أي خدمة، وقد تمنع وصولك إلى الخادم رغم أن مجموعة القواعد تبدو صحيحة. استخدم رقم المنفذ بعد تغييره. يشرح دليل أساسيات جدار ufw الناري لخادم VPS بقية الصياغة.

لماذا لا تفسّر قواعد IPv4 ما أراه؟

لأن نصف حركة الشبكة ليس عبر IPv4. يضم Ubuntu IPV6=yes في /etc/default/ufw، ثم يحتفظ ufw بمجموعة قواعد IPv6 موازية في /etc/ufw/user6.rules. القاعدة المكتوبة بعنوان IPv4، مثل ufw allow from 203.0.113.10 to any port 22، لا تنشئ أي قاعدة لـIPv6. إذا كان لدى VPS سجل AAAA، وكان العميل يفضّل IPv6، فستنتهي مهلة الاتصال بينما يعرض ufw status قاعدة تبدو صحيحة. اختبر الفرق باستخدام ssh -4 user@host مقابل ssh -6 user@host. إذا نجح الاختبار الأول وفشل الثاني، فالمشكلة في مجموعة قواعد IPv6.

الحالة العكسية أسوأ من ناحية الأمان. عند استخدام IPV6=no، لا يدير ufw ip6tables إطلاقاً، ولذلك تبقى سياسة IPv6 على القيمة الافتراضية ACCEPT في kernel. سيستجيب منفذ تعتقد أنه مغلق على عنوان IPv6 الخاص به، ولن يذكره أي أمر من أوامر ufw. تحقّق باستخدام sudo ip6tables -S وss -tlnp، واقرأ كيفية تعامل ufw مع منافذ IPv6 لفهم الصورة كاملة.

لماذا يكون منفذ Docker مفتوحاً رغم أن ufw يحظره؟

ينشر Docker المنفذ بكتابة قواعد DNAT ‏(ترجمة عنوان الشبكة الوجهة) في جدول nat، وإدراج سلسلة خاصة به في FORWARD. توجد قواعد ufw في مسار INPUT. تُمرَّر حركة الشبكة المتجهة إلى الحاوية بدلاً من تسليمها إلى الخادم، لذلك لا تصل إلى السلسلة التي توجد فيها قاعدة الحظر. يمكن الوصول إلى docker run -p 5432:5432 من الإنترنت مع تفعيل ufw وحظره لكل الاتصالات.

sudo iptables -t nat -S DOCKER

أبسط حل هو النشر على loopback: يربط -p 127.0.0.1:5432:5432 جانب الخادم بالعنوان 127.0.0.1، ولا يمكن لأي جهة خارجية الوصول إليه بغض النظر عن إعدادات ufw. يشرح نشر Docker للمنافذ متجاوزاً ufw الحالات التي يجب أن تكون فيها الخدمة عامة.

حدّد التراجع قبل تطبيق القاعدة

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

sudo systemd-run --on-active=5m --unit=ufw-rollback /usr/sbin/ufw disable

يطبع systemd القيمة Running timer as unit: ufw-rollback.timer. طبّق التغيير الآن. إذا ظل بإمكانك فتح جلسة SSH جديدة بعد ذلك، فألغِ التراجع:

sudo systemctl stop ufw-rollback.timer

إذا لم تتمكن من فتح تلك الجلسة، فانتظر. سيتوقف ufw تلقائياً، وستنجح محاولتك التالية في الاتصال. لا تفيد حيلة shutdown -r +5 التقليدية مع ufw، لأن ufw يحمّل مجموعة القواعد نفسها مرة أخرى عند الإقلاع.

احتفظ بطريقة وصول ثانية

• سجّل الدخول إلى لوحة تحكم مزوّد الخدمة مرة واحدة قبل أن تحتاج إليها، وتحقّق من أن كلمة المرور تعمل. وحدة تحكم لم تختبرها من قبل ليست وسيلة احتياطية.
• احتفظ بمستخدم sudo ثانٍ مع مفتاحه الخاص، حتى لا يؤدي تعطل ملف authorized_keys واحد إلى فقدان الوصول بالكامل.
• تحقّق مما إذا كان مزوّد الخدمة يشغّل جداراً نارياً للشبكة من لوحة التحكم، بشكل منفصل عن ufw. فهو يحظر المنافذ نفسها، ولن يذكره ufw status أبداً.
• لا تجعل ufw allow from <your home address> قاعدة SSH الوحيدة إذا كان ذلك العنوان ديناميكياً. قد يغيّره مزوّد الخدمة أثناء الليل، وعندها ستفقد الوصول.

أقل وقت تكلفة لتنفيذ كل ذلك هو عند إعداد خادم جديد، بالتزامن مع أعمال الإعداد الأخرى في الدقائق العشر الأولى على VPS جديد.

الرفض أو انتهاء المهلة يحددان الطبقة التي حدث فيها الفشل

Connection refused يعني أن حزمة وصلت إلى الخادم وأن جهة ما أرسلت استجابة TCP لإعادة الضبط. مسار الشبكة سليم، لذلك تكون خدمة sshd متوقفة أو تستمع على منفذ مختلف. نادراً ما يكون الجدار الناري هو السبب، لأن ufw يُسقط الاتصالات افتراضياً بدلاً من رفضها.

Connection timed out يعني أن شيئاً لم يعد على الإطلاق. هذه علامة على إسقاط الاتصال: قد يكون السبب ufw، أو جداراً نارياً في شبكة موفّر الخدمة، أو عنواناً غير صحيح. تساعدك قراءة هذين الخطأين بشكل صحيح على تجنّب التخمين لمدة ساعة، وتوضّح الفرق بين رفض الاتصال وانتهاء المهلة الحالات المتبقية.

فعِّل التسجيل قبل التغيير التالي

sudo ufw logging on
sudo tail -f /var/log/ufw.log

تظهر الحزمة المحظورة بهذا الشكل:

[UFW BLOCK] IN=eth0 OUT= SRC=203.0.113.10 DST=192.0.2.5 LEN=60 PROTO=TCP SPT=51234 DPT=22 WINDOW=64240 SYN

يشير DPT=22 مع عنوانك الخاص في SRC= إلى أن ufw هو الذي يحظرك، وليس الشبكة ولا sshd. في صورة نظام minimal لا تحتوي على rsyslog، لا يوجد /var/log/ufw.log، وتصدر الأسطر نفسها من sudo journalctl -k | grep UFW. يحدّ ufw معدل قواعد التسجيل الخاصة به، لذلك لا يثبت غياب السطر أن الحزمة سُمِح لها بالمرور.

إذا وجدت قواعد لم تضفها قط

مجموعة القواعد التي تغيّرت من تلقاء نفسها ليست مشكلة في الجدار الناري. لقد كتبها شخص لديه صلاحيات root. شغّل sudo grep ufw /var/log/auth.log لمعرفة أوامر sudo التي نُفّذت والحساب الذي نفّذها، ثم شغّل last لمعرفة عمليات تسجيل الدخول القريبة من ذلك التوقيت. إذا لم تتطابق الحسابات مع أي شخص تعرفه، فتوقّف عن تصحيح إعدادات الجدار الناري، واتبع قائمة التحقق الخاصة بخادم VPS مخترق بدلاً من ذلك. إعادة تفعيل الجدار الناري على خادم يتحكم فيه شخص آخر لا تؤدي إلا إلى إخفاء المشكلة.

أعد تفعيله بأمان

بعد معرفة السبب، فعّل ufw مجدداً بطريقة تمنع تكرار فقدان الوصول. اسمح بمنفذ SSH الفعلي، وجدول التراجع، ثم فعّل الجدار الناري. بعد ذلك افتح جلسة SSH جديدة تماماً من طرفية أخرى وتحقق من نجاح الاتصال. لا تغلق الجلسة التي تعمل فيها إلا بعد أن تصبح الجلسة الجديدة متاحة. اترك التسجيل مفعّلاً لمدة يوم، لأن السجل يوضح ما نسيت السماح به بسرعة أكبر بكثير من قراءة user.rules.

FAQ

هل يحذف ufw disable قواعدي؟

لا. يفرغ disable مجموعة القواعد من النواة، ويكتب ENABLED=no في /etc/ufw/ufw.conf. تبقى قواعدك في /etc/ufw/user.rules و/etc/ufw/user6.rules، ويعرض sudo ufw show added هذه القواعد عندما يكون جدار الحماية غير مفعّل. الأمر ufw reset هو الذي يمسحها، وينشئ نسخة احتياطية من كل ملف أولاً، ويطبع سطراً مثل Backing up 'user.rules' to '/etc/ufw/user.rules.20260813_101500'.

هل يؤدي إعادة تشغيل VPS إلى إلغاء حظري بسبب ufw؟

لا. يبدأ ufw عند الإقلاع من ENABLED=yes في /etc/ufw/ufw.conf، لذلك تُحمَّل القواعد نفسها قبل تشغيل الشبكة، ويتكرر حظرك. تفيد إعادة التشغيل فقط بعد إيقاف ufw، أو بعد تعديل ذلك الملف من وضع الإنقاذ مع تثبيت القرص. استخدم وحدة تحكم المزوّد وشغّل sudo ufw disable منها.

لماذا يمكن الوصول إلى حاوية Docker رغم أن ufw يمنع المنفذ؟

يكتب Docker قواعد DNAT وFORWARD خاصة به لكل منفذ منشور. تُوجَّه حركة الشبكة هذه إلى الحاوية بدلاً من تسليمها إلى الخادم المضيف، لذلك لا تمر عبر سلسلة INPUT التي توجد فيها قاعدة المنع في ufw. انشر المنفذ على loopback باستخدام -p 127.0.0.1:5432:5432 عندما يكون مخصصاً للخادم المضيف فقط، وافحص القواعد التي ثبّتها Docker باستخدام sudo iptables -t nat -S DOCKER.

لا أملك كلمة مرور لوحدة التحكم ولا يتوفر وضع إنقاذ. ما الخيارات المتاحة؟

تتعلق الخيارات المتبقية بالمزوّد: إعادة تعيين كلمة المرور من لوحة التحكم، وهو ما يعيد تشغيل الخادم عادةً، أو إرفاق القرص بمثيل آخر لتتمكن من تعديل /etc/ufw/ufw.conf منه. تواصل مع الدعم قبل إعادة إنشاء الخادم، لأن إعادة إنشائه تتلف البيانات الموجودة عليه. بعد استعادة الوصول، شغّل sudo passwd yourname واختبر تسجيل الدخول إلى وحدة التحكم مرة واحدة، حتى لا يستغرق حظرك التالي أكثر من دقيقتين.