كيف يتعامل البروكسي العكسي مع TLS لحاويات خادم المنزل؟

يتعامل الوكيل العكسي مع TLS لحاويات خادم المنزل عن طريق قبول اتصال المتصفح المشفر، وعرض الشهادة لاسم المضيف المطلوب، وفك تشفير طلب HTTP، واختيار الحاوية المطابقة، وإنشاء اتصال علوي منفصل مع تلك الخدمة.

لذلك، تعتبر اتصالات المتصفح إلى الوكيل والوكيل إلى الحاوية حدود أمان مختلفة. يستخدم الاتصال الأول عادة شهادة موثوقة عامة أو خاصة؛ أما الثاني فقد يستخدم شبكة HTTP معزولة، أو اتصال HTTPS منفصل، أو تمرير TLS عندما يجب على الخدمة الخلفية الاحتفاظ بالمفتاح الخاص.

أين تنتهي اتصال TLS الخاص بالمتصفح؟

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

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

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

كيف يصل منفذ HTTPS واحد إلى عدة حاويات؟

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

أثناء مصافحة TLS، يزود العميل عادةً اسم الخادم المقصود حتى يتمكن الوكيل من اختيار شهادة مطابقة. بعد فك التشفير، يحدد رأس HTTP Host والمسار المُكوَّن ما إذا كان الطلب يذهب إلى Jellyfin أو Home Assistant أو Vaultwarden أو حاوية أخرى.

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

كيف يتم إصدار وتجديد الشهادات؟

يمكن للوكيلات العكسية أن تعمل كعملاء ACME، وتحديات DNS تؤتمت تجديد الشهادة بإنشاء سجل DNS مؤقت يثبت السيطرة على النطاق المطلوب.

يثبت تحدي HTTP السيطرة عبر نقطة نهاية ويب، بينما يمكن لتحدي DNS إصدار شهادات للخدمات الداخلية أو أسماء البدل دون نشر كل حاوية مباشرة. تغير طريقة التحقق التعرض ومتطلبات الاعتماد.

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

هل يتم تشفير الحركة بين الوكيل والحاوية؟

الصاعد مكون بشكل مستقل، لذا يمكن للروابط الصاعدة استخدام HTTP أو HTTPS. إنهاء TLS العام لا يقرر تلقائيًا ما إذا كان الاتصال الداخلي مشفرًا.

قد يكون HTTP العادي معقولًا على شبكة حاويات خاصة محصورة في مضيف موثوق واحد، لكن الوكيل يمكنه قراءة وتعديل تلك الحركة. إذا عبر الصاعد مضيفين أو شبكات غير موثوقة أو حدود ثقة أقوى، يقلل اتصال HTTPS منفصل وموثوق من التعرض.

إعادة التشفير تخلق جلستي TLS وقرارين للشهادة. يجب على الوكيل التحقق من شهادة الخلفية والاسم المتوقع؛ مجرد تمكين HTTPS مع تخطي التحقق يستبدل التشفير بنفق غير موثوق.

كيف تتعرف الحاوية على سياق العميل الأصلي؟

اتصال TCP الصاعد ينشأ من الوكيل، لذا اتصالات الوكيل تخفي عنوان العميل الأصلي. رؤوس Forwarded تحمل عنوان IP للعميل، المخطط الأصلي، اسم المضيف، والمنفذ الذي يحتاجه التطبيق.

بدون مخطط HTTPS الأصلي، قد ينشئ التطبيق إعادة توجيه HTTP، أو يحدد ملفات تعريف الارتباط الآمنة بشكل غير صحيح، أو يبني عنوان URL للرد الخاطئ. بدون عنوان عميل موثوق، قد تحدد السجلات وحدود المعدل وسياسات الوصول الوكيل فقط.

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

ما هو حد الثقة الجديد الذي ينشئه إنهاء TLS؟

يمكن للعملاء إرسال رؤوس توجيه مزورة بأنفسهم، لذا يجب على البروكسيات الموثوقة تنقية رؤوس التوجيه قبل أن يستخدمها الخادم الخلفي لاتخاذ قرارات أمنية.

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

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

الأسئلة الشائعة

هل تحتاج كل حاوية إلى شهادة TLS عامة خاصة بها؟

ليس عندما ينهي البروكسي العكسي TLS. يمكن للبروكسي الاحتفاظ بشهادات لعدة أسماء مضيفين وإعادة توجيه الطلبات المفككة إلى حاويات داخلية منفصلة.

هل HTTP من البروكسي إلى الحاوية غير آمن دائمًا؟

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

هل يمكن للبروكسي العكسي توجيه HTTPS دون فك تشفيره؟

نعم. يمكن لتقنية تمرير TLS التوجيه باستخدام معلومات المصافحة مثل SNI بينما ينهي الخادم الخلفي TLS، لكن البروكسي يفقد الرؤية والتصفية العادية على طبقة HTTP.

لماذا يجب على الحاويات رفض الوصول الخارجي المباشر؟

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

الخلاصة النهائية

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