لقد واجهت مشاكل في يوليو مع الكثير من الطلبات من سنغافورة. قمت بحظر نطاق IP، مما نجح لفترة من الوقت، لكن المشكلة عادت بشكل أقوى في أغسطس (من سنغافورة وهونغ كونغ والمكسيك) مع تكلفة CDN عالية وغير متوقعة
لاحظت ارتفاعًا في عدد مشاهدات الصفحات من Amazonbot و DataForSeoBot و meta-externalagent و SeekportBot، إلخ…
هذه القائمة لا تحتوي على بعض الزواحف الأكثر زيارة لدي، ولكن لدي سؤال على أي حال.
هل سيكون من المستحسن إضافة هذه القائمة بأكملها إلى إعداد وكلاء الزحف المحظورين؟
هل هناك طريقة لإضافة أسماء الروبوتات بشكل جماعي من ملف .txt؟
تأتي الزواحف بنية فهرسة موقعك في محركات البحث، لذا يجب أن يكون ارتفاع حركة المرور منها ضئيلاً إلا إذا كانت هذه روبوتات تخفي نفسها كزواحف. لا ترغب العديد من المنتديات في فهرستها بواسطة الزواحف وهذا هو الخيار للقيام بذلك: تحمل الزواحف هوية/مرجعًا لمصدرها، لذا هنا يمكنك إضافة أي اسم تريده يسمح فقط لهذا المصدر بالزحف (آه، يا لها من كلمة غريبة )
المصدر الأكثر احتمالاً المسؤول عن زيادة حركة المرور لديك هو الروبوتات ويجب عليك التحقق من سجلات خادمك لهذا الغرض. إذا كنت تعرف شخصًا يعرف فقط الأساسيات جدًا في لينكس، فسأقترح أداة الإعداد لمدة دقيقتين هذه لحظر البلدان التي تتمتع بسمعة سيئة في الروبوتات (قد تجد هذا بسهولة عبر الإنترنت). بعد إعداده، لا يزال من الجيد إخبار مجتمعك بأنهم قد يحتاجون إلى VPN للوصول إلى موقعك إذا انتهى بهم الأمر في عطلة في تلك البلدان. إليك الأداة، إنها فعالة، وستقطع 80-90٪ من الطلبات غير الضرورية إلى خادمك. لديك وضعان ويجب عليك الاختيار بينهما: البلدان المسموح بها، أو البلدان المحظورة.
هل أنت متأكد تمامًا من ذلك؟ لأنه إذا كان هذا صحيحًا، فسأبدأ في استخدام وكيل عكسي على الفور.
تعديل
قال الذكاء الاصطناعي هنا نفس الشيء. لذا، سيكون وكيل عكسي.
إجابة الذكاء الاصطناعي
يستخدم المكون الإضافي GeoBlock لـ Discourse قاعدة بيانات MaxMindDB لتحديد بلد المستخدم أو شبكته (ASN) بناءً على عنوان IP الخاص به، ولكن الحظر الفعلي يحدث على مستوى التطبيق (داخل تطبيق Discourse)، وليس على مستوى الخادم أو الشبكة/جدار الحماية.
في الممارسة العملية:
إذا تطابق عنوان IP للزائر مع بلد أو شبكة محظورة، فإن تطبيق Discourse يعيد صفحة خطأ إلى الزائر بدلاً من محتوى المنتدى.
لا يحدث الحظر إلا بعد وصول طلب HTTP إلى تطبيق Discourse. بعبارة أخرى، لا تزال الطلبات تمر عبر خادم الويب الخاص بك (مثل nginx) وحاوية Docker وتصل إلى برنامج Discourse قبل حظر المستخدم.
هذا يعني أنك ستظل ترى هذه الطلبات في سجلات الخادم والوكيل/nginx الخاصة بك، حتى لو تم حظر المستخدم في النهاية بواسطة Discourse.
إذا كنت بحاجة إلى حظر “صارم” (منع الوصول حتى قبل وصول الطلب إلى تطبيق Discourse)، فستحتاج إلى حل GeoIP على مستوى الخادم (مثل الحظر على مستوى nginx/iptables أو أداة خارجية).
ملخص:
لا يحظر المكون الإضافي Discourse GeoBlock الطلبات على مستوى الشبكة/الخادم، ولكن فقط بعد أن يقوم تطبيق Discourse بمعالجة الطلب. إذا كنت بحاجة إلى منع أي وصول قبل أن يرى تطبيقك الطلب، فيجب عليك استخدام نهج GeoIP على مستوى الخادم.
لم أستخدم مشاركة المحادثة لأنني سألت باللغة الفنلندية وأنتم على الأرجح لا تستطيعون فهمها
يعني أن صفحتك يتم الوصول إليها، لذا نعم أنت في طبقة أقرب إلى الخادم من حظر يتم على مستوى جدار الحماية، ومع ذلك لا يعني ذلك أنها مشكلة أمنية تتطلب وكيلًا عكسيًا.
الأداة التي اقترحتها تقلل الطلبات بنسبة 80٪ بالفعل، والـ discourse تطبيق آمن، الآن إذا كان لديك أشياء أخرى مستضافة على خادمك مثل موقع ويب، فقد يكون الوكيل العكسي مفيدًا، وفي غضون ذلك، هناك حلول أخرى لحظر عناوين IP ذات السمعة السيئة مثل Crowdsec، اسأل الذكاء الاصطناعي الخاص بك عن Crowdsec light
(مؤلف المكون الإضافي للحظر الجغرافي هنا)
نعم، يوقف المكون الإضافي للحظر الجغرافي الطلبات على مستوى التطبيق، على الرغم من أنه يفعل ذلك في مرحلة مبكرة جدًا. السبب في ذلك هو أنه تم تصميمه لعرض صفحة خطأ سهلة الاستخدام، لذلك يجب أن يكون قادرًا على تحميل أصول Discourse وعرض تلك الصفحة. كما أنه يسجل أي حظر في /logs إذا تم تكوينه للقيام بذلك.
تشمل المزايا الأخرى لهذا النهج القدرة على تكوين البلدان والشبكات المحظورة من داخل Discourse والقدرة ليس فقط على حظر الوصول ولكن أيضًا لفرض الإشراف.
إذا كنت قلقًا بشأن تضخم السجلات أو استهلاك نطاق التردد الخاص بشبكة توصيل المحتوى (CDN)، فالمكون الإضافي ليس لك، ولكن بصراحة لا أعتقد أن هذين الأمرين مهمان كثيرًا.
)
