ZFW هو جدار حماية للمضيف طوره المجتمع من أجل ZimaOS، وليس ميزة مدمجة من IceWhale. ويُثبت كامتداد للنظام على مستوى المضيف، ويظهر كبلاطة في لوحة المعلومات، ويحاول معالجة فجوة حقيقية في ZimaOS: فقد تكون الخدمات الأصلية والمنافذ التي ينشرها Docker قابلة للوصول عبر الشبكة المحلية ما لم يقيّدها جدار حماية آخر أو جهاز شبكة upstream.
بدأ المنشور الأصلي عند الإصدار ZFW v1.0.10، لكن هذا الإصدار لم يعد المرجع المناسب للتثبيت الحالي. واصل ZFW التغير بسرعة مع تطور ZimaOS نفسه. الإصدار الحالي في المستودع الأساسي هو v1.0.25، وقد أصلح المشروع بالفعل مشكلات توافق تتعلق بـ nf_tables الواجهة الخلفية، وتغييرات رموز الجلسات في ZimaOS 1.7.x، وتعريض Docker عبر IPv6، وحركة مرور Zima Net على tun0.
ZFW برنامج مجتمعي، وليس جدار حماية من IceWhale
طوّر Lintux نظام ZFW ويصونه بشكل مستقل. ويتضمن النقاش الأصلي اختبارات مجتمعية قوية، بما في ذلك مستخدمين أكدوا استمرار القواعد والمنافذ المحظورة وسلوك التراجع وإصلاحات التوافق اللاحقة، لكن لا يوجد إعلان من IceWhale يجعل ZFW جدار حماية رسميًا لـ ZimaOS.
ويهم هذا التمييز لأن ZFW يتعامل مباشرةً مع مكدس شبكة المضيف. فقد تحظر قاعدة سيئة أو غير متوافقة SSH أو واجهة الويب أو تطبيقات Docker أو الوصول عن بُعد.
يفصل ZFW بين خدمات المضيف والمنافذ التي ينشرها Docker
تدرك بنية ZFW أن حركة مرور Docker تختلف عن حركة مرور INPUT العادية للمضيف:
- تُدار خدمات ZimaOS الأصلية وخدمات المضيف عبر قواعد على نمط INPUT؛
- تُرشَّح المنافذ التي ينشرها Docker عبر
DOCKER-USER; - لدى IPv6 سلاسل وسلوكيات مقابلة خاصة به.
وهذا أدق من برنامج تعليمي لجدار الحماية يفحص INPUT فقط ويفترض أن Docker يتبع المسار نفسه.
التطبيق الآمن هو أهم ميزة للسلامة
قدّم المصدر آلية تراجع تلقائي بعد 120 ثانية. عند تطبيق مجموعة من القواعد، يجب على المستخدم تأكيدها قبل انتهاء المؤقت. وإذا تسببت القاعدة عن طريق الخطأ في منعه من الوصول، يتراجع جدار الحماية تلقائيًا.
وهذا مهم بشكل خاص في جهاز NAS بلا شاشة، لأن خطأً في جدار الحماية قد يتحول بخلاف ذلك إلى مهمة استرداد محلية باستخدام شاشة ولوحة مفاتيح.
كشفت المناقشة عن ثغرة حقيقية في السماح الافتراضي لمحطة ZimaOS الطرفية
أبلغ أحد المستخدمين بأن ZFW حظر المنفذ TCP 7681، وهو المنفذ الافتراضي لمحطة ttyd الطرفية. وأوضح Lintux أن قائمة السماح الأولية الأصلية تضمنت منافذ مثل SSH وHTTP/HTTPS وSMB وعدة خدمات من ZimaOS، لكنها لم تتضمن 7681.
هذا تذكير مفيد: قبل تفعيل سياسة المنع الافتراضي، أحصِ الخدمات التي تعتمد عليها فعليًا. قد يعمل جدار الحماية بشكل صحيح، لكنه يظل يحظر خدمة نسيها الملف التعريفي الافتراضي.
غيّر ZimaOS 1.6.2 الواجهة الخلفية لـ iptables
جاء أحد أهم التحديثات في موضوع المصدر بعد أن بدّل ZimaOS 1.6.2 مسار iptables الفعّال في Docker إلى سلسلة DOCKER-USER. nf_tables الواجهة الخلفية. كان بإمكان إصدارات ZFW الأقدم كتابة القواعد في الجدول القديم غير المستخدم، بينما كانت المربعة لا تزال تبدو سليمة.
أضافت الإصدارات اللاحقة اكتشاف الواجهة الخلفية وعمليات تحقق إضافية من قواعد Docker. ولهذا يجب ألا تُجمّد تعليمات تثبيت ZFW القديمة كطريقة دائمة.
كشف الموضوع عن حالة حقيقية لفشل Docker في وضع السماح وأصلحها
أثناء اختبار الإصدار v1.0.16، اكتشف أحد المستخدمين أن DOCKER-USER قد تنتهي بعبارة RETURN بسيطة من دون قواعد المنع الافتراضية المتوقعة. أكد Lintux أن هذا كان مسارًا حقيقيًا وغير متوقع للفشل في وضع السماح، وغيّر منطق جرد المنافذ.
لاحقًا، أعاد المستخدم نفسه تثبيت الإصدار v1.0.19، وأعاد تطبيق جدار الحماية، وتحقق من وجود القواعد المتوقعة لكل منفذ ومن معالجة UDP.
تطلب IPv6 عدة جولات من الإصلاحات الواقعية
يوثّق موضوع المصدر حالات كانت فيها حماية IPv6 نشطة، لكنها أُبلغ عنها بشكل غير صحيح، وحالات أخرى حُظرت فيها منافذ IPv6 التي ينشرها Docker على نحو غير متوقع. لم تكن هذه مخاوف نظرية؛ فقد نشر المستخدمون مخرجات السلاسل الفعلية، وأعاد المشرف إنتاج مسارات محددة وأصلحها.
بالنسبة إلى اتصال منزلي يدعم IPv6، اختبر الوصول من شبكة IPv6 خارجية فعلية بدلًا من افتراض أن اختبارًا من شبكة IPv4 المحلية يثبت السياسة نفسها.
كان على ZFW الحالي أيضًا التكيف مع الوصول عن بُعد إلى Zima Net
اكتشف إصدار لاحق من المصدر أن حركة الوصول عن بُعد إلى Zima Net المدمجة في ZimaOS عبر tun0 قد تُسقطه إصدارات ZFW الأقدم. أضاف الإصدار v1.0.24 من ZFW معالجة التجاوز اللازمة عبر السلاسل ذات الصلة.
وهذا سبب آخر لتحديث كلٍّ من ZimaOS وZFW معًا والتحقق من الوصول عن بُعد بعد ترقية جدار الحماية.
استخدم إصدار ZFW الحالي، وليس v1.0.10
اعتبارًا من سبتمبر 2026، يعرض المصدر الرئيسي الإصدار v1.0.25 من ZFW باعتباره أحدث إصدار. راجع إصدارات ZFW الحالية وسجل التوافق قبل التثبيت أو التحديث.
تحقق من جدار الحماية الفعلي، وليس من مربع لوحة المعلومات الأخضر فقط
بعد تمكين ZFW، اختبر ما يلي:
- SSH وواجهة الويب من الشبكة المحلية؛
- طرفية ZimaOS؛
- منافذ Docker المنشورة المهمة؛
- Tailscale/ZeroTier/Zima Net إذا كانت مستخدمة؛
- اتصال IPv6 من خارج الشبكة المحلية عند الحاجة؛
- استمرارية القواعد بعد إعادة التشغيل.
يوضح سجل المصدر سبب عدم اعتبار واجهة المستخدم التي تبدو سليمة الدليل الوحيد على وصول القواعد إلى الواجهة الخلفية الفعلية.
الأسئلة الشائعة حول ZFW
هل ZFW جدار حماية رسمي من IceWhale؟
لا. إنها وحدة جدار حماية للمضيف طوّرها المجتمع وتتفاعل بعمق مع ZimaOS.
هل ينبغي للمستخدمين الحاليين تثبيت الإصدار v1.0.10 من المنشور الأصلي؟
لا. تلقّى المشروع العديد من إصلاحات التوافق والأمان منذ ذلك الإصدار.
لماذا يستخدم ZFW سلسلة DOCKER-USER؟
يمكن لحركة المرور التي ينشرها Docker تجاوز تصفية INPUT العادية للمضيف، لذلك يستخدم ZFW مسار التصفية المخصص لـ Docker لمنافذ الحاويات.
