لا يوجد مفتاح HTTPS عالمي مؤكد لكل تطبيق
لم يحدّد موضوع المجتمع زرًا في ZimaOS يمنح كل تطبيق مُثبّت تلقائيًا نقطة نهاية HTTPS صالحة. يمكن لكل تطبيق الاستماع على منفذ مختلف، واستخدام ميزات ويب مختلفة، وطلب سلوك توجيه منفصل.
كان المستخدم يصل إلى وحدة التخزين عبر نطاق وعنوان IP عام ثابت، لكنه ظل يتلقى تحذيرًا بشأن اتصال غير آمن. اسم النطاق وحده لا ينشئ TLS. يجب أن يصل المتصفح إلى نقطة نهاية تقدّم شهادة صالحة لاسم المضيف.
ابدأ بإدراج كل تطبيق، ومنفذه الداخلي، واسم المضيف الذي تريد استخدامه، وما إذا كان الوصول محليًا فقط، أو وصولًا خاصًا عن بُعد، أو وصولًا عبر الإنترنت العام. يحدّد هذا النطاق تصميم بوابة الدخول المناسب.
اختر نموذج دخول واحدًا لهدف الوصول الفعلي
يمكن للوكيل العكسي إنهاء TLS على المنفذ 443 وتوجيه أسماء مضيفين مختلفة إلى منافذ تطبيقات داخلية منفصلة. يناسب ذلك تصميمًا قائمًا على النطاقات، حيث تخدم واجهة أمامية واحدة مُتحكَّم بها عدة تطبيقات.
يمكن لنفق مُدار توفير نقطة دخول HTTPS من دون إعادة توجيه كل منفذ تطبيق مباشرةً من الموجّه. أما شبكة خاصة متراكبة مثل Tailscale فتحل مشكلة مختلفة: تنضم الأجهزة الموثّقة إلى شبكة خاصة ويمكنها الوصول إلى الخدمات من دون جعلها متاحة للعامة عمومًا.
اختر نموذجًا واحدًا قبل إعداد الشهادات. إن تكديس إعادة توجيه المنافذ المباشرة ونفق وشبكة متراكبة من دون سبب محدد يزيد عدد المسارات التي يجب تأمينها وتصحيحها.
مكان الشهادات هو نقطة إنهاء TLS
يمكن استخدام شهادة Let's Encrypt بواسطة وكيل عكسي أو خدمة أخرى تتحكم في اتصال HTTPS. لا تُثبّت الشهادة «على النطاق»، كما أن الحصول عليها لا يعلّم تلقائيًا كل تطبيق خلفي كيفية استخدامها.
وجّه اسم مضيف واحد إلى الوكيل أو النفق المختار، وأصدر الشهادة أو اربطها هناك، ثم وجّه اسم المضيف إلى تطبيق داخلي واحد. أبقِ منفذ الواجهة الخلفية خاصًا ما لم تتطلب البنية وصولًا مباشرًا تحديدًا.
إذا عرض المتصفح تحذيرًا، فتحقق من اسم المضيف الموجود في الشهادة، ووجهة DNS، وسلسلة الشهادة، والمكوّن الذي يجيب فعليًا على المنفذ 443. لا تتجاوز التحذير كحل دائم.
تحقق من تطبيق واحد قبل تكرار النمط
اختبر تسجيل الدخول، والتحميلات، والتنزيلات، والتحديثات المباشرة، وأي ميزات تعتمد على WebSocket عبر اسم مضيف HTTPS. فالصفحة التي تُحمّل لكنها لا تستطيع التحميل أو الحفاظ على الجلسة ليست مُعدّة بالكامل.
أعد تشغيل الوكيل أو النفق والتطبيق المستهدف، ثم كرر سير العمل نفسه. تأكد من إعادة توجيه HTTP فقط حيثما كان ذلك مقصودًا، ومن عدم كشف منافذ الواجهة الخلفية الخام للإنترنت عن غير قصد.
بعد نجاح تطبيق واحد، كرر ربط اسم المضيف بالواجهة الخلفية للتطبيق التالي. إذا كانت إحدى الخدمات تتطلب إعدادات وكيل خاصة، فتراجع عن المسار المتعطل فقط بدلًا من إزالة نقاط نهاية HTTPS العاملة.
لا يحل HTTPS عن بُعد محل التحكم في الوصول
يشفّر TLS حركة المرور ويتحقق من اسم المضيف، لكنه لا يحدد من ينبغي له استخدام التطبيق. حافظ على مصادقة قوية للتطبيق، وتعرّض محدود، وتحديثات، وسجلات تدقيق.
يوصي الموضوع بالبحث في Cloudflare Tunnels أو Tailscale أو وكيل عكسي مثل Caddy، لكنه لا يوثّق عملية نشر مكتملة. هذه توجهات معمارية وليست وصفة تنفيذية خطوة بخطوة لـ ZimaOS مؤكدة المصدر.
توقف قبل الإتاحة العامة إذا كانت الطريقة المختارة أو ملكية الشهادة أو حدود المصادقة غير واضحة. تحقّق أولًا على خدمة غير حرجة، أو استخدم وصولًا خاصًا عن بُعد أثناء تصميم المسار العام.
الأسئلة الشائعة
هل يمكن لشهادة واحدة تأمين كل تطبيقات ZimaOS تلقائيًا؟
ليس بمفردها. فما زال الوكيل أو نقطة نهاية TLS الأخرى بحاجة إلى اسم مضيف وقاعدة توجيه لكل خدمة خلفية.
هل أحتاج إلى كشف منفذ كل تطبيق لاستخدام HTTPS عن بُعد؟
ليس بالضرورة. صُمّمت الوكلاء العكسية والأنفاق المُدارة لتوحيد بوابة الدخول، بينما تتجنب الشبكات المتراكبة الخاصة الإتاحة العامة الشاملة.
هل Tailscale هو نفسه الوكيل العكسي؟
لا. ينشئ Tailscale إمكانية وصول شبكية خاصة بين الأجهزة المصرّح لها؛ أما الوكيل العكسي فيقبل طلبات الويب ويوجّه أسماء المضيفين إلى الخدمات الخلفية.
