Privoxy: ربط عميل بروكسي HTTP بنفق SOCKS

يوفر نفق SSH الديناميكي، بما في ذلك إعادة التوجيه الديناميكي في PuTTY، واجهة SOCKS. والتطبيق الذي لا يقبل إلا بروكسي HTTP لا يمكنه استخدام ذلك المنفذ بمجرد تسميته HTTP.

يمكن أن يجلس جسر بروتوكول محلي بينهما: يرسل التطبيق طلبات بروكسي HTTP إلى الجسر، ويفتح الجسر اتصالات الوجهة عبر خدمة SOCKS.

يوثّق Privoxy هذا الترتيب عبر قواعد إعادة التوجيه لديه. ولنفق SOCKS5 محلي قائم، يكون جزء الإعداد:

forward-socks5 / 127.0.0.1:1080 .

يتصل التطبيق بمستمع HTTP الخاص بـ Privoxy، لا بالمنفذ 1080. أبقِ ذلك المستمع محليًا وفق سياسة الوصول المقصودة. وللنقطة الأخيرة في القاعدة معنى موثّق؛ فهي ليست عنصرًا نائبًا عن اسم مضيف إنترنت مفقود.

هذه ترجمة بروتوكول

توضح وثائق إعادة التوجيه في Privoxy صياغة إعادة توجيه SOCKS والتعامل مع أسماء المضيفين. إعادة توجيه منفذ TCP عادية لا تنفذ الترجمة نفسها: فهي تنقل بايتات HTTP الخاصة بالعميل دون تغيير إلى مستمع SOCKS لا يزال يتوقع تفاوض SOCKS.

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

بالنسبة لمواقع HTTPS، يطلب التطبيق عادةً CONNECT من جسر HTTP، ويحصل الجسر على اتصال الوجهة عبر SOCKS. ويبقى TLS العادي للموقع علاقة بين التطبيق والموقع؛ ولا يحتاج الجسر إلى انتحال شخصية الموقع لتوفير هذا المسار.

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