ربط عملاء SOCKS بأصل HTTP CONNECT باستخدام 3proxy

يحتاج التطبيق إلى SOCKS. خدمة المنبع المعتمدة لديك تقبل HTTP CONNECT. ووضع نقطة نهاية HTTP في حقل SOCKS في التطبيق لا يترجم بين البروتوكولين.

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

SOCKS application → SOCKS-facing gateway → HTTP CONNECT parent → destination

اجعل كل واجهة صريحة

بالنسبة إلى بوابة تدعم هذا الترتيب، يهم نوع الأصل الخاص بها. فتوثيق 3proxy يميز بين أصل connect وأصل يُستخدم كخادم وكيل HTTP عادي لإعادة التوجيه.

مع وجود مستخدم 3proxy وإعداد مصادقة قائمين، يمكن لمقطع توجيه محلي فقط أن يتخذ هذا الشكل:

auth strong
allow alex
parent 1000 connect parent.example.net 8080
socks -i127.0.0.1 -p1080

يفترض هذا المقطع أن الحساب محدد مسبقًا. وهو لا يضيف أي بيانات اعتماد يحتاجها أصل HTTP نفسه، ولا يستبدل سياسة الوصول القائمة. وللوجهات العامة على مسار يسمح بأصل HTTP عام غير موثق، تقدم قائمة وكلاء HTTP مرشحي المضيف والمنفذ. أبقِ بيانات اعتماد الأصل غائبة في ذلك الفرع وتأكد من الإذن للهدف الفعلي؛ ويبقى حساب البوابة نفسها محليًا. وتُربط قاعدة parent بقاعدة السماح السابقة وفق نموذج التكوين الموثق في 3proxy.

يستخدم التطبيق نقطة نهاية SOCKS المحلية. وتستخدم البوابة HTTP CONNECT نحو الأصل. ولا يزال الأصل هو من يقرر ما إذا كان مضيف الوجهة المطلوب ومنفذه مسموحين.

النطاق المفيد هنا هو أنفاق تدفق TCP العادية. ولا يصبح اقتران UDP في SOCKS5 مدعومًا لمجرد أن المستمع الأمامي يقبل SOCKS5. وأصل HTTP CONNECT لا يوفر تلقائيًا مرحل UDP المطلوب.

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