UDP عبر منفذ SOCKS في Tor: ما لا يمر عبره

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

تحقق مما يرسله التطبيق فعلًا

ابدأ بتحديد الناقل لا باسم البروتوكول. قد يسجّل عميل الصوت الدخول عبر HTTPS ثم يحمل الوسائط عبر UDP؛ وقد تتحقق اللعبة عبر TCP وتلعب عبر UDP؛ وقد يستخدم نقل الملفات TCP للتحكم وUDP للاكتشاف. يبدو السلوك الأولان متطابقين حتى ينجح تسجيل الدخول وتبقى المكالمة فاشلة، ولهذا فإن «اتصل» ليس دليلًا على أن التطبيق كله يعمل. بعض العملاء يتراجعون أيضًا من UDP إلى TCP من تلقاء أنفسهم، ما يجعل جلسة تعمل جزئيًا تبدو كشبكة متقطعة لا كناقل محجوب.

دوّن منفذ الوجهة والناقل للجزء الذي يفشل. هذا السطر الواحد يقرر ما إذا كان الوكيل يمكنه المساعدة أصلًا.

ما تقبله واجهة SOCKS في Tor

ينفّذ Tor أمر SOCKS5 CONNECT لاتصالات التدفق وأوامر امتداد لتحليل الأسماء، ولهذا يعمل المتصفح عبره دون تغيير. أما UDP ASSOCIATE، وهو الأمر الذي يتيح للعميل تسليم حزم البيانات إلى الوكيل لتمريرها، فليس جزءًا مما يقدمه Tor. توثيق الامتدادات موجود في مواصفة امتدادات SOCKS الخاصة بالمشروع، وهو قصير. غياب أمر حزم البيانات مقصود: فتمرير UDP الاعتباطي سيمنح الشبكة دور تمرير لم تُصمم له قط.

هذه أيضًا هي الإجابة عن WireGuard، فهو UDP بالتصميم ولا بديل TCP له. لا يوجد مسار مدعوم يوجّه WireGuard إلى منفذ SOCKS، وكل ما يدّعي غير ذلك هو غلاف له حكايته الخاصة في الثقة والصيانة، لا ميزة في أي من الأداتين.

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

نفّذ الفحص بالترتيب

أكّد أولًا أن الوكيل يعمل مع التدفقات، حتى لا يُلقى اللوم في فشل لاحق على منفذ غير قابل للوصول. ثم أكّد حركة التطبيق نفسه، ولاحظ أي المقابس يفتحها فعلًا.

curl --socks5-hostname 127.0.0.1:9050 -sS https://check.torproject.org/api/ip
ss -tupn | grep 9050
ss -aun | grep -E ':(3478|5060|27015)\b'

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

تراجع واختر الأداة الصحيحة

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

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