Tor کے SOCKS پورٹ سے UDP: کیا نہیں گزرتا

ایپ کو SOCKS پورٹ کی طرف اشارہ کرنا براؤزر کے لیے کام کرتا ہے اور گیم کے لیے ناکام ہوتا ہے، اور وجہ کنفیگریشن نہیں ہے۔ SOCKS5 کئی کمانڈز متعین کرتا ہے، اور عمل درآمد آزاد ہے کہ ان میں سے صرف چند کو سپورٹ کرے، Tor کا انٹرفیس اسٹریم کنکشنز اور ناموں کا حل قبول کرتا ہے، من مانی ڈیٹاگرام فارورڈنگ نہیں۔ جو کلائنٹ UDP بھیجتا ہے اور توقع کرتا ہے کہ پراکسی اسے آگے بھیجے گا، وہ ایسی کمانڈ مانگتا ہے جو سرور عمل میں نہیں لاتا۔ نیچے دی گئی گائیڈ اسے چند منٹوں میں جانچتی ہے اور پھر ایسا ٹرانسپورٹ منتخب کرتی ہے جو واقعی کام کر سکے۔

دیکھیں کہ ایپ واقعی کیا بھیجتی ہے

پروٹوکول کے نام کے بجائے ٹرانسپورٹ کی شناخت سے شروع کریں۔ وائس کلائنٹ HTTPS سے سائن ان کر کے پھر میڈیا UDP سے لے جا سکتا ہے؛ گیم TCP سے توثیق کر کے UDP سے کھیل سکتی ہے؛ فائل ٹرانسفر کنٹرول کے لیے TCP اور دریافت کے لیے UDP استعمال کر سکتا ہے۔ پہلے دو رویے تب تک یکساں دکھتے ہیں جب تک لاگ ان کامیاب نہ ہو اور کال اب بھی ناکام رہے، اسی لیے ”منسلک ہو گیا“ اس بات کا ثبوت نہیں کہ پوری ایپ کام کرتی ہے۔ کچھ کلائنٹ خود ہی UDP سے TCP پر واپس جاتے ہیں، جس سے جزوی طور پر کام کرنے والا سیشن بلاک شدہ ٹرانسپورٹ کی بجائے غیر مستحکم نیٹ ورک جیسا دکھتا ہے۔

جو حصہ ناکام ہوتا ہے اس کے لیے منزل کا پورٹ اور ٹرانسپورٹ لکھیں۔ وہی ایک سطر طے کرتی ہے کہ پراکسی بالکل مدد کر سکتی ہے یا نہیں۔

Tor کا SOCKS انٹرفیس کیا قبول کرے گا

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 عام طور پر زیادہ موزوں ہے: یہ ایپ سے پراکسی پروٹوکول بولنے کو کہے بغیر اس کے پیکٹ لے جاتا ہے، البتہ بالکل مختلف گمنامی کی خصوصیات کی قیمت پر۔ ہر اوزار کو اسی کام کے لیے استعمال کریں جس کی وہ دستاویز کرتا ہے، اور ان کے درمیان کسی بھی پل کو الگ نظام سمجھیں جس کا اپنا جائزہ درکار ہے۔ حتمی رپورٹ میں لکھیں کہ کون سی تہہ کون سا ٹرانسپورٹ لے جاتی ہے، تاکہ اگلا شخص کسی دوسری ایپ کے ساتھ وہی حد دوبارہ دریافت نہ کرے۔