ما هو عكس البروكسي وكيف يعمل؟

تعد البروكسيات العكسية أداة مفيدة في أي مجموعة أدوات لمسؤول النظام. لديهم الكثير من الاستخدامات ، بما في ذلك موازنة الحمل والحماية من هجمات DDOS

ما هي وكلاء عكس؟

الوكيل العادي ، المسمى بـ Forward Proxy ، هو خادم يتم من خلاله توجيه اتصال المستخدم. من نواح كثيرة ، يشبه VPN بسيطًا ، يقع أمام اتصال الإنترنت الخاص بك. تعد شبكات VPN مثالًا شائعًا على ذلك ، ولكنها تتضمن أيضًا أشياء مثل جدران الحماية المدرسية ، والتي قد تمنع الوصول إلى محتوى معين.

يعمل الوكيل العكسي بشكل مختلف قليلاً. إنها أداة خلفية يستخدمها مسؤولو النظام. بدلاً من الاتصال مباشرة بموقع ويب يقدم المحتوى ، يمكن لبروكسي عكسي مثل NGINX الجلوس في المنتصف. عندما يتلقى طلبًا من مستخدم ، فإنه سيرسل إعادة توجيه ، أو "وكيل" ، هذا الطلب إلى الخادم النهائي. يُطلق على هذا الخادم اسم "الخادم الأصلي" لأنه ما سيستجيب بالفعل للطلبات.

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

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

ما هي استخدام الوكلاء العكسيين؟

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

توزيع الحمل

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

ذات صلة كيفية إعداد موازن تحميل HAProxy

هذا يعني أن عنق الزجاجة غالبًا ما يكون الخادم الأصلي ، ولكن مع وجود وكيل عكسي أمامه ، يمكنك بسهولة الحصول على خوادم أصل متعددة. على سبيل المثال ، يمكن أن يرسل الوكيل 50٪ من الطلبات إلى خادم واحد ، و 50٪ إلى خادم آخر ، مما يضاعف سعة موقع الويب. تم تصميم خدمات مثل HAProxy للتعامل مع هذا الأمر بشكل جيد.

هذه حالة استخدام شائعة جدًا ، وسيقدم معظم موفري الخدمات السحابية مثل Amazon Web Services (AWS) موازنة الحمل كخدمة ، مما يوفر عليك عناء إعدادها بنفسك. باستخدام أتمتة السحابة ، يمكنك تلقائيًا زيادة عدد الخوادم الأصلية استجابةً لحركة المرور ، وهي ميزة تسمى "التحجيم التلقائي".

يمكن إعداد موازنات التحميل مثل Elastic Load Balancer من AWS لإعادة تكوين نفسها تلقائيًا عندما ترتفع الخوادم الأصلية وتنخفض ، وكل ذلك أصبح ممكنًا بواسطة وكيل عكسي تحت الغطاء.

ذات صلة: كيفية البدء باستخدام موازن التحميل المرنة من AWS

التخزين المؤقت

نظرًا لأن الوكيل العكسي غالبًا ما يكون أسرع في الاستجابة من الخادم الأصلي ، يتم استخدام تقنية تسمى التخزين المؤقت بشكل شائع لتسريع الطلبات على المسارات الشائعة. التخزين المؤقت هو عندما يتم تخزين بيانات الصفحة على الوكيل العكسي ، ويتم طلبها فقط من الخادم الأصلي مرة واحدة كل بضع ثوان / دقائق. هذا يقلل من الضغط على الخادم الأصلي بشكل كبير.

على سبيل المثال ، تم تقديم هذه المقالة التي تقرأها الآن بواسطة WordPress ، والتي تحتاج إلى التحدث إلى قاعدة بيانات SQL لجلب محتوى المقالة والبيانات الوصفية. يعد القيام بذلك مع كل تحديث للصفحة إهدارًا نظرًا لأن الصفحة لا تتغير حقًا. لذلك ، يمكن تخزين هذا المسار مؤقتًا ، وسيرسل الوكيل العكسي الرد الأخير إلى المستخدم التالي ، بدلاً من إزعاج WordPress مرة أخرى.

تسمى الشبكة المخصصة من البروكسيات العكسية التي تخزن المحتوى الخاص بك بشبكة توصيل المحتوى ، أو CDN. يتم استخدام شبكات CDN مثل CloudFlare أو Fastly بشكل شائع من قبل مواقع الويب الكبيرة لتسريع التسليم العالمي. تسمى الخوادم حول العالم التي تخزن المحتوى مؤقتًا "عقد الحافة" ، ويمكن أن يؤدي وجود الكثير منها إلى جعل موقع الويب الخاص بك سريعًا للغاية.

حماية الشبكة والخصوصية

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

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

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

الواجهة الأمامية شكلي

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

على سبيل المثال ، NGINX قادرة على تصنيف طلبات الحد إلى مسارات معينة ، والتي يمكن أن تمنع المسيئين من إرسال آلاف الطلبات إلى الخوادم الأصلية من IP واحد. هذا لا يوقف هجمات DDOS ، ولكن من الجيد أن يحدث ذلك.

NGINX قادرة أيضًا على إعادة توجيه حركة المرور من أسماء نطاقات متعددة مع كتل "خادم" قابلة للتكوين. على سبيل المثال ، يمكن أن ترسل طلبات إلى example.com إلى خادمك الأصلي ، ولكن ترسل api.example.com إلى خادم واجهة برمجة التطبيقات الخاص بك ، أو files.example.com إلى مساحة تخزين الملفات الخاصة بك ، وما إلى ذلك. يمكن أن يكون لكل خادم تكوين وقواعد خاصة به.

NGINX قادر أيضًا على إضافة ميزات إضافية أعلى الخوادم الأصلية الحالية ، مثل شهادات HTTPS المركزية وتكوين الرأس.

في بعض الأحيان ، يكون من المفيد أن يكون لديك NGINX على نفس الجهاز مثل خدمة محلية أخرى ، لمجرد تقديم المحتوى من تلك الخدمة. على سبيل المثال ، تستخدم واجهات برمجة تطبيقات الويب ASP.NET خادم ويب داخليًا يسمى Kestrel ، وهو جيد في الاستجابة للطلبات ، ولكن ليس أكثر من ذلك. من الشائع جدًا تشغيل Kestrel على منفذ خاص واستخدام NGINX كوكيل عكسي قابل للتكوين.

التسجيل المركزي

هذه الطريقة بسيطة جدًا ، ولكن وجود معظم حركة المرور الخاصة بك يمر عبر خدمة واحدة يجعل من السهل التحقق من السجلات. يحتوي سجل الوصول الخاص بـ NGINX على الكثير من المعلومات المفيدة حول حركة المرور الخاصة بك ، وعلى الرغم من أنه لا يتفوق على ميزات خدمة مثل Google Analytics ، إلا أنه من المعلومات الرائعة الحصول عليها.

ذات صلة: كيفية إعداد تحليلات Elasticsearch ولوحة المراقبة لعملك