VPN سے پہلے Tor تیار: اسٹارٹ اپ گیٹ کو صحیح ترتیب دیں

tor کے عمل کی نگرانی کر کے پھر VPN شروع کرنا اس اسٹیک کو غلط طریقے سے بنانے کا سب سے عام طریقہ ہے۔ ڈیمون کلائنٹ کی اسٹریم لے جانے کی صلاحیت سے بہت پہلے ظاہر ہوتا ہے، اور مقررہ انتظار انحصار کا لباس پہنے ایک اندازہ ہے۔ گیٹ وہی حالت ہونی چاہیے جس کی اگلے جزو کو واقعی ضرورت ہو۔ نیچے دیے گئے چار مراحل ترتیب سے مکمل کریں اور ہر ایک کو ایڈجسٹ کرنے والی تاخیر نہیں بلکہ الگ شرط سمجھیں۔

مرحلہ 1: وہ ٹرانسپورٹ منتخب کریں جو آپ کے پاس واقعی موجود ہے

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

پھر تصدیق کریں کہ آپ کا کلائنٹ کسی SOCKS پراکسی تک پہنچ ہی سکتا ہے۔ OpenVPN 2.6 TCP پروفائلز کے لیے socks-proxy آپشن کی دستاویز کرتا ہے، اور مختلف کلائنٹ مختلف پراکسی معاونت پیش کرتے ہیں۔ جو لانچر پراکسی آپشن کو خاموشی سے نظر انداز کرتا ہے وہ براہ راست جڑ جائے گا اور کام کرتا دکھائی دے گا، جو ناکامی سے بھی بدتر ہے۔

منتخب ٹرانسپورٹ رن بک میں لکھیں، کیونکہ ہر بعد کی جانچ اسی پر منحصر ہے۔

مرحلہ 2: عمل کی فہرست نہیں، bootstrap مرحلہ پڑھیں

Tor کا کنٹرول پروٹوکول GETINFO status/bootstrap-phase کا جواب تازہ ترین bootstrap حالت کے ساتھ دیتا ہے، جس میں پیش رفت کا فیصد اور خلاصہ ٹیگ شامل ہوتا ہے۔ وہ جواب اسی لیے مفید ہے کہ کنٹرولر ڈیمون کے bootstrap مکمل کرنے کے بعد بھی جڑ سکتا ہے۔ جو سپر وائزر صرف واقعات سنتا ہے وہ اس صورت سے محروم رہے گا جہاں سپر وائزر کے شروع ہونے سے پہلے ہی Tor تیار تھا۔

کنٹرول کنکشن کی صحیح تصدیق کریں۔ کنٹرول پورٹ ایک انتظامی انٹرفیس ہے، اور جو بھی اس سے بات کر سکتا ہے وہ ڈیمون کو دوبارہ ترتیب دے سکتا ہے۔ اسے localhost پر رکھیں، کوکی یا پاس ورڈ کی تصدیق فعال رکھیں، اور اسٹارٹ اپ اسکرپٹ آسان بنانے کے لیے دونوں میں سے کوئی بھی نہ ہٹائیں۔

شروع میں مرحلہ ایک بار پڑھیں، پھر براہ راست منظر کے لیے پیش رفت واقعات کی رکنیت لیں۔

printf 'AUTHENTICATE\r\nGETINFO status/bootstrap-phase\r\nQUIT\r\n' | nc 127.0.0.1 9051
ss -ltn | grep -E '9050|9051'
tor --verify-config -f /etc/tor/torrc

پیش رفت 100 اور done ٹیگ والا جواب یعنی ڈیمون نے اپنا آغاز مکمل کر لیا ہے۔ ابھی اس کا مطلب یہ نہیں کہ آپ کے منزل تک کوئی قابل استعمال سرکٹ موجود ہے۔

مرحلہ 3: کلائنٹ سرکٹ واقعے کا انتظار کریں

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

واقعے کو کوشش کی اجازت سمجھیں، کسی مخصوص منزل کے بارے میں ضمانت نہیں۔ ایگزٹ پالیسی اب بھی دور دراز ساتھی کو مسترد کر سکتی ہے، اور VPN کا اپنا ہاتھ ملانا بھی Tor سے بالکل غیر متعلق وجوہات کی بنا پر ناکام ہو سکتا ہے۔

کوڈ میں دونوں شرطیں الگ رکھیں۔ ready نام کا ایک ہی بولین انہیں ملا کر اگلے واقعے کو ناقابل مطالعہ بنا دے گا۔

مرحلہ 4: VPN کو اس کے اپنے ہاتھ ملانے پر گیٹ کریں

VPN کی اپنی تیاری کی شرط ہے، اور سرنگ کے اٹھنے کا ثبوت صرف وہی ہے۔ انتظار کریں کہ کلائنٹ مختص شدہ پتے کے ساتھ منسلک حالت کی اطلاع دے، پھر جانچیں کہ پراکسی کی شرط نافذ رہی۔ جو دوبارہ کوشش کا لوپ ایک ناکامی کے بعد socks-proxy آپشن چھوڑ دیتا ہے وہ براہ راست جڑ جائے گا اور پورے ڈیزائن کو خاموشی سے ہرا دے گا۔

ساتھی کے ناقابل رسائی ہونے پر کیا ہوگا، یہ جاننے کی ضرورت سے پہلے طے کریں۔ نظر آنے والی ناکامی کے ساتھ محدود دوبارہ کوشش لامحدود لوپ سے چلانا آسان ہے، اور نگرانی کے نظام کو انتباہ کے لیے کچھ دیتی ہے۔ یہی فیصلہ کیرئیر پر بھی لاگو ہے: اگر Tor دوبارہ شروع ہو تو VPN کو توڑ کر دوبارہ گیٹ کرنا ہوگا، مردہ سرکٹ پر چلتا نہ چھوڑیں۔

آخر میں، VPN بند ہونے کے دوران ایپلیکیشن کی اپنی پالیسی نافذ رکھیں۔ صحیح انتظار کرنے والا سپر وائزر غیر متعلق عمل کو براہ راست ٹریفک بھیجنے سے روکنے کے لیے کچھ نہیں کرتا۔

ان چار منتقلیوں کی جانچ کریں جن سے آپ کو گزرنا ہے

چار صورتیں ڈیزائن کا احاطہ کرتی ہیں: ٹھنڈا آغاز جس میں Tor پہلے اٹھتا ہے، پہلے سے تیار Tor سے جڑنے والا سپر وائزر، دستیاب نہ ہونے والا VPN ساتھی، اور سرنگ کے اوپر ہونے کے دوران کیرئیر کا ضیاع۔ ہر ایک کی متوقع منتقلی مختلف ہے، اور گیٹ صحیح لکھا ہو تو ہر ایک الگ لاگ سطر پیدا کرتی ہے۔

انہیں جان بوجھ کر، ایک وقت میں ایک چلائیں، اور عمل کی فہرست کے بجائے حالت کی تبدیلیاں پڑھیں۔

journalctl -u tor@default -n 30 --no-pager
systemctl status [email protected]
curl -sS --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip

جب کیرئیر گرتا ہے، VPN کو پرانی سرنگ کے ساتھ لٹکنے کے بجائے ایک دوبارہ کوشش کے وقفے میں اس کے ساتھ نیچے آنا چاہیے۔ جب Tor واپس آتا ہے، گیٹ کو عمل شروع ہونے کے بعد نہیں، سرکٹ واقعے کے بعد ہی دوبارہ کھلنا چاہیے۔ ریکارڈ کریں کہ ہر ناکامی میں کون سی شرط غائب تھی، اور اگلی ڈیوٹی والے شخص کو ٹائم اسٹیمپ سے ترتیب دوبارہ بنانے کی ضرورت نہیں ہوگی۔