تغيير قاعدة الجدار الناري لا يعمل: ترتيب القواعد وحالة الاتصال

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

ترتيب القواعد وحالة الاتصال عطلان مختلفان

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

ينتج تتبُّع الاتصالات العرَض الثاني، وهو يبدو من الخارج مطابقًا. فبمجرد أن يصبح التدفق في جدول الحالات، يعود سماح «منشأ أو مرتبط» قرب أعلى السلسلة قبل أن تُستشار قاعدتك الجديدة. ولترجمات NAT الخاصية نفسها: فقد ثُبِّت التحويل عند بدء التدفق، لذا لا تعيد قاعدة postrouting المعدلة كتابة جلسة تعمل بالفعل. ولهذا يبدو التغيير ناجحًا عند 09:00 بالنسبة لاتصال جديد، ويبدو بلا أثر بالنسبة للجلسة التي فتحها أحدهم عند 08:55.

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

اقرأ مجموعة القواعد النشطة، لا الملف الذي عدّلته

ابدأ بما تفرضه النواة الآن. فالتهيئة المحفوظة التي لم تُطبَّق قط تفسّر عددًا مفاجئًا من السلوكيات التي لم تتغير، واستبعادها لا يكلّف سوى أمر واحد:

nft list ruleset
iptables-save

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

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

قاعدة حظر بعدّاد صفري بعد محاولة اختبار حقيقية ليست مشكلة سياسة، بل مشكلة موقع. ونقلها تغيير من سطر واحد، والصياغة هي بالضبط ما سبّب الخطأ الأصلي. مع iptables، -I تُدرج، بينما -A تضيف في النهاية؛ ومع nftables، insert تضع القاعدة في بداية السلسلة، بينما add تضيف في النهاية. وعندما يجب أن تنتصر قاعدة، فصرّح بذلك بدلًا من الوثوق بالترتيب الذي حُمّل مصادفة.

أثبت ما إذا كان التدفق متتبَّعًا

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

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

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

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

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

اختبر من تدفق جديد مع طريق للعودة

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

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

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

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

سجّل الغرض والموقع مع القاعدة

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

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