Tor ریلے اور VPN سرور: یہ ایک دوسرے کے متبادل کیوں نہیں
Tor ریلے پر کھلا پورٹ VPN اختتامی نقطہ نہیں ہے۔ پہلے دیکھیں کہ پورٹ کیا خدمت دیتا ہے، ریلے کا کردار، SOCKS سننے والے کا دائرہ اور پروفائل۔
آپ کے پاس ایک پتہ ہے، پورٹ جواب دیتا ہے، اور کلائنٹ بغیر کسی شکایت کے اسے قبول کرتا ہے۔ ان میں سے کوئی بھی Tor ریلے کو VPN اختتامی نقطہ نہیں بناتا، اور غلطی مہنگی ہے کیونکہ پروفائل صاف طریقے سے درآمد ہوتا ہے اور بعد میں مصافحے میں ناکام ہوتا ہے۔ میں نیچے دیے گئے چار جائزے ترتیب سے استعمال کرتا ہوں؛ ہر ایک کی ایک رکنے کی شرط ہے، اور جلدی رکنا ہی اصل بات ہے۔ اگر پہلا جائزہ ناکام ہو جائے تو باقی آپ کی مدد نہیں کر سکتے۔
دیکھیں کہ پورٹ اصل میں کیا خدمت دیتا ہے
کھلا پورٹ صرف سننے والے کا ثبوت دیتا ہے، اس سے زیادہ کچھ نہیں۔ ریلے کا ORPort TLS مصافحے کے بعد Tor کے اپنے خلیوں سے بات کرتا ہے، اس لیے کامیاب TLS جانچ اس بارے میں تقریباً کچھ نہیں بتاتی کہ وہاں VPN پروٹوکول قبول ہوتا ہے یا نہیں:
nc -vz 203.0.113.20 443
openssl s_client -connect 203.0.113.20:443 -brief < /dev/null
سرٹیفکیٹ کے موجود ہونے کی حقیقت نہیں، سرٹیفکیٹ پڑھیں۔ ریلے جان بوجھ کر غیر نمایاں نام کے ساتھ خود دستخط شدہ سرٹیفکیٹ پیش کرتے ہیں، کیونکہ ریلے کی ٹریفک کو عام HTTPS جیسی نظر آنا چاہیے؛ جبکہ VPN سرور کا سرٹیفکیٹ وہ نام رکھتا ہے جس کی آپ کا پروفائل توقع کرتا ہے۔ اگر سامنے والا فریق VPN پروٹوکول کے پہلے پیکٹ کا کبھی جواب نہ دے، تو پروفائل میں کتنی بھی ترمیم نتیجہ نہیں بدلے گی۔
اگر پتہ آپ کے کلائنٹ کے بھیجے مصافحے کو مکمل نہیں کرتا تو یہیں رکیں۔ یہ پروٹوکول کا جواب ہے، کنفیگریشن کا مسئلہ نہیں، اور درآمد شدہ پروفائل کے ہمیشہ 'connecting' پر رہنے کی سب سے عام وجہ یہی ہے۔
نیٹ ورک کا حجم نہیں، ریلے کا کردار دیکھیں
ریلے کے کردار مختلف کام کرتے ہیں۔ گارڈ کلائنٹس کے لیے پہلا قدم ہے، درمیانی ریلہ دوسرے ریلوں کے درمیان سرکٹ آگے بھیجتا ہے، ایگزٹ وہ ہے جو منزلوں کو چھوتا ہے، اور پل ایک غیر عوامی داخلہ نقطہ ہے جو BridgeDB کے ذریعے تقسیم ہوتا ہے۔ Tor کی اصطلاحات ان تعریفوں کو الگ رکھتی ہیں، اور قابل رسائی ہونا ہر کردار کا حصہ ہے، جبکہ من مانی کلائنٹس کی خدمت کی اجازت کسی کا حصہ نہیں۔
ایگزٹ پالیسی پڑھنے کے قابل ہے کیونکہ یہی واحد حصہ ہے جو آگے بھیجنے کے قاعدے جیسا لگتا ہے، اور یہ ان منزلوں کو کنٹرول کرتی ہے جہاں ایگزٹ باہر جانے کی اجازت دے گا، نہ کہ ان کلائنٹس کو جنہیں اندر آنے دیا جاتا ہے۔ پورٹ 25 کو بلاک کرنے والی سخت ایگزٹ پالیسی باہر جانے والی بدسلوکی کے کنٹرول کے بارے میں کچھ کہتی ہے، اس بارے میں نہیں کہ آپ OpenVPN کلائنٹ کو مشین کی طرف موڑ سکتے ہیں یا نہیں۔
اگر آپ ساکھ سے استدلال کر رہے ہیں تو رکیں: چونکہ ریلے ٹریفک آگے بھیجتے ہیں، پتے کو آپ کی ٹریفک قبول کرنی چاہیے — یہ درست نہیں۔ Tor راستے اتفاق رائے اور اپنے پروٹوکول کے ذریعے چنتا ہے؛ VPN کلائنٹ شریک نہیں ہے اور اس کے پاس شامل ہونے کے لیے کوئی سرکٹ نہیں۔
دیکھیں کہ SOCKS سننے والا مقامی ہے یا عوامی
Tor کا کلائنٹ اسی مشین کی ایپلیکیشنز کے لیے SOCKS انٹرفیس کھولتا ہے، بطور ڈیفالٹ loopback پر۔ وہ سننے والا مقامی سہولت ہے، وہ خدمت نہیں جو ریلہ انٹرنیٹ کو پیش کرتا ہے، اور اسے عوامی پراکسی سمجھنا ہی وہ راستہ ہے جس سے لوگ نادانستہ کھلا ریلہ چلانے لگتے ہیں:
ss -ltnp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org
بائنڈ پتہ ہی اشارہ ہے۔ 127.0.0.1:9050 پر SocksPort اپنا کام کر رہا ہے؛ جو 0.0.0.0 پر سنتا ہے اور باہر سے قابل رسائی ہے وہ کھلی پراکسی ہے، اور Tor کے اپنے رسائی پالیسی کنٹرول اسی لیے موجود ہیں کہ یہ انکشاف خصوصیت نہیں، مسئلہ ہے۔
Tor درکار ایپلیکیشن کے لیے اسے loopback پورٹ کی طرف موڑیں اور نام Tor کو حل کرنے دیں، جو اوپر والی socks5h شکل کرتی ہے۔ اس پورٹ کے لیے ریلے کا پتہ نہ رکھیں؛ ریلہ وہ انٹرفیس پیش نہیں کرتا جو آپ کی ایپلیکیشن مانگتی ہے۔
دیکھیں کہ VPN پروفائل اصل اختتامی نقطے سے مطابقت رکھتا ہے
VPN پروفائل توقعات کا بنڈل ہے: OpenVPN کو سرور سرٹیفکیٹ یا CA، کلائنٹ سرٹیفکیٹ اور کلید، اور عام طور پر TLS کلید درکار ہے، جبکہ WireGuard کو سامنے والے فریق کی عوامی کلید، اختتامی نقطہ اور اجازت شدہ IP درکار ہیں۔ ان میں سے کوئی بھی پتے اور کھلے پورٹ سے اخذ نہیں کیا جا سکتا، اسی لیے اس طرح بنایا گیا پروفائل جڑنے کے وقت نہیں بلکہ پہلے تبادلے میں ناکام ہوتا ہے۔
جب آپ کو پروفائل دیا جائے تو اسے اس اختتامی نقطے کے سامنے جانچیں جسے آپ کنٹرول کرتے ہیں یا اس فراہم کنندہ کے سامنے جسے آپ پہچان سکتے ہیں:
wg show
openvpn --config client.ovpn --verb 4
OpenVPN لاگ میں TLS گفت و شنید کی غلطی عدم مطابقت کو براہ راست نام دیتی ہے؛ wg show میں، مصافحے کی لائن کے بغیر سامنے والے فریق نے کبھی ایک بھی مکمل نہیں کیا۔ دونوں کلائنٹ کے گھومتے اشارے سے زیادہ معلومات دیتے ہیں، اور دونوں Tor کی طرف نہیں بلکہ کلید کے مواد یا پروٹوکول کی طرف اشارہ کرتے ہیں۔
دیکھیں کہ آپ کو واقعی کون سا تحفظ درکار ہے
یہی وہ جائزہ ہے جو ساخت کا فیصلہ کرتا ہے۔ Tor براؤزر آپ کو وہ سرکٹ الگاؤ اور فنگر پرنٹ کے خلاف دفاع دیتا ہے جو VPN نہیں دیتا؛ VPN وہ پتہ بدلتا ہے جو منزل دیکھتی ہے اور آپ کو فراہم کنندہ کے سامنے تصدیق کرتا ہے۔ ان کے درمیان انتخاب خطرے کے ماڈل کا سوال ہے، مطابقت کا نہیں، اور دونوں کو ملانا ایسی ترتیب بناتا ہے جو نجی دکھتی ہے اور ہے نہیں۔
زنجیر کا ایک ترتیب ہے۔ Tor ٹریفک لے جانے والا VPN معاون ترتیب ہے، کیونکہ Tor کے کلائنٹ کو صرف باہر جانے والا TCP درکار ہے۔ Tor کے اندر سرنگ میں ڈالا گیا VPN کلائنٹ وہی چیز نہیں ہے اور وہ نہیں جو Tor کلائنٹ نافذ کرتا ہے، اس لیے اس کی بنیاد پر منصوبہ نہ بنائیں۔
کچھ بھی درآمد کرنے سے پہلے چاروں باتوں کی تصدیق کریں:
- پورٹ آپ کے پروٹوکول کا مصافحہ مکمل کرتا ہے، صرف TCP کنکشن نہیں۔
- آپ ہوسٹ کا کردار جانتے ہیں اور آگے بھیجنے کو اجازت نہیں سمجھتے۔
- آپ جو SOCKS سننے والا استعمال کرتے ہیں وہ loopback اور آپ کا ہے، کسی اور کے ریلے پر عوامی پورٹ نہیں۔
- پروفائل کی کلیدیں یا سرٹیفکیٹ اسی اختتامی نقطے کے ہیں جس سے آپ جڑتے ہیں۔