أكره حقًا القيام بشيء غير عادي هنا. أكره ذلك بقدر أي شخص آخر، لكن هذا كل ما أعرف كيف أفعله وكيف تعمل جميع تطبيقاتي الأخرى المستضافة ذاتيًا.
لدي سجل A البري الخاص بي يشير إلى عنوان IP داخلي على شبكتي والذي يتم تصدير المنفذين 80 و 443 بواسطة مدير وكيل nginx، والذي يحتوي على شهادات SSL الخاصة بي معدة بالكامل. لدي معظم كل شيء على شبكتي الحالية معدًا باستخدام docker، لذا فإن مدير وكيل nginx آمن للاستخدام لأنه يستخدم فقط شبكة docker للوكالة عبر http.
في حالة discourse، حاولت إعداد discourse.MYDOMAIN.com إلى عنوان IP محلي منفصل ضمن سجل A منفصل وجعلته يحل؛ ومع ذلك، فإن إعداد مدير وكيل nginx باستخدام lets encrypt يعمل وكيفية إعداد discourse لا يعمل مع عناوين IP الداخلية.
لذلك… أريد فقط وكالة عكسية. سأحاول تجربة جميع أنواع تكوينات وكيل nginx لجعل هذا يعمل. أنا قلق قليلاً بشأن هجمات الوسيط، لكنني أود معرفة سبب عمل تكوين lets encrypt لمدير وكيل nginx مع التكوين الداخلي ولا يعمل discourse.
يجب أن تكون هناك طريقة!
(ملاحظة: أعرف أنني مشوش الذهن. يرجى طرح أسئلة محددة ويمكنني تقديم توضيح)
هناك بعض المواضيع حول تشغيل Discourse خلف مدير وكيل nginx. في الأساس، تقوم بتكوين Discourse لعدم الارتباط بأي منافذ وإضافة التسميات المطلوبة في قسم labels: في ملف app.yml الخاص بك.
إذا اتبعت مسار مدير وكيل Nginx، وهو ما قمت بإعداده حاليًا (على عكس إعداد Let’s Encrypt على جهاز Discourse الافتراضي نفسه)…
سأحتاج إلى الارتباط بالمنفذ 80 على جهاز Discourse الافتراضي لأنه جهاز منفصل في حالتي.
خبرتي الحالية هي أنني أحصل على أخطاء المحتوى المختلط مع تكويني الحالي لمدير وكيل Nginx مع إعداد SSL هناك يشير إلى عنوان IP لجهاز Discourse الافتراضي على المنفذ 80.
لا أعتقد أنه من الممكن التخلص من هذا نظرًا لأن المراجع http:// في الكود مكتوبة بشكل ثابت… أم أنني مخطئ؟ هل هذا هو ما سيغيره حقل التسميات الذي أشرت إليه؟
لا يمكنني إعداد مقبس Unix… جهاز Discourse الافتراضي الخاص بي موجود على جهاز منفصل. العودة إلى الخطة الأصلية. دعني أرى ما إذا كان بإمكاني اكتشاف تمكين force_https من خلال بعض المشاركات الأخرى في المنتدى. للعلم، هذه هي الخطوة التي لا يمكنني القيام بها.
بمجرد أن قمت بالوكيل العكسي إلى المنفذ 80 لجهاز discourse الافتراضي وتمكنت من التسجيل وما إلى ذلك، فقد تم الأمر بتعيين force_https باستخدام الواجهة الرسومية وإضافة علامة x-forwarded-proto في علامة التبويب المتقدمة لـ nginx proxy manager.