تعمق في فهم ما هو Forward Proxy
January 12, 2024
نستخدم عادةً NGINX أو Apache كموازنات تحميل وخوادم وكيل عكسي، حتى عندما يتم توجيه حركة المرور الخارجية عبر هذا البرنامج للوصول إلى الخدمات الفعلية داخل الشبكة الداخلية. بينما يوجد وكيل عكسي، يوجد أيضًا وكيل توجيهي. دعونا نتعمق في وظائفهما.
من نموذج OSI إلى خوادم الوكيل
عند الوصول إلى خدمات الإنترنت، نستخدم عادةً بروتوكول HTTP، الذي يعمل في الطبقة السابعة من نموذج OSI. المكونات المألوفة لهذا البروتوكول، مثل أسماء المضيفين والمسارات ومعلمات الاستعلام، هي أجزاء من هذه الطبقة. يعتمد بروتوكول HTTP على بروتوكولات TCP أو UDP، التي تعمل في الطبقة الرابعة من نموذج OSI، وتوجد مفاهيم المنافذ المستخدمة أثناء الوصول إلى الخدمات ضمن هذه البروتوكولات. بالانتقال إلى أبعد من ذلك، يعتمد كل من TCP وUDP على بروتوكول الإنترنت (IP)، الذي يعمل في الطبقة الثالثة من نموذج OSI، حيث تعمل عناوين IP كـ "أرقام منازل" الإنترنت.
عند استخدام شبكة IP للوصول إلى الإنترنت، يكون بروتوكول IP مسؤولًا عن توجيه الهدف، وتغليف حزم البيانات وفقًا للقواعد، وإعادة توجيهها من عنوان المصدر إلى عنوان الوجهة داخل شبكة IP. على سبيل المثال، تنتقل حركة المرور من شبكة الزائر المحلية عبر جهاز البوابة المقدم من مزود خدمة الإنترنت (ISP)، للاتصال بشبكة ISP قبل الوصول إلى خدمات موفر الموارد.
في هذه المرحلة، نستخدم بوابة للوصول إلى الإنترنت. عند مناقشة خوادم الوكيل، يمكننا رسم تشابه مع شبكة IP. تعمل خوادم الوكيل كبوابات، تعمل كجسر لمساعدة العملاء في الوصول إلى الخدمات. تعمل بشكل أساسي بين الطبقة الرابعة والطبقة السابعة من نموذج OSI، وتقع في الواقع في الطبقة الخامسة من نموذج OSI.
أغراض خوادم الوكيل
تُستخدم خوادم الوكيل عادةً للأغراض التالية:
- مخرج مركزي للوصول إلى الشبكة الداخلية
غالبًا ما يكون لدى الشركات متطلبات معينة لأمن المعلومات، مثل التحكم في الوصول وتسجيل حركة المرور. مع انتشار حركة المرور المشفرة مثل HTTPS، يصبح إخفاء حركة المرور تحت كلمات المرور أمرًا صعبًا لتسجيله ومراجعته عند حدود الشبكة، مما يزيد من خطر التسريبات. وجود خادم وكيل يعمل كمخرج موحد لحركة المرور، كوسيط للتعامل مع مهام مراجعة حركة المرور.
بالإضافة إلى الأغراض الموجهة للإنسان، يمكن أن تكون خدمات الوكيل مخرجًا للخدمات البرمجية للوصول إلى الشبكة الخارجية. على سبيل المثال، عندما يقدم موفر الخدمة وظيفة webhook، يحتاج إلى توجيه حركة المرور عبر مخرج ثابت، باستخدام عنوان IP ثابت واحد أو نطاق من عناوين IP الثابتة. هذا يسهل على مستقبل استدعاءات webhook إدراجها بشكل صحيح في القائمة البيضاء في الجدار الناري. عدم القيام بذلك يعرض كلا طرفي استدعاءات webhook لخطر أمني محتمل.
- إخفاء هوية الزائر
في بعض الأحيان، قد يرغب مستخدمو الإنترنت في إخفاء هويتهم، مثل عنوان IP الخاص بهم. في هذه الحالات، تأتي خوادم الوكيل الشفافة إلى الصورة. يتصل العميل أولاً بخادم الوكيل، مع تحديد عنوان الخدمة الحقيقية للاتصال بها، ثم يصل إلى الخدمة الهدف عبر خادم الوكيل باستخدام بروتوكول HTTPS. وجود خادم الوكيل يضمن إخفاء هوية العميل، بينما يضمن استخدام بروتوكول مشفر أن خادم الوكيل لا يمكنه سرقة البيانات خلال هذه العملية.
وكيل HTTP
على خوادم الوكيل، نواجه عادةً وكيل HTTP القائم على HTTP وبروتوكول SOCKS 4/5 القائم على الثنائي. يؤدون وظائف مماثلة ولكن بطرق تنفيذ مختلفة. دعونا نركز على وكلاء HTTP القائم على HTTP.
في المراحل الأولى من تنفيذ البروتوكول، كانت حركة المرور على HTTP بشكل أساسي نصًا عاديًا. هذا الشفافية سمحت لخوادم الوكيل في منتصف العميل والخدمة بتحليل عناوين URL وحمولات الطلبات بسهولة. من خلال تحليل DNS وعمليات مماثلة، يمكن للوكيل الاتصال بالخدمة باستخدام عنوان شبكته الخاص، وبالتالي إخفاء العميل.
مثال على مثل هذا الاستدعاء هو كما يلي:
GET http://example.com/resource HTTP/1.1
Proxy-Authorization: Basic encoded-credentials
يفهم خادم الوكيل العنوان الذي يحاول العميل الوصول إليه ويرسل طلبًا إلى الخدمة للحصول على استجابة، والتي يتم إرجاعها بعد ذلك إلى العميل.
HTTP/1.1 200 OK
Content-Type: text/html
...
body blahblah
...
يمثل هذا أبسط أشكال تنفيذ خادم وكيل HTTP. ومع ذلك، نلاحظ عيوبًا: خادم الوكيل يتعامل مع حركة مرور العميل كنص عادي، مما يشكل خطرًا أمنيًا محتملًا حيث قد يسجل حركة مرور المستخدم أثناء إعادة التوجيه. لذلك، من الضروري النظر في طرق التشفير لضمان الأمان.
عمل حركة HTTPS المعقدة وخوادم الوكيل
مع زيادة نسبة حركة المرور المشفرة HTTPS ضمن جميع حركة مرور HTTP، يجب على خوادم الوكيل التكيف مع هذا السيناريو.
ومع ذلك، يظهر تحدي: حركة المرور التي يرسلها العميل إلى موفر الخدمة أصبحت الآن مشفرة. لا يمكن لخادم الوكيل فهم المورد الذي يحاول العميل الوصول إليه من خلال فك التشفير. هذا لأن حركة المرور محمية بآلية تفاوض على المفاتيح تعتمد على خوارزميات التشفير غير المتماثلة بين العميل وموفر الخدمة، وتستخدم حركة المرور المشفرة اللاحقة مفاتيح متماثلة لا يمكن الحصول عليها من قبل رجل في الوسط أثناء الاتصال. الغرض الأساسي من TLS هو منع إمكانية هجمات رجل في الوسط.
إذن، كيف يعمل خادم الوكيل في هذه الحالة؟
هذا أكثر تعقيدًا مقارنة بالطريقة السابقة لتحليل طلبات النص العادي. قدم بروتوكول HTTP طريقة طلب مخصصة تسمى CONNECT. يستخدم العميل هذه الطريقة لإرسال طلب أولي إلى خادم الوكيل:
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: Basic encoded-credentials
يرسل العميل طلب CONNECT إلى خادم الوكيل، بما في ذلك النطاق أو عنوان IP والمنفذ الذي يرغب العميل في الاتصال به. عند استلام الطلب، يقوم خادم الوكيل بإنشاء اتصال TCP مع الخدمة الهدف ويخزن تعيين المنفذ بين العميل والخدمة. بعد ذلك، يمكن للعميل إرسال الطلب الصحيح إلى خادم الوكيل، الذي سيقوم بإعادة توجيه حركة المرور إلى الخدمة كما هي، دون محاولة تحليل البيانات. وبالتالي، فإن الاتصال المشفر لـ HTTPS موثوق به.
هذه الآلية، مقارنة بوكلاء HTTP النص العادي، أكثر تنوعًا. بمجرد أن يخبر الطلب HTTP الأول خادم الوكيل بالمعلومات اللازمة لإنشاء اتصال، يصبح بشكل أساسي قناة وكيل شفافة. يمكنه تسهيل الاتصال لكل من حركة HTTPS وحركة TCP الثنائية (مثل SSH) عبر خادم الوكيل.