لاحظت للتو أن عناوين IP لعدد كبير من الأعضاء في منتداي تُخزَّن كـ 172.17.0.1. أنا لا أستخدم وكيلًا عكسيًا أو أي شيء آخر - لا يوجد شيء بينك وبين Docker الخاص بـ Discourse. هل لديك أي أفكار؟
هل تستخدم CloudFlare أو أي شيء مشابه؟
فقط لـ DNS (الوضع الرمادي). (تقنيًا، أعتقد أنني أستخدم الوضع البرتقالي لـ www.intfiction.org، لكنه سيتم إعادة توجيهه إلى النطاق الرئيسي intfiction.org قبل أن يصل إلى خادمي.) لدي ما يلي في ملف app.yml الخاص بي، رغم أنني لم أظن أن أيًا من الجزأين سيكون ذا صلة:
after_web_config:
- replace:
filename: /etc/nginx/nginx.conf
from: /sendfile.+on;/
to: |
server_names_hash_bucket_size 64;
sendfile on;
- file:
path: /etc/nginx/conf.d/discourse_redirect_1.conf
contents: |
server {
listen 80;
server_name www.intfiction.org;
return 301 $scheme://intfiction.org$request_uri;
}
ألا يكون ذلك ذا صلة فقط إذا كان هناك وكيل أمام خادمي؟
أنا أيضًا أواجه هذه المشكلة، بعد نقل منصة Discourse الخاصة بي إلى خادم جديد وقررت عدم استخدام Cloudflare.
أعدت تثبيت Discourse من الصفر ثم استعدت النسخة الاحتياطية الخاصة بي.
لم أضف خيار قالب Cloudflare مرة أخرى من ملف app.yml.
لقد جربت إضافة الكود من الموضوع الآخر أيضًا:
- replace:
filename: /etc/nginx/conf.d/discourse.conf
from: "types {"
to: |
set_real_ip_from 10.0.0.0/24;
set_real_ip_from 172.17.0.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
types {
إلى ملف app.yml، لكن المشكلة لا تزال قائمة:
يظهر جميع مستخدمو IPv6 عنوان IP الأخير الخاص بهم كـ 172.17.0.1.
تُظهر عناوين مستخدمو IPv4 بشكل مثالي.
لا يوجد وكيل عكسي أو أي شيء آخر قيد الاستخدام على هذا الخادم - فقط تثبيت Discourse القياسي كما هو موضح في الوثائق، حيث يخدم حركة المرور على المنافذ 80/443.
أعتقد أنني أعرف سبب حدوث هذا.
بالنسبة لـ IPv4، يقوم Docker بإدراج قواعد جدار الحماية في iptables لعكس ترجمة عناوين الشبكة (NAT) من عنوان/منفذ المضيف المكشوف إلى عنوان/منفذ الحاوية. وهذا يسمح للحاوية برؤية عنوان المصدر الأصلي.
أما بالنسبة لـ IPv6، فيستخدم Docker وكيلًا على مستوى مساحة المستخدم (docker-proxy) يقوم فقط بتحويل الإشارات من منفذ إلى آخر. وهذا يتسبب في أن ترى الحاوية عنوان المصدر على أنه localhost. وبما أن هذا الوكيل ليس وكيلاً مدركًا لبروتوكول HTTP، بل هو مجرد تحويل للمنافذ، فإنه غير قادر على إدراج رؤوس X-Forwarded-For.
لم يضيف مشروع Docker الأساسي دعمًا لإجراء ترجمة عناوين الشبكة (NAT) على IPv6، إما لأنهم يعتقدون أن NAT لـ IPv6 أمر غير مرغوب فيه، أو لأنهم لم يأتوا بعد إلى تنفيذه.
لكن يمكنك إصلاح ذلك عن طريق تمكين IPv6 لـ Docker ثم تشغيل حاوية تقوم تلقائيًا بإدراج قواعد NAT الصحيحة لـ IPv6.
راجع https://medium.com/@skleeschulte/how-to-enable-ipv6-for-docker-containers-on-ubuntu-18-04-c68394a219a2 للحصول على دليل حول كيفية إعداد ذلك.
TLDR: تأكد من عمل IPv6 في حاوياتك، ثم قم بتشغيل GitHub - robbertkl/docker-ipv6nat: Extend Docker with IPv6 NAT, similar to IPv4 · GitHub
هل هذا شيء يجب تغييره داخل التطبيق/حاوية Docker، أو خارجيًا، أو كليهما؟ أفترض أنه كليهما… لكن هذا يبدو وكأنه مهام إدارية عالية المستوى. إذا تم التأكيد على ذلك، فسيكون دليل سهل المتابعة حول كيفية تمكين Discourse (Docker) لبروتوكول IPv6 أمرًا ممتنًا للغاية.
سأحاول تنفيذ هذا على موقعي لاحقًا وسأحاول توثيق خطواتي. لست خبيرًا في Docker بأي حال، لكنني أعتقد أنه لن يكون صعبًا جدًا.
للأسف، كان هذا أكثر تعقيدًا مما توقعت بسبب معرفتي المحدودة بدوكر. حاليًا، أقوم بتجربة مجرد تمرير discourse عبر nginx يعمل على المنزل لتجاوز هذا القيد. إذا فشلت كل المحاولات، سأعود لاستخدام كلاودفلر، لكنني أفضل عدم الاعتماد عليهم لموقع يعمل بشكل صحيح.
ملاحظة سريعة لأي شخص مهتم: وضع Discourse خلف nginx هو الحل الأسهل لهذه المشكلة. استخدم الرابط الموجود في تعليقات ملف app.yml الافتراضي لإعداد Discourse على منفذ (socket). والفائدة الإضافية بالنسبة لي كانت القدرة على إعداد صفحة خطأ مخصصة تظهر أثناء عمليات إعادة البناء.