وكيل SOCKS قد يحمّل الرسائل لكنه يفشل في المكالمات

تصل الرسائل النصية عبر وكيل SOCKS، لكن مكالمة صوتية لا تتصل أبدًا. ليس بالضرورة أن يكون الوكيل معطلًا تمامًا. قد يستخدم التطبيق نقلًا مختلفًا للمكالمات.

طلب TCP ناجح يثبت وجود مسار TCP لتلك العملية. يحدد SOCKS5 أيضًا ارتباط UDP، لكن العميل وخدمة SOCKS وقواعد الشبكة وإعدادات التطبيق يجب أن تدعم جميعها مسار UDP المقصود.

هناك أكثر من مستمع TCP

يفصل دليل Dante بين قواعد البروتوكول وقواعد الأوامر، بما في ذلك connect وudpassociate وudpreply. القاعدة التي تسمح فقط باتصال TCP الذي اختبرته بالفعل لا تثبت أذونات UDP المطلوبة.

يتضمن ارتباط UDP أيضًا نقطة نهاية ترحيل وحركة مرتجعة. يجب أن تسمح جدران الحماية وترجمة العناوين بذلك المسار الفعلي. فتح مستمع TCP الخاص بـSOCKS لا يكافئ جعل مرحّل UDP الخاص به قابلًا للوصول.

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

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

وثّق النجاح لكل عملية: الرسائل ونقل الوسائط والمكالمات. لا يمكن لطلب واحد ناجح أو عنوان IP متغير للمتصفح أن يثبت أن كل جزء من تطبيق آخر يشترك في نفس مخرج الوكيل.