قاعدة UFW جديدة واتصال قديم: الحالة المؤسَّسة تفوز

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

الترتيب يحسم، لا وجود القاعدة

‏UFW واجهة أمامية تكتب قواعد netfilter على مراحل: قسم إطاري يعمل قبل قواعد المستخدم، ثم قواعد المستخدم نفسها، ثم قسم يعمل بعدها. وقواعد «ما قبل» الافتراضية تقبل المرور العائد لاتصالات مؤسَّسة ومرتبطة، وتُقيَّم تلك القواعد قبل أي شيء تضيفه بأمر allow أو deny عادي. ويوثّق مرجع أوامر UFW صيغة الإدراج وعرض الحالة المرقَّم الذي يعتمد عليه هذا التغيير.

هذا الترتيب يفسّر المفاجأة. قاعدتك الجديدة حقيقية وهي في الجدول الصحيح، لكنها ليست أول قرار تصادفه الحزمة. فالاتصال الذي جرى تتبعه بوصفه مؤسَّسًا لا يصل إليها أبدًا.

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

أدرِجها فوق الإذن الواسع

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

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

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

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

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

التدفقات المؤسَّسة تنجو من القاعدة الجديدة

تتبّع الاتصالات هو سبب استمرار الجلسة القائمة. فبمجرد تسجيل تدفق بوصفه مؤسَّسًا، تقبل قواعد «ما قبل» حزمه قبل الرجوع إلى قاعدة الرفض، وينتهي النقل كأن شيئًا لم يتغير. لذا فإن الاختبار بمتصفح يعيد استخدام اتصال مفتوح لا يخبرك بشيء عن السياسة الجديدة. قد يبدو الرفض عديم الجدوى بعد دقائق من النشر وفعّالًا تمامًا للمستخدم التالي الذي يتصل.

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

تذكّر الحدود أيضًا. هذه القاعدة لا تقول شيئًا عن ICMP أو UDP أو IPv6، لذا فنجاح ping ليس دليلًا على فشل الرفض. كما أن عنوان IPv4 واحد ليس موقعًا إلكترونيًا: فالاسم قد يُحلّ إلى عدة عناوين، ولا يُغطى إلا العنوان الذي سمّيته.

اختبر بتدفق جديد

اقرأ قواعد المستخدم المرقَّمة والعرض الخام الفعّال، ثم افتح اتصالًا جديدًا من العميل المختار:

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

العرض الخام مهم لأن status يحذف القواعد الإطارية المكتوبة يدويًا، فيمكنه أن يجعل الترتيب يبدو مختلفًا عما تفرضه النواة. قارن الاثنين قبل أن تستنتج أن قاعدة في الموضع الخطأ.

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

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