رموز المواقع، الصور الرمزية، وأخطاء الشهادات

[markcichy (Mark)]

إليك رابط لأحد النسخ:
https://discourse.mobiusnode.io

إنه معطل. X-Forwarded-Proto موجود في كتلة الخادم الخاصة بي. إذن، العنصر (العناصر) الوحيد الذي لا أستخدمه - استنادًا إلى الروابط التي شاركتموها جميعًا - هو هذا:

# القوالب الأساسية المستخدمة؛ يمكن تقليلها لتشمل وظائف أقل لقوالب الحاويات:
# - "templates/cron.template.yml" # تم تضمين cron الآن في صورة الأساس
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/sshd.template.yml"
- "templates/web.template.yml"
# - "templates/web.ssl.template.yml" # إزالة - سيتم التعامل مع HTTPS بواسطة nginx الخارجي
- "templates/web.ratelimited.template.yml"
- "templates/web.socketed.template.yml" # <-- تمت الإضافة
# أي المنافذ التي سيتم كشفها؟
# expose: قم بتعليق القسم بأكمله

[itsbhanusharma (Bhanu Sharma)]

لقد فتحت الموقع في ثلاثة متصفحات (إيدج، فايرفوكس، وكروم للجوال) وحصلت على شهادة آمنة تمامًا كمستخدم مجهول. ما هي الخطوات التي اتبعتها لتكرار هذه المشكلة؟

[markcichy (Mark)]

سجّل كـمستخدم، وبعد التسجيل وتسجيل الدخول، تتفاقم الأمور تمامًا وأواجه الأخطاء المذكورة سابقًا.

[itsbhanusharma (Bhanu Sharma)]

حسناً، سأقوم بالتسجيل كمستخدم وهمي عبر فايرفوكس الآن.

[itsbhanusharma (Bhanu Sharma)]

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

[markcichy (Mark)]

لا. من المرجح أنها ذهبت إلى مجلد المهملات أو البريد العشوائي. لا توجد شكاوى من أي مستخدمين في هذا الصدد.

[itsbhanusharma (Bhanu Sharma)]

لم يحدث انفجار في الجحيم هنا. إحدى المشكلات المحتملة هي أن رسائل البريد الإلكتروني الخاصة بك لا تزال تحتوي على رابط http://. ومع ذلك، تم إعادة توجيهي بشكل صحيح إلى موقع HTTPS لتفعيل حسابي، ولا أرى أي أخطاء متعلقة بـ SSL هنا.

لذا، نعم، أنا متأكد بنسبة 99% من أن force_https غير مفعّل، أو أن هناك خطأ فادحًا جدًا في تثبيتك يسبب هذه المشكلة.

[markcichy (Mark)]

لديك إعادة توجيه في كتلة الخادم الخاصة بك، لذا لا يهم أي رابط يظهر هناك. فسيتم إعادة التوجيه دائمًا إلى https.

[itsbhanusharma (Bhanu Sharma)]

@markcichy

لا يهم أي رابط يُظهر هناك

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

[markcichy (Mark)]

هذا لا يبدو منطقياً بالنسبة لي. إذا قمنا بتحليل الأمر منطقياً، فأنا أقوم فعلياً بنفس ما يهدف إليه force-https، لكن باستخدام كتلة الخادم.

[markcichy (Mark)]

أيضًا، عند تفعيل force-https، يتعطل موقعي ولا يستطيع المستخدمون المصادقة.

[itsbhanusharma (Bhanu Sharma)]

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

@markcichy

أيضًا، عندما أفعّل force-https ينهار موقعي، ولا يستطيع المستخدمون المصادقة.

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

[markcichy (Mark)]

جميع “الحلول” التي طُرحت لا تتناسب مع حالت الاستخدام المحددة لدي:

• خادم بعيد (ضمن الشبكة نفسها) — أعتقد أن جميع الأمثلة تفترض أن Nginx يعمل على نفس الخادم الذي يعمل عليه Discourse، بينما أنا أستخدم proxy_pass للوصول إلى عنوان IP داخلي آخر.

لماذا فعلت ذلك؟ من أجل أمان أعلى وتوزيع الموارد. هذا هو السبب نفسه الذي دفعني إلى تقسيم الخدمات بطريقتين: عبر الحاويات وآلات افتراضية. يبدو أن الوثائق المقترحة تميل إلى افتراض حالة تعمل فيها جميع الخدمات على نفس الخادم.

أتخيل أن الظروف المذكورة أعلاه شائعة إلى حد ما. إذا كان أي من هذه الظروف يمكن استخدامه لاستيعاب حالة proxy_pass، فسأكون سعيدًا جدًا بتعديل إعداداتي لتناسب ذلك. لكنني أشعر أن تقديم عبارة عامة مثل “أنت وحدك في هذه الحالة” لمجرد أنني أحاول تجنب وضع “كل بيضاتي في سلة واحدة” أمر غير مبرر إلى حد ما.

[itsbhanusharma (Bhanu Sharma)]

proxy_pass 192.168.20.10:8080

في discourse، اعرض 192.168.20.10:8080:80

أزل قالب socketed.

فعّل force_https

الربح.

[markcichy (Mark)]

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

أسئلة فورية:

1. في ملف app.yml، هل نغير منفذ الاستماع الافتراضي إلى 8080؟
2. ماذا عن SSL على المنفذ 443؟ هل نتركه كما هو؟
3. هل نزيل إعادة التوجيه من المنفذ 80 في كتلة خادم Nginx؟
4. هل يؤثر الأمر رقم 3 إذا كنت أغير فقط proxy_pass على الجانب الداخلي؟ ربما لا؟ أنا أعيد التوجيه ببساطة إلى 8080؟
5. السؤال الأكبر: لماذا؟ لماذا سيُحدث هذا فرقًا عند التغيير من 80 إلى 8080؟
6. هل نبقي جميع القوالب الأخرى نشطة؟ هل نعلق socketed فقط؟

شكرًا لك على مساعدتك وصبرك.

[itsbhanusharma (Bhanu Sharma)]

@markcichy

هل يجب تغيير منفذ الاستماع الافتراضي في ملف app.yml إلى 8080؟

هذا تفضيل شخصي، لقد كتبتها كمثال. يمكنك أيضًا اختيار كشف المنفذ 80.

@markcichy

ماذا عن SSL 443؟ هل نتركه على 443؟

لا توجد فائدة أو منطق في تمكين SSL على شبكة محلية.

@markcichy

هل يجب إزالة إعادة التوجيه من المنفذ 80 في كتلة خادم Nginx؟

يجب أن يكون هذا موجودًا.

server {
    listen 80;
    server_name discourse.example.com;
    return 301 https://example.com$request_uri;
}

@markcichy

هل النقطة رقم 3 مهمة إذا كنت سأقوم فقط بتغيير proxy_pass على الجانب الداخلي؟ ربما لا؟ أنا فقط أعيد التوجيه إلى 8080؟

هذا بالضبط ما يحدث، فأنت تقوم بتوجيه جميع الطلبات التي يستقبلها الوكيل/مدخل الدخول (proxy/ingress) إلى خادم خلفي داخلي على المنفذ 8080 (أي discourse).

@markcichy

أكبر سؤال: لماذا؟ لماذا سيؤدي هذا إلى فرق عند التغيير من 80 إلى 8080؟

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

@markcichy

هل يجب إبقاء جميع القوالب الأخرى نشطة؟ هل أعلق socketed فقط؟

لا تحتاج تحديدًا إلى أي شيء يتعلق بالمقابس (sockets) أو SSL على الخادم الداخلي. يجب إنهاء SSL بشكل صحيح على الوكيل العكسي (reverse-proxy).

ملاحظة: معظم ذلك يعتمد على تفضيل شخصي بناءً على النشر للعملاء.

[markcichy (Mark)]

حسناً. شكراً لتعليقاتكم.

إليك كتلة خادم Nginx الخاصة بي، للمعلومة:

server {
        # ssl
        listen  443 ssl  http2;
        listen [::]:443 ssl http2;

        server_name discourse.mobiusnode.io;

        location / {
                # حركة مرور HTTP
                proxy_pass http://192.168.86.108;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header Host $http_host;
                proxy_http_version 1.1;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto https;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";

        }

    ssl on;
    ssl_certificate /path/to/certificate/domain.io/fullchain.pem; # تم إدارته بواسطة Certbot
    ssl_certificate_key /path/to/certificate/domain.io/privkey.pem; # تم إدارته بواسطة Certbot

    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
    ssl_protocols TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

    add_header Strict-Transport-Security "max-age=63072000;";
    ssl_stapling on;
    ssl_stapling_verify on;

    client_max_body_size 0;

}

server {
    if ($host = discourse.mobiusnode.io) {
        return 301 https://$host$request_uri;
    } # تم إدارته بواسطة Certbot

    listen 80;
    listen [::]:80;

    server_name discourse.mobiusnode.io;
    return 404; # تم إدارته بواسطة Certbot

}

[markcichy (Mark)]

السلوك الذي أواجهه يحدث تحت الشروط المذكورة أعلاه.

يبدو بداية ملف app.yml كالتالي:

## هذا هو قالب حاوية Docker المستقل الشامل لـ Discourse
##
## بعد إجراء تغييرات على هذا الملف، يجب عليك إعادة البناء
## /var/discourse/launcher rebuild app
##
## كن *حذرًا جدًا* عند التعديل!
## ملفات YAML حساسة للغاية للأخطاء في المسافات البادئة أو المحاذاة!
## قم بزيارة http://www.yamllint.com/ للتحقق من صحة هذا الملف عند الحاجة

templates:
- "templates/postgres.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.ratelimited.template.yml"
## قم بإلغاء التعليق عن هذين السطرين إذا كنت ترغب في إضافة Lets Encrypt (https)
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"

## ما هي منافذ TCP/IP التي يجب أن تعرضها هذه الحاوية؟
## إذا كنت تريد لـ Discourse مشاركة منفذ مع خادم ويب آخر مثل Apache أو nginx،
## راجع https://meta.discourse.org/t/17247 للحصول على التفاصيل
expose:
- "80:80" # http
- "443:443" # https

params:
db_default_text_search_config: "pg_catalog.english"

## قم بتعيين db_shared_buffers إلى الحد الأقصى 25% من إجمالي الذاكرة.
## سيتم تعيينها تلقائيًا بواسطة bootstrap بناءً على الذاكرة المكتشفة، أو يمكنك تجاوزها
db_shared_buffers: "1024MB"

## يمكن أن يحسن أداء الفرز، لكنه يزيد من استخدام الذاكرة لكل اتصال
#db_work_mem: "40MB"

## أي إصدار Git يجب أن تستخدمه هذه الحاوية؟ (الافتراضي: tests-passed)
#version: tests-passed

[RGJ (Richard - Communiteq)]

أنت تتصل بالمنفذ 80 على خادم nginx الثاني، لذا يعتقد أنه اتصال بـ http وليس https.

حاول العثور على X-Forwarded-Proto في خادم nginx الداخلي، وقم بتغيير proxy_set_header X-Forwarded-Proto $thescheme; إلى proxy_set_header X-Forwarded-Proto https;

أو قم بتوجيه حركة المرور الخاصة بك إلى https proxy_pass https://192.168.86.108

[itsbhanusharma (Bhanu Sharma)]

@markcichy

- "80:80" # http
- "443:443" # https

يتطلب هذا الجزء التعديل