كيفية التحقق من أن الوكيل العكسي يرسل عنوان IP الصحيح للعميل

إيفا وونغ

IceWhale author

إيفا وونغ هي كاتبة تقنية و ومهندسة هاوية في ZimaSpace. مهووسة بالتكنولوجيا مدى الحياة ولديها شغف بالمختبرات المنزلية والبرمجيات مفتوحة المصدر، تتخصص في تبسيط المفاهيم التقنية المعقدة إلى أدلة عملية وسهلة الفهم. تؤمن إيفا بأن الاستضافة الذاتية يجب أن تكون ممتعة وليست مخيفة. من خلال دروسها، تمكّن المجتمع من تبسيط إعدادات الأجهزة، بدءًا من بناء أول نظام تخزين شبكي NAS وحتى إتقان حاويات Docker.

How to Verify a Reverse Proxy Is Sending the Correct Client IP

تحقق من تمرير عنوان IP الخاص بالعميل من خلال مقارنة مصدر خارجي معروف مع كل رأس وكيل وعنوان التحليل النهائي في الخادم الخلفي.

يقوم الوكيل العكسي بإنهاء اتصال العميل، لذا يرى الخادم الخلفي عادةً عنوان المقبس الخاص بالوكيل ما لم يمرر الوكيل بيانات تعريف الطلب الموثوقة. يجب أن يميز الاختبار عنوان النظير المباشر عن Forwarded وX-Forwarded-For وX-Real-IP، ويوثق كل قفزة موثوقة، ويثبت أن العميل من الإنترنت لا يمكنه تزوير القيمة المستخدمة للسجلات أو حدود المعدل أو التحكم في الوصول.

إنشاء اختبار عنوان IP للعميل معروف من خارج المنزل

استخدم جهازًا على بيانات الجوال أو شبكة خارجية أخرى وسجل عنوان IPv4 أو IPv6 العام الخاص به فورًا قبل الطلب. أرسل مسارًا فريدًا أو قيمة استعلام أو طابع زمني عبر الوكيل العكسي العام.

تصف MDN X-Forwarded-For كرأس فعلي للحفاظ على عنوان العميل الأصلي عبر اتصالات الوكيل.

اجمع سجل وكيل الحافة، وأي سجل وكيل وسيط، وسجل تطبيق الخادم الخلفي لذلك الطلب الواحد. بدون مصدر معروف وطابع زمني مرتبط، يمكن لعدة مستخدمين متزامنين جعل سلسلة الرؤوس غامضة.

سجل عنوان النظير للمقبس وكل رأس تم تمريره

في الخادم الخلفي، سجّل عنوان النظير TCP المباشر بشكل منفصل عن Forwarded وX-Forwarded-For وX-Real-IP وأي رأس عميل خاص بشبكة CDN. لا تقم بالكتابة فوق القيم الخام أثناء الاختبار الأول.

تحليل عملي لكيفية التعامل مع عنوان IP "الحقيقي" للعميل يحذر من أن الدقة تعتمد على كيفية تعيين الوكيل للرؤوس أو إلحاقها وما إذا كان يمكن تزوير القيم السابقة. يجب أن يتطابق نموذج الثقة الكامل للوكيل مع البنية التحتية الفعلية للشبكة.

يجب أن يكون عنوان النظير للمقبس في الخادم الخلفي مساويًا للوكيل الموثوق المباشر، بينما يجب أن يساوي عنوان العميل المختار الجهاز الخارجي للاختبار. إذا سجّل الخادم الخلفي عنوان الوكيل فقط، فهذا يعني أن إنشاء الرأس أو تحليله مفقود.

تحقق من كيفية إضافة أو استبدال كل وكيل للرأس

افحص كل قفزة من CDN أو نفق إلى وكيل الحافة، والوكيل الداخلي، والتطبيق. سجّل ما إذا كانت كل قفزة تلحق بقائمة موجودة، أو تستبدل مدخلات غير موثوقة، أو تمرر الرأس دون تغيير.

تشرح Sling Academy أن NGINX يمكنه تعيين X-Real-IP من الاتصال المباشر وإلحاق سلسلة باستخدام proxy_add_x_forwarded_for.

قم بتكوين أول وكيل حافة موثوق لإزالة أو استبدال رؤوس التوجيه المقدمة من العميل، ثم ألحِق العناوين في القفزات الداخلية المسيطر عليها. تجنب قبول القيمة اليسرى أو اليمنى بشكل أعمى دون تحديد عدد الوكلاء الموثوقين.

Featured

ZimaCube 2 سحابة شخصية منزلية NAS

ZimaCube2

تكوين الخادم الخلفي ليثق فقط بعناوين الوكلاء المعروفة

اضبط قائمة الوكلاء الموثوقين في التطبيق أو خادم الويب على عناوين الوكلاء العكسيين الدقيقة أو الشبكات الفرعية المسيطر عليها. تأكد من أن الاتصالات المباشرة من عملاء LAN العاديين أو الإنترنت لا تُعامل كمصادر رؤوس موثوقة.

توضح Ip2Geo أن اتصال التطبيق ينشأ من موازن التحميل أو الوكيل العكسي وأن تحليل عنوان IP الأصلي بأمان يتطلب قاعدة قفزة موثوقة بدلاً من قبول مدخلات عشوائية.

إذا تغير عنوان الوكيل بسبب الحاويات أو الشبكات التراكبية أو CDN، فوثق النطاق المدعوم وقم بتحديثه عن قصد. لا تثق بجميع العناوين الخاصة لمجرد أن الوكيل يستخدم واحدًا حاليًا.

قم بإجراء اختبار رأس مزور

من جهاز الاختبار الخارجي، أرسل قيمة مزورة لـ X-Forwarded-For أو Forwarded أثناء الاتصال عبر الوكيل الحقيقي. قارن الرأس الوارد الخام، ورأس الوكيل الموحد، وعنوان العميل المختار في الخادم الخلفي.

النتيجة الصحيحة هي أن الحافة الموثوقة تستبدل أو تلحق بأمان المدخلات غير الموثوقة ويختار الخادم الخلفي العنوان بناءً على عدد القفزات الموثوقة الموثقة. يجب ألا يصبح العنوان المزور القيمة المستخدمة للمصادقة أو القوائم البيضاء.

كرر اختبار الاتصال المباشر بالخادم الخلفي من جزء LAN إذا كان المنفذ متاحًا. يجب أن يتجاهل الخادم الخلفي رؤوس التوجيه من عميل مباشر غير موثوق ويسجل عنوان النظير الفعلي للمقبس.

تحقق من صحة IPv4 وIPv6 ومسارات الوكلاء المتعددين

كرر الاختبار عبر IPv4 وIPv6، عبر اسم المضيف العام العادي، وعبر أي CDN أو نفق أو وكيل ثانوي مستخدم في الإنتاج. تأكد من أن السجلات تحافظ على تنسيقات العناوين الصحيحة ولا تقطع السلسلة.

يوفر دليل ZimaSpace لـ هوية طلب الوكيل العكسي السياق المحيط لأهمية القيم الممررة الصحيحة بما يتجاوز التسجيل.

يتم التحقق من الوكيل فقط عندما يتطابق المصدر المعروف مع عنوان IP العميل المحلل، وتظل الوكلاء الموثوقون مرئيين في السلسلة الخام، تفشل محاولات التزوير، وتستخدم ضوابط الأمان القيمة الموحدة باستمرار. أعد التحقق بعد إضافة CDN أو نفق أو قفزة وكيل أخرى.