مقبس .NET يحتاج إلى مصافحة SOCKS

توجيه Socket.Connect() إلى خادم SOCKS يفتح اتصال TCP بذلك الخادم. لا تزال البايتات التالية بحاجة إلى التحدث بلغة SOCKS. إرسال بروتوكول تطبيقك فورًا يترك الخادم ينتظر محادثة مختلفة.

مع SOCKS5، يشمل إنشاء الاتصال تفاوض الطريقة، وأي تبادل مصادقة مختار، وطلبًا يسمّي الوجهة. الرد الناجح وحده يفتح المسار لبايتات التطبيق. تُعرَّف هذه المراحل في RFC 1928.

أبقِ التفاوض في طبقة الاتصال

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

التنفيذ المكتوب يدويًا الذي يقرأ مخزنًا واحدًا ثابت الحجم ويفترض النجاح هش. لا يحافظ TCP على حدود رسائل SOCKS. اقرأ الرد الكامل الذي يصفه نوع عنوانه قبل بدء بروتوكول التطبيق. يوضح قارئ رد CONNECT في .NET 7+ تلك الخطوة.

إذا كانت مكتبة مُصانة توفر طبقة الاتصال هذه بالفعل، فتحقق من إصدارات SOCKS المدعومة وطرق المصادقة وإطار العمل الهدف. رابط منتدى عمره عقد هو نقطة انطلاق للتحقيق لا دليل على التوافق الحالي.

لإعداد عميل HTTP نطاق منفصل

إعداد الوكيل في عميل HTTP يضبط ذلك العميل. لا يعدّل كل مقبس خام في العملية. تقبل واجهة Socket نقطة نهاية شبكة وتترك التفاوض الأعلى مستوى للمستدعي.

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