ثمّة طقس عبور لكل من يدير خادمه لأول مرة: تقرّر إعداد جدار ناري، تكتب بضعة أوامر ufw، تضغط enable — فيصمت الطرفية. اختفى SSH. لم تُعطب شيئًا ولم تُخترق. أنت فقط أوصدت الباب وأنت في الخارج.
يحدث هذا حتى للمدراء المهرة. الأسبوع الماضي حدث لأحد عملائنا، ولذلك أكتب هذا. الخبر الطيّب: يمكن استرجاعه بالكامل في أقل من دقيقة، ولست بحاجة إطلاقًا لإعادة التثبيت أو فقد ملف واحد. إليك الطريقة.
ما الذي حدث حقًا
يرفض ufw (Uncomplicated Firewall) افتراضيًا كل الوارد. في اللحظة التي تشغّل فيها ufw enable، يُسقَط كل ما لم تسمح به صراحةً — بما في ذلك جلسة SSH التي تجلس داخلها. إن نسيت ufw allow لمنفذ SSH أولًا، فقد قطعت اتصالك أنت لحظة سريان القاعدة.
هذه هي النسخة الكلاسيكية. واثنتان أخريان توقعان الناس أيضًا:
- سمحت بالمنفذ الخطأ. خطأ طباعي، أو سمحت بمنفذ الخدمة (لنقل 8080) ونسيت 22.
- سمحت بـ 22 لكنك وضعت قاعدة
denyأعلى في القائمة تحجبه. ufw حسّاس للترتيب.
في كل الأحوال الخادم نفسه بخير — يعمل، القرص سليم، وتطبيقك ما زال يهمهم خلف الجدار. إنها مشكلة وصول شبكي بحتة. ولهذا بالذات الإصلاح سهل.
الحركة الخطأ: إعادة التثبيت
الاندفاع الأول غالبًا "إذن أُعيد ضبط الخادم وأبدأ من الصفر". لا تفعل — ليس لهذا. إعادة التثبيت تمحو كل شيء لاسترجاع SSH يعمل، بينما ما يحجب SSH مجرد أمر جدار ناري تتراجع عنه في عشر ثوانٍ. كأنك تحرق البيت لأنك أوصدت باب الدخول.
إعادة التثبيت صحيحة حين تريد صفحة بيضاء. أما لحبس ufw فهي مبالغة كمن يصطاد ذبابة بمدفع.
الحركة الصحيحة: وحدة التحكم عبر الويب
كل خادم VPS محترم يمنحك وحدة تحكم خارج النطاق — طريقًا إلى الجهاز لا يمرّ عبر SSH ولا حتى عبر مكدس الشبكة. في EQVPS هو زر Console في صفحة خادمك. إنها وحدة تحكم تسلسلية: نص فقط، موصولة مباشرة بالجهاز الافتراضي كما لو كانت شاشة ولوحة مفاتيح. لا سلطان لقاعدة جدار ناري عليها، لأنها ليست حركة مرور شبكية.
انقره، وسجّل الدخول ببيانات root (أو اكشف كلمة المرور في اللوحة إن لم تكن بحوزتك) — وها أنت في الجهاز، بجدار ناري أو بدونه.
الآن تراجَع عن الضرر. أسرع طريق:
sudo ufw disable
هذا يطفئ الجدار الناري ويحفظ قواعدك، لتعيد تفعيله لاحقًا بعد تصحيح الخطأ. يعود SSH فورًا.
إن كنت تفضّل عدم إسقاط الجدار الناري كلّه، فافتح فقط المنفذ الذي فاتك:
sudo ufw allow 22
sudo ufw status numbered
يستحق status numbered النظرة: يُظهر ترتيب القواعد — وهنا تختبئ حالات "سمحت بـ 22 ومع ذلك يحجب". إن جلس deny فوق allow لديك، فاحذفه بـ sudo ufw delete <الرقم>.
فخّ NAT الذي لا يذكره تقريبًا أي دليل
إن كنت على خطة NAT، فهنا فخّ. تدخل SSH عبر منفذ مرتفع — شيء مثل 20266 — فالحدس الطبيعي ufw allow 20266. هذا لا يفعل شيئًا.
في NAT، ذلك المنفذ الخارجي مُمرَّر إلى المنفذ 22 داخل الجهاز الافتراضي. يعمل ufw داخل الجهاز الافتراضي ولا يرى أبدًا سوى 22. فالقاعدة التي تحتاجها فعلًا هي:
sudo ufw allow 22
اسمح بـ 20266 وستظل تحدّق في اتصال معطّل متسائلًا لماذا. اسمح بـ 22 وأنت في الداخل. المنطق نفسه لأي خدمة: اسمح بالمنفذ الذي تُنصت عليه العملية داخل الجهاز، لا المنفذ المُمرَّر الذي تتصل عبره من الخارج.
كيف لا تكرّرها أبدًا
الإصلاح يستغرق دقيقة، لكن ألا تحتاجه أفضل. عادتان:
اسمح بمنفذ SSH قبل التفعيل. دائمًا بهذا الترتيب:
sudo ufw allow 22
sudo ufw enable
اعكسه فتعود إلى وحدة التحكم.
أبقِ جلسة SSH ثانية مفتوحة أثناء تغيير قواعد الجدار الناري. سجّل الدخول مرتين. أجرِ التغييرات في نافذة؛ فإن مات SSH، تبقى الأخرى حيّة لتصلحه. حيلة قديمة، تنقذك كل مرة.
وإن كنت تُجهّز جهازًا جديدًا، فإن قائمة أمان خادم VPS الجديد لدينا تغطّي ufw بالترتيب الصحيح، مع مفاتيح SSH وبضعة أشياء أخرى تهمّ حقًا في العشر دقائق الأولى.
الخلاصة
يبدو حبس ufw مرعبًا وهو لا شيء تقريبًا. الخادم لم يغادر قط؛ تحتاج فقط بابًا لا يستطيع أي جدار ناري إيصاده — وحدة التحكم عبر الويب — وأمرًا واحدًا. احتفظ بـ ufw disable ووحدة التحكم في جيبك، واسمح بمنفذك قبل التفعيل المرة القادمة، ولن يُعرّقك هذا الأمر ثانيةً أبدًا.
التعليقات
لا تعليقات بعد. كن الأول.