قواعد دخول SSH وVPN: ما الذي تتحكم فيه قائمة السماح فعليًا

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

تتبَّع محاولة SSH واحدة حتى خطاف الإدخال

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

تحقّق من المستمع بعد ذلك، فلا قاعدة تستطيع إنقاذ خدمة غير موجودة. شغّل ss -ltnp وتأكّد من أن شيئًا مربوط بالمنفذ وعائلة العناوين التي تتوقعها، ثم اقرأ ssh -v على العميل لتعرف أين يتوقف.

إعادة التوجيه قرار منفصل

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

اكتب السياسة الداخلية كسؤال مستقل: أي عناوين عملاء يجوز لها الوصول إلى أي وجهات عبر النفق. أبقِ المسار الإداري، مثل SSH، على مسار الإدخال مع قيد مصدر خاص به. القاعدة المتساهلة في forward التي تُضاف أثناء الاختبار هي العيب الكلاسيكي الذي يعيش أطول من الاختبار، فراجع المجموعة كاملة بعد التغيير بدلًا من السطر الذي عدّلته. فتح مستمع النفق ليس إذنًا لكل عميل متصل بإدارة المضيف.

الإسقاط والرفض إجراءان، لا سياستان

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

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

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

أبقِ حركة التحكم التي تحتاجها فعلًا

حجب كل ICMP إعداد افتراضي شائع يكسر اكتشاف MTU للمسار، والعَرَض اتصال يُنشأ ثم يتوقف عند الحزم الأكبر. يعتمد اكتشاف الجيران على IPv6 على أنواع ICMPv6 الخاصة به، وإسقاطها يكسر الوصلة قبل أن تُستشار أي قاعدة TCP. كلاهما ينتمي إلى قائمة السماح كاعتماد مسمّى لا كإذن شامل. سياسة تكسر الاكتشاف بصمت أسوأ من سياسة تسمح بقليل من حركة التشخيص.

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

أثبت الاستعادة قبل أن تتخلى عن المسار القديم

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

بالنسبة لخدمة VPN، أعد التجربة من عميل لم يتصل قط، لأن الجلسة المستأنفة قد تعيد استخدام حالة يجب على جلسة جديدة التفاوض عليها. سجّل مجموعة القواعد الدقيقة التي نجحت، مع بصمة أو نسخة، كي تتم مقارنة تعديل لاحق بدلًا من تخمينه. نسّق مع من يملك ترتيب القواعد، لأن قاعدة أسبق تفوز بصمت على التي أضفتها.