What is a Cloudflare Tunnel and why would I use it on my ZimaCube 2?

A Cloudflare Tunnel creates an outbound-only encrypted connection from your ZimaCube 2 to Cloudflare edge network. Instead of opening ports on your router (which exposes your infrastructure to the internet), all traffic flows through this encrypted tunnel. Your origin server — the ZimaCube 2 — remains completely hidden from public view.

Do I need to open any ports on my router for this setup?

No. That is the point. Cloudflare Tunnel only makes outbound connections. Your router does not need a single port forward rule. This eliminates the most common attack vector in [homelab networking](https://shop.zimaspace.com/blogs/zima-campaign-hub/ultimate-homelab-hardware-guide-self-hosting "Building a Homelab: Top Hardware Picks for Beginners to Pros").

Can the ZimaCube 2 handle running a reverse proxy and all my services at the same time?

Yes. Michael ZC2 runs Cloudflare Tunnel, Nginx Proxy Manager, and 10+ Docker containers simultaneously — all while maintaining quiet, cool operation. The dual 2.5GbE ports and NVMe storage ensure networking and container I/O do not become bottlenecks.

Why does Docker network segmentation matter?

If every container shares the same network, one compromised service gives an attacker a path to everything else. By placing only Cloudflare Tunnel and Nginx Proxy Manager on an "edge" network (and keeping applications on separate internal networks), you create a controlled boundary between public-facing traffic and your private services.

What was the TLS hostname mismatch issue?

When Cloudflare Tunnel connected to Nginx Proxy Manager internally using a Docker hostname like reverse-proxy, the TLS certificate — which was issued for a public domain like example.com — did not match. The fix was configuring Cloudflare Tunnel to use the correct Origin Server Name while still routing to the internal Docker hostname. This preserved full encryption without disabling validation.

How does the ZimaCube 2 networking hardware compare to a standard NAS for this use case?

Most consumer NAS devices ship with a single gigabit Ethernet port. The ZimaCube 2 has dual 2.5GbE — which means you can dedicate one interface to edge traffic (Cloudflare + reverse proxy) and the other to internal services. This physical-layer separation is something you cannot achieve on single-NIC hardware.

كيف حولت ZimaCube 2 إلى وحدة تحكم دخول بدون ثقة لكامل مختبر المنزل الخاص بي

إيفا وونغ

IceWhale author

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

"Dual monitor home lab workstation showing Lucky in Prod blog page, mini server tower, keyboard and coding setup on office desk

💡

تسليط الضوء على المجتمع: مايكل لوكنبيل، برنامج رواد ZimaCube 2

لمختبر منزلك باب أمامي. إذا كنت مثل معظم المستضيفين الذاتيين، فإن هذا الباب الأمامي هو إعادة توجيه منفذ على جهاز التوجيه الخاص بك — وهو مفتوح على مصراعيه.

قضيت أسابيع في إعادة بناء مختبري. النتيجة: طبقة دخول بمستوى إنتاجي تعمل بالكامل على ZimaCube 2. لا منافذ مفتوحة على جهاز التوجيه الخاص بي. لا خوادم مصدر قابلة للوصول علنًا. تشفير TLS شامل على كل اتصال. كل ذلك يجلس بهدوء بجانب تلفازي.

إليك بالضبط كيف بنيته، وما تعطل على طول الطريق، ولماذا تبين أن ZimaCube 2 هو المنصة المثالية لهذه المهمة.

المشكلة مع دخول مختبرات المنازل التقليدية

لا تزال العديد من مختبرات المنازل تبدو هكذا :

المنفذ 443 معاد توجيهه على جهاز التوجيه → يشير إلى وكيل عكسي
المنفذ 80 معاد توجيهه → يعيد التوجيه إلى 443
الخدمات قابلة للوصول مباشرة إذا كنت تعرف عنوان IP
بنية المصدر على بعد فحص منفذ واحد من الاكتشاف

هذا يخلق مشاكل حقيقية. منافذ دخول مكشوفة علنًا. خوادم المصدر قابلة للوصول مباشرة. واجهات الإدارة تستجيب قبل المصادقة. حتى مع HTTPS، تظل البنية التحتية نفسها مرئية — والرؤية تجذب الاستطلاع.

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

لماذا ZimaCube 2

هذا النوع من الهيكلية يتطلب مجموعة محددة من خصائص الأجهزة. ليس القوة الخام — بل الاعتمادية، والمرونة، والهدوء.

حقق ZimaCube 2 كل المتطلبات:

تشغيل دائم: هادئ على مدار الساعة طوال أيام الأسبوع.
يجب أن تعمل طبقة الدخول باستمرار — تصميم ZC2 الحراري يعني أنها تفعل ذلك دون أن تهيمن على الغرفة.

شبكتا 2.5GbE مزدوجتان: واجهة واحدة لشبكة الحافة، وواحدة للشبكة الداخلية. يبدأ تقسيم حركة المرور من الطبقة الفيزيائية، وليس فقط في Docker.

Docker أصلي: تخزين NVMe لأداء سريع لحاويات الإدخال/الإخراج. شبكات جسر متعددة لا تعيق النظام. تم بناء المنصة لهذا الغرض.

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

Featured

ZimaCube 2 سحابة شخصية منزلية لتخزين الشبكة (NAS)

ZimaCube2

الهيكلية الجديدة

بدلاً من فتح المنافذ على جهاز التوجيه الخاص بي، يعمل التصميم الجديد على النحو التالي:

نفق Cloudflare ينشئ اتصالات مشفرة صادرة فقط إلى حافة Cloudflare
مدير وكيل Nginx يتولى التوجيه، وإنهاء SSL، وقوائم التحكم في الوصول
شبكات جسر Docker تفصل حركة المرور على الحافة عن الأحمال الداخلية
صفر قواعد NAT واردة — الموجه لا يعلم أن هناك أي شيء يتم تقديمه

🔒 البنية التحتية الأصلية مخفية تمامًا. كلاودفلير تقع أمام كل حركة المرور العامة. يقوم ZimaCube 2 فقط بإنشاء اتصالات صادرة. لا شيء يستمع على منفذ عام.

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

تقسيم شبكة دوكر: الحافة ≠ الداخلية

كان أحد أهم التغييرات هو فصل حركة المرور باستخدام شبكات جسر دوكر.

docker network create \

--subnet 172.x.x.x/24 \

الحافة

تحمل شبكة الحافة حاويتين فقط: نفق كلاودفلير ومدير بروكسي Nginx. هذا كل شيء. تعيش التطبيقات على شبكات دوكر داخلية منفصلة — معزولة تمامًا عن طبقة الدخول.

🎁 ليس كل حاوية يجب أن تكون متصلة بالإنترنت. إذا كان خادم Plex الخاص بك، أو مثيل Vaultwarden، أو مشغل CI/CD يشارك شبكة مع البروكسي العكسي، فإن خدمة مخترقة واحدة تعطي المهاجم طريقًا إلى كل شيء آخر.

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

مشكلة TLS التي كادت تكسرني

انتهى الأمر ليكون الدرس الهندسي الأكثر إثارة للاهتمام في المشروع بأكمله.

بدا الإعداد بسيطًا في البداية. عمل HTTP بين نفق كلاودفلير ومدير بروكسي Nginx على الفور:

http://reverse-proxy → ✅ يعمل

لذا قمت بتمكين HTTPS.

https://reverse-proxy → ❌ فشل

كانت الشهادة صالحة. وتاريخ الانتهاء كان جيدًا. وتم التحقق من سلسلة الثقة. بدا كل شيء صحيحًا — ومع ذلك رفض HTTPS الاتصال.

المشكلة الحقيقية كانت في التحقق من اسم المضيف في TLS.

تم إصدار الشهادة لنطاقاتي العامة (example.com، app.example.com). لكن نفق كلاودفلير كان يتصل داخليًا بـ reverse-proxy — وهو اسم مضيف في دوكر لم يتطابق مع أي شيء على الشهادة. تسبب عدم تطابق اسم المضيف في فشل التحقق من TLS بصمت.

💡 التحقق من TLS ليس فقط حول ثقة الشهادة وانتهائها. بل يتحقق أيضًا من هوية اسم المضيف وتوقعات SNI. إذا لم يتطابق الاسم في عنوان URL مع الاسم على الشهادة، تفشل الاتصال — حتى لو كان كل شيء آخر مثاليًا.

الحل: تكوين نفق كلاودفلير مع اسم خادم الأصل: example.com مع الاستمرار في التوجيه داخليًا إلى https://reverse-proxy:443. حافظ ذلك على النقل المشفر، والتحقق الصحيح من اسم المضيف، والتحقق الكامل من TLS — دون تعطيل أي فحوصات أمان.

هذا هو النوع من الدروس التي لا تتعلمها إلا من خلال البناء.

قوائم التحكم في الوصول والدرس حول مسارات حركة البنية التحتية

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

تعلمت هذا بالطريقة الصعبة عندما قفلت نفسي عن طريق الخطأ من مدير وكيل Nginx.

قمت بتكوين ACL للسماح فقط لشبكة LAN الفرعية الخاصة بي (192.168.x.x/24). بدا المنطق سليمًا — فقط الأجهزة على شبكتي المنزلية يجب أن تصل إلى لوحة الإدارة.

كان NPM يرى فعليًا حركة من شبكة جسر Docker. وليس من شبكة LAN الخاصة بي. قوائم التحكم في الوصول منعت كل شيء، بما في ذلك أنا.

إضافة شبكة فرعية لـ Docker إلى قائمة السماح حلت المشكلة فورًا. لكنها كانت تذكيرًا حقيقيًا بأن مسارات حركة البنية التحتية غالبًا ما تختلف عما نفترضه على الورق.

🔄 في بيئة الحاويات، يتم إعادة كتابة عنوان IP الأصلي للعميل عند عدة نقاط: حافة Cloudflare → النفق → جسر Docker → الوكيل العكسي. كل نقطة تغير عنوان المصدر. يجب أن تأخذ قواعد جدار الحماية في الاعتبار مسار الحركة الفعلي، وليس ما تتخيله.

لماذا هذه البنية مهمة على ZimaCube 2

هناك سبب يجعل هذه الحزمة تعمل بشكل جيد جدًا على ZC2 تحديدًا:

ثنائي 2.5GbE يعني أن طبقة الدخول لديها عرض نطاق مخصص — حركة الشبكة الداخلية لا تتنافس مع الخدمات المواجهة للإنترنت
تخزين NVMe يضمن شبكة حاويات سريعة — عرض نطاق شبكة الجسر لا يعيق بسبب بطء إدخال/إخراج القرص
تشغيل هادئ دائمًا يعني أن طبقة الدخول تعمل على مدار الساعة في مساحة معيشة — وليس في رف قبو
منصة أصلية لـ Docker مع مساحة كافية لتشغيل النفق، الوكيل العكسي، محرك قوائم التحكم في الوصول، وجميع خدماتك في نفس الوقت
قابلية التوسع تعني أنه يمكنك إضافة بطاقة شبكة مخصصة أو بطاقة تسريع لاحقًا إذا نمت احتياجات الشبكة لديك

ZimaCube 2 لا يستضيف هذه الخدمات فقط. إنه المنصة المناسبة لها.

الحزمة النهائية

ما يعمل على ZimaCube 2 الآن:

نفق Cloudflare — اتصالات مشفرة صادرة فقط، بدون منافذ مفتوحة
مدير وكيل Nginx — وكيل عكسي، SSL، قوائم التحكم في الوصول
شبكات جسر Docker — فصل حركة الحافة عن الحركة الداخلية
TLS من النهاية إلى النهاية — مشفر من العميل إلى الأصل، لا نص عادي في أي مكان
الأصل المخفي — لا شيء يرد على عنوان IP عام

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

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

يقدم ZimaCube 2 ذلك بالضبط.

ابنِ مختبر منزلي بدون ثقة مع ZimaCube 2 →

الأسئلة المتكررة

ما هو Cloudflare Tunnel ولماذا أستخدمه على ZimaCube 2 الخاص بي؟

ينشئ Cloudflare Tunnel اتصالًا مشفرًا صادرًا فقط من ZimaCube 2 إلى شبكة Cloudflare الحدية. بدلاً من فتح منافذ على جهاز التوجيه الخاص بك (مما يعرض بنيتك التحتية للإنترنت)، يتدفق كل المرور عبر هذا النفق المشفر. يظل خادم الأصل — ZimaCube 2 — مخفيًا تمامًا عن العرض العام.

هل أحتاج إلى فتح أي منافذ على جهاز التوجيه الخاص بي لهذا الإعداد؟

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

هل يمكن لـ ZimaCube 2 تشغيل عكس البروكسي وجميع خدماتي في نفس الوقت؟

نعم. يعمل Michael ZC2 على تشغيل Cloudflare Tunnel وNginx Proxy Manager وأكثر من 10 حاويات Docker في نفس الوقت — كل ذلك مع الحفاظ على تشغيل هادئ وبارد. تضمن منافذ 2.5GbE المزدوجة وتخزين NVMe ألا تصبح الشبكة وعمليات الإدخال/الإخراج للحاويات عنق زجاجة.

لماذا يهم تقسيم شبكة Docker؟

إذا شارك كل حاوية نفس الشبكة، فإن خدمة مخترقة واحدة تمنح المهاجم طريقًا إلى كل شيء آخر. بوضع Cloudflare Tunnel وNginx Proxy Manager فقط على شبكة "الحدود" (والاحتفاظ بالتطبيقات على شبكات داخلية منفصلة)، تخلق حدًا محكمًا بين حركة المرور العامة وخدماتك الخاصة.

ما هي مشكلة عدم تطابق اسم مضيف TLS؟

عندما اتصل Cloudflare Tunnel بـ Nginx Proxy Manager داخليًا باستخدام اسم مضيف Docker مثل reverse-proxy، لم تتطابق شهادة TLS — التي صدرت لنطاق عام مثل example.com — مع الاسم. كان الحل هو تكوين Cloudflare Tunnel لاستخدام اسم خادم الأصل الصحيح مع الاستمرار في التوجيه إلى اسم مضيف Docker الداخلي. هذا حافظ على التشفير الكامل دون تعطيل التحقق.

كيف تقارن أجهزة الشبكات في ZimaCube 2 بجهاز NAS عادي لهذا الاستخدام؟

تأتي معظم أجهزة NAS الاستهلاكية مزودة بمنفذ إيثرنت جيجابت واحد فقط. يحتوي ZimaCube 2 على منفذي 2.5GbE — مما يعني أنه يمكنك تخصيص واجهة واحدة لحركة المرور الخارجية (Cloudflare + العكس البروكسي) والأخرى للخدمات الداخلية. هذا الفصل على مستوى الطبقة الفيزيائية هو شيء لا يمكنك تحقيقه على أجهزة ذات بطاقة شبكة واحدة.