لا يحتاج الوكيل الأمامي الخاص إلى أن يجلس فعليًا بين الحاسوب المحمول والموجّه. يمكن أن يكون جهازًا آخر على الشبكة المحلية نفسها، مستخدمًا واجهة شبكة واحدة.

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

client → proxy listener
proxy → existing router → destination

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

البوابة الافتراضية تجيب عن سؤال آخر

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

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

هذا التمييز يفسر أيضًا تجربة فاشلة شائعة: تعديل قواعد تمرير خادم وكيل لا يؤثر على اتصال عميل مباشر يمر عبر موجّه آخر. فالحزم لم تعبر ذلك الخادم أبدًا.

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

مقالات ذات صلة