يا @Falco، هل يأتي عنوان IP الحقيقي (الذي توفره CF كرأس CF-Connecting-IP) إليك في سجلات nginx؟ لا يأتي إليّ. أرى فقط عنوان IP الخاص بـ cloudflared.
أعتقد أنه يجب القيام بأحد هذين الأمرين أو كليهما (سأتابع بعد التحقيق):
إضافة سطر تكوين set_real_ip_from إلى nginx لعنوان IP الخاص بـ cloudflared. إذا تبين أن هذه هي المشكلة، فأنا أخمن أنه لا يلزم وجود أي من أسطر set_real_ip_from الأخرى (الموفرة بواسطة templates/cloudflare.template.yml) لمستخدمي argotunnel. وفي هذه الحالة، ربما يجب إضافة قالب argotunnel منفصل إلى مستودع docker الذي يسحب عنوان IP الخاص بـ cloudflared الخاص بك من متغير بيئة أو شيء ما في app.yml الرئيسي الخاص بك.
إصلاح log_format. أعتقد أن هذه ليست المشكلة على الأرجح، على الرغم من ذلك. تم التأكد من عدم الحاجة إليها
تعديل:
هذا ما أفعله لجعله يعمل:
لا تستخدم قالب cloudflare. لا فائدة منه.
بدلاً من ذلك، ادمج هذا في app.yml الخاص بك:
hooks:
after_web_config:
- file:
path: /etc/nginx/conf.d/cloudflare_tunnel_real_ip.conf
contents: |
# استعادة عناوين IP الأصلية للزوار (ngx_http_realip_module)
set_real_ip_from 10.100.20.200/32; # نطاق عنوان IP الخاص بـ cloudflared/argotunnel الخاص بك
real_ip_header CF-Connecting-IP;
هذا ينتهي تلقائيًا في سياق http الخاص بـ nginx، وهو مناسب بالمناسبة.
ملاحظة: في رأيي، من أجل النظافة، يجب أن يقوم قالب cloudflare أيضًا بإنشاء تكوين nginx الخاص به في ملف منفصل بدلاً من استخدام sed -i لإضافته إلى /etc/nginx/conf.d/discourse.conf.
نعم يا @shyguy، لقد اتبعت الخطوات يا سيد @Falco
نعم، أنا في النفق، قبل أن أحصل على بعض الحماية من هجمات DDoS من Cloudflare، أعطت هجمات DDoS خادمي ارتفاعًا في وحدة المعالجة المركزية، وفي سجل الوصول 20 ميجابايت ورأيت فقط عنوان IP الخاص بـ Docker الخاص بي، لقد تحديت الزائر على مسار URL / لحماية الخادم ولكن انتهاء صلاحية ذاكرة التخزين المؤقت أعطى خطأ في الاستبعاد.
في حال لم يكن الأمر واضحًا، كان منشوري هناك يتعلق فقط بإصلاح تسجيل Nginx.
إذا لم تقم بإصلاحه، فستبدو جميع الطلبات في سجلات Nginx وكأنها قادمة من عنوان IP واحد (cloudflared الخاص بك) بدلاً من وجود عناوين IP الفعلية للعملاء.
عنوان IP هذا (أو نطاق IP) هو ما يتصل به cloudflared الخاص بك بـ Discourse منه، لذا يعتمد الأمر على إعداداتك. إحدى الطرق للتأكد هي النظر في ملف سجل Nginx والحصول على عنوان IP من هناك. ثم أضف /32 بعده.
إذا كنت تتبع دليله بالضبط، فأنا أخمن أنه سيكون 127.0.0.1/32.
لا، كان ذلك مجرد اقتراح لقالب cloudflare.template.yml - والذي لا يجب عليك استخدامه في هذا الإعداد.
فقط اتبع دليله في المنشور الأول ولكن تجاهل خطوة إضافة هذا القالب إلى تكوينك. بدلاً من ذلك، أضف الخطاف الذي قدمته.
مؤسف. هذا يبدو صحيحًا بالنسبة لي، لذلك لست متأكدًا مما هو الخطأ.
هذه هي الطريقة المفترض أن يعمل بها هذا:
يقوم وكيل Cloudflare بإضافة رأس CF-Connecting-IP يحتوي على عنوان IP الخاص بالعميل
تم تجميع Nginx في Discourse باستخدام ngx_http_realip_module - وهو برنامج يقرأ هذا الرأس ويقوم بتصحيح السجلات وما إلى ذلك لإظهار عنوان IP الفعلي للعميل
يتيح set_real_ip_from هذه الميزة للاتصالات من نطاقات IP المقدمة إليه. عادةً ما تكون هذه نطاقات IP الخاصة بـ Cloudflare (المقدمة من القالب المساعد cloudflare.template.yml)، ولكن نظرًا لأنك تستخدم Argotunnel، فستستخدم ببساطة عنوان IP الخاص بـ Argotunnel بدلاً من ذلك.
جرب تعطيل الخطاف الخاص بي. هل ترى نفس عنوان IP في سجلات Nginx الخاصة بك قبل وبعد؟
ربما يكون الاختلاف الوحيد في إعداداتنا هو أنني أقوم بتشغيل Argotunnel (cloudflared) في Docker.
إذا كنت ترغب في تجربة ذلك…
لقد أنشأت شبكة خاصة بـ cloudflared:
services:
cloudflared:
image: cloudflare/cloudflared:latest
container_name: cloudflared
command: tunnel run
restart: unless-stopped
networks:
wan:
cf_tunnel:
# لـ ngx_http_realip_module
# اضبطه على عنوان IP مرتفع حتى يتمكن Docker من تعيين عنوان IP
# ل حاوية أخرى إذا بدأت قبل cloudflared
ipv4_address: 10.200.10.200 # هذا هو عنوان IP لـ `set_real_ip_from` في nginx
volumes:
# يجب أن تكون مملوكة لـ uid:gid 65532:65532
- ./conf:/home/nonroot/.cloudflared
networks:
cf_tunnel:
external: true # يعني فقط شبكة غير مُدارة بواسطة compose
# للأداء:
# https://github.com/quic-go/quic-go/wiki/UDP-Receive-Buffer-Size
# sudo nano /etc/sysctl.conf
# أضف هذا السطر:
# net.core.rmem_max=2500000
# (كانت قيمتي القديمة 212992 - تحقق منها باستخدام: sudo sysctl net.core.rmem_max)
يمكنك نقل التكوين/الشهادة الخاصة بك إليه في دليل conf (تذكر استخدام chown كما هو موضح في الملاحظة الموجودة في ملف التركيب) أو فقط اتبع إجراء الإعداد مرة أخرى. يمكنك تشغيل أوامر cloudflared لتسجيل الدخول أو أي شيء آخر مثل هذا:
docker run -it --rm -v /path/to/conf:/home/nonroot/.cloudflared cloudflare/cloudflared:latest YOUR_CMD_HERE
ثم يتعين عليك ربط حاوية Discourse الخاصة بك بالشبكة. يمكنك القيام بذلك بإضافة هذا في نهاية ملف yml الخاص بالحاوية:
docker_args:
- '--network=cf_tunnel' # اختياريًا، يمكنك أيضًا تعيين عنوان IP ثابت هنا
هل نجح أي شخص في تشغيل حاوية خادم البريد الوارد الخاص بـ Discourse عبر نفق Cloudflare؟
لقد واجهت مشكلة في إعداد خادم بريد آخر خلف نفق Cloudflare في الماضي، ولكن يمكنني تشغيل التطبيقات على جهازي Raspberry Pi التي تستخدم المنافذ 80 و 443 بشكل جيد.
لقد قمت بإعداد Discourse على الخوادم عدة مرات ولست قلقًا جدًا بشأن حاوية Discourse الرئيسية في الوقت الحالي.
أعتقد أن هذا مرتبط، ولكن يرجى إنشاء منشور جديد من ردي إذا كنت تشعر أنه خارج الموضوع.
لقد استخدمت خدمة argo. استسلمت عندما دفعت 28 يورو للشهر الأول. كان هناك بالفعل فرق لا يقل عن 200 مللي ثانية. ومع ذلك، ألغيت الاشتراك لأنني لم أتمكن من تحمل دفع 28 يورو كل شهر مقابل 200 مللي ثانية. المواقع الأكبر سيكون لديها فواتير أكثر، ضع ذلك في اعتبارك.
يبلغ عدد الزيارات للموقع 800-1000 مستخدم فريد. يمكنك الحساب وفقًا لذلك.
هذا هو الشيء هههه إنه 64 بت. لكنني اكتشفت الأمر. قمت بترقية apt get وأعدت تشغيل خدمة cloudflare وتم التحميل. هل تعلم أيضًا ما إذا كانت cloudflare تحد من تحميل مقاطع الفيديو باستخدام النفق؟ أواجه مشكلات في تحميل مقطع فيديو بحجم 20 ميجابايت ولم أكن كذلك من قبل
