ماذا يقول السجل production.log (داخل حاوية Docker قيد التشغيل) عند محاولة تسجيل الدخول بالفشل (وبالتالي مع force_https=true)؟
@RGJ – أعجبني حلّك! هل عليّ استخدام force-https مع آخر اقتراح؟ بخصوص proxy_pass https. تعديل: أحصل على خطأ 502 إذا اكتفيت باستخدام proxy_pass https://192.168.86.108 فقط. تعديل 2: قمت بإخفاء المنفذ 80 في Discourse عبر ملف app.yml ومع ذلك ظلت المشكلة قائمة — لقد أعدت قراءة منشورك، هل يحتوي حاوية Discourse على مثيل خاص بها من Nginx؟ إذن، بعبارة أخرى، أنا أقوم بإرسال وكيل إلى وكيل؟ آسف، أنا مشوش جدًا في هذه المرحلة.
@itsbhanusharma هل يجب أن أضع علامة تعليق على 80:80 #http وأتبع نصيحة @RGJ لاستخدام proxy_pass https؟
لماذا لا تتبع العملية المدعومة للمواقع المتعددة هنا؟ فأنت في الواقع تعيد اختراع عجلة هشة للغاية.
تم توفير العديد من الروابط الآن، @Stephen، لدرجة أنني في حيرة من أمري ولا أستطيع فهم كل هذا. ظننت أنني أتبع العمليات المدعومة. أليست التعليقات أعلاه مدعومة؟ 
نعم، لأنك لم تكن تستخدم force_https، ومن هنا وسم unsupported-install أعلاه. إذا انحرفت عن مسار مدعوم، فلن تحصل على الكثير من المساعدة.
ابدأ من هنا:
هناك دليل منفصل للتعامل مع تغليف SSL في حالة تعدد المواقع.
إذن، هل الحاوية القياسية تعمل فقط مع http؟ كيف يمكن أن يكون ما أحاول فعله متعدد المواقع؟ أنا لا أحاول استضافة نطاقات متعددة؛ لدي نطاق واحد فقط. هل يمكنك توضيح كيفية معالجة ذلك لمشكلتي؟
ماذا قصدت بـ:
لقد قمت بإعداد خوادم Discourse في حوالي 5 حالات، وجميعها تظهر سلوكًا غريبًا؛ لست متأكدًا مما إذا كان هذا عيبًا فعليًا أم أن أي شخص آخر لديه خبرة مماثلة.
بنية تحتية مستقلة، غير مرتبطة ببعضها البعض بأي شكل من الأشكال.
لكن جميعها تحمل إعدادات متشابهة جداً كما هو موضح أعلاه.
إذن، لماذا يقوم nginx بعمل وكيل للمضيف أساسًا؟ وماذا يحدث آخر على الأجهزة؟
لدينا عدة آلات افتراضية (VMs) غير معرّضة خارجيًا، حيث يُوجَّه المرور عبر الوكيل (وهو معرَّض خارجيًا) إلى آلة Discourse الافتراضية داخليًا. الوضع مماثل في كل من التثبيتات المنفصلة. هل هذا يوضّح الأمر؟
ليس حقًا، لكن بطريقة أو بأخرى، هذا ألم تقني ستضطر إلى التعايش معه. من المستحيل التعليق على ما إذا كان هناك نهج أفضل عندما تكون حالة الاستخدام والطوبولوجيا غامضة للغاية.
أعتقد أن المزيج الصحيح من الحلول كان كالتالي:
وفقًا لـ @itsbhanusharma:
تعديل /var/discourse/containers/app.yml وتغيير المنافذ إلى قيم مخصصة، استخدمتُ:
- "8080:80" #http
- "4343:443" #https
نفذت الأمر ./launcher rebuild app
ثم قمت بتعديل الوكيل الخارجي القابل للوصول لتوجيه الطلبات على المنافذ 80/443 إلى http://internal_ip:8080
بعد تنفيذ sudo nginx -t و sudo systemctl restart nginx، سجلت الدخول إلى خادم https://discourse.mobiusnode.io (الذي كان لا يزال يعاني من المشاكل المذكورة أعلاه) وقمت بتفعيل خيار force_https، وعندئذٍ يبدو أن كل شيء يعمل بشكل صحيح.
سأقوم الآن بتكرار هذه الخطوات على الخوادم/البنية التحتية المتبقية.
للتوضيح فقط، هذا ليس ما اقترحته.
لقد طلبت منك فقط فتح المنفذ 80 على عنوان IP محلي وإنهاء اتصال SSL على وكيل العكس الخاص بك.
إذن، عدم استخدام SSL على الوكيل الظاهر الخارجي الخاص بي، بل توجيه طلبات http العادية إلى خادم Discourse والسماح لـ force_https بمعالجة هذه الطلبات؟ كيف يتم بعد ذلك تمرير الشهادة؟ عبر مثيل Nginx الأول؟ هذا هو المكان الذي تتعطل فيه الأمور بالنسبة لي.
حسناً، طالما أنها تعمل ويمكنك إعادة البناء/الترقية بنجاح. يبدو أنك تقوم بالفعل بما اقترحه @itsbhanusharma في منشوره الأخير.
إذا كنت تشارك عنوان IP واحدًا مع اتصالات SSL متعددة، فستحتاج إلى شهادة SAN في الواجهة الأمامية للوكيل الخاص بك. إذا كانت الشبكة آمنة، فيمكن أن يكون كل ما خلفها غير مشفر.
تتطلب Discourse force_https إذا اتصل المستخدم عبر SSL، ويجب عليك التأكد من حفظ وتحويل رأس الرأس المذكور أعلاه.
لا، هناك شيء يُعرف بـ SNI.
أنا أدرك ذلك تمامًا، ولكن بما أن جميع الشهادات تأتي من Let’s Encrypt، فما هي القيمة في طلب شهادات منفصلة؟ تدعم Let’s Encrypt SAN، فلماذا لا نستخدمها؟