الوجهات الأصلية في إعادة التوجيه الشفاف من TCP إلى SOCKS

يمكن لجدار ناري أن يغيّر المكان الذي ينتهي إليه اتصال TCP. لكنه لا يستطيع، بهذا التغيير وحده، أن يعلّم التطبيق المنشئ كيف يتحدث SOCKS.

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

المكوّن المفقود هو مترجم

يوضع مكوّن شفاف يحوّل TCP إلى الوكيل بين هاتين الواجهتين. يكتشف الوجهة التي طلبها التطبيق أصلًا، وينشئ جلسة SOCKS أو HTTP CONNECT المناسبة، ثم ينقل بيانات التطبيق عبر التدفق الناتج.

على مسار Linux iptables، يسترجع مصدر redsocks الوجهة المحفوظة باستخدام SO_ORIGINAL_DST. أما أنظمة التشغيل الأخرى وطرق إعادة التوجيه الأخرى فتستخدم آليات مختلفة. هذه خاصية بإعادة الموجّه وإعداد الشبكة، وليست ميزة في عميل SOCKS عادي.

تشرح معلومات الوجهة الأصلية أيضًا لماذا لا يكون نقل قاعدة إعادة توجيه من مضيف الوكيل إلى بوابة غير مرتبطة مكافئًا دائمًا. تحتاج العملية المستقبِلة إلى البيانات الوصفية التي يتطلبها نمط الاعتراض لديها. وقد لا يوفّر عنوان أعيد كتابته في مكان آخر تلك المعلومات بالصيغة المتوقعة.

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

حين يفشل إعداد فور الاتصال، افحص حدود البروتوكول قبل توسيع قواعد الوصول. فقد يرفض مستمع SOCKS يمكن الوصول إليه تمامًا بايتات لم تكن قط طلب SOCKS.