Android OpenVPN: فون کو روٹ کیے بغیر نجی راستہ شامل کرنا
Android واقعی جو پروفائل لوڈ کرتا ہے اُس میں ایک راستہ شامل کریں، پھر جانچیں کہ سرور اُسے اجازت دیتا ہے یا نہیں۔ ترمیم، دوبارہ اتصال اور چار جانچوں کے لیے رہنما۔
آپ کو ایک اور نجی ذیلی نیٹ ورک درکار ہے — فرض کریں 10.60.0.0/24 — جو پروفائل میں ابھی نہیں ہے۔ لیپ ٹاپ پر آپ راستہ شامل کر کے آگے بڑھ جاتے۔ Android میں VPN ایک ایپ ہے، tun ڈیوائس اُسی ایپ کی ہے، اور root کے بغیر ترمیم کے لیے کوئی روٹنگ ٹیبل نہیں۔ راستہ بہرحال ہونا چاہیے، لیکن وہ اُس پروفائل میں جاتا ہے جو کلائنٹ لوڈ کرتا ہے، اور صرف اُس وقت کام کرتا ہے جب دوسرا فریق متفق ہو۔ یہ ہے ترمیم، دوبارہ اتصال، سرور کی جانب اور واپسی۔
ترمیم سے پہلے: راستہ کیا کر سکتا ہے اور کیا نہیں
راستہ ایک سوال کا جواب دیتا ہے: اِس منزل کی ٹریفک کون سا انٹرفیس لے جائے گا۔ یہ کسی چیز کی اجازت نہیں دیتا۔ اگر نیٹ ورک کے مالک نے اتفاق نہیں کیا کہ یہ فون اُس ذیلی نیٹ ورک تک پہنچ سکتا ہے، تو درست راستہ درست دکھنے والی کنفیگ اور گیٹ وے پر خاموش ڈراپ پیدا کرتا ہے، اور اگلا گھنٹہ آپ غلط فائل کی ترمیم میں گزار دیں گے۔
پہلے وہ اتفاق حاصل کریں، نیٹ ورک کا مالک ہو تو تحریری طور پر۔ پھر نوٹ کریں کہ آپ کیا نہیں کر رہے: آپ فون کو اُس LAN کے اندر پتہ نہیں دے رہے، سرور کا سننے والا نہیں بدل رہے، اور ہوسٹ نام سے سائٹ نہیں چن رہے۔ یہ چار مختلف تبدیلیاں ہیں اور صرف پہلی آپ کی ہے۔
| The route gives you | The route does not give you |
|---|---|
| A destination prefix associated with the tunnel | Permission to forward at the gateway |
| A path for the phone's own traffic | A return route on the target host |
| A scope for the client's virtual interface | A name in DNS, or HTTPS identity |
وہی پروفائل ترمیم کریں جو کلائنٹ واقعی لوڈ کرتا ہے
عام OpenVPN آپشن متن درآمد کرنے والے موافق کلائنٹ کے لیے، اضافہ ایک سطر ہے:
route 10.60.0.0 255.255.255.0اُسے پروفائل کے بنیادی حصے میں، دوسری روٹنگ ہدایات کے قریب شامل کریں، اور آپریٹر کا endpoint، سرٹیفکیٹ، کلید کی دیکھ بھال اور تصدیقی سطریں بالکل ویسی ہی رکھیں جیسی تھیں۔ ایک سطر ادھار لینے کے لیے پوری پرانی مثال نہ چسپاں کریں: کمپریشن، مطلق فائل راستے اور متروک cipher ترتیبات اُس کے ساتھ آتی ہیں اور الگ ڈیبگنگ اجلاس کا خرچ کروائیں گی۔
لوگ جس مرحلے کو چھوڑ دیتے ہیں وہ فائل کی ملکیت ہے۔ اگر ایپ نے پروفائل درآمد کیا ہے تو جو نقل وہ استعمال کرتی ہے وہ ایپ کی ہے، اور ڈاؤن لوڈ شدہ اصل کی ترمیم کچھ نہیں بدلتی۔ کلائنٹ کا معاونت شدہ ایڈیٹر استعمال کریں، یا ترمیم شدہ فائل کو اپ ڈیٹ راستے سے دوبارہ درآمد کریں، اور جب ایک جیسے نام کئی ہوں تو فعال پروفائل کا نام یقینی بنائیں۔ لکھیں کہ آپ نے کون سی بدلی۔
اگر پروفائل میں پہلے سے route-nopull ہے تو سرور سے کوئی راستہ نصب نہیں ہوتا اور فون کو درکار ہر سابقہ واضح طور پر درج کرنا ہوگا۔ یہ جائز ڈیزائن ہے، لیکن اس کا مطلب ہے کہ چھوڑی گئی سطر سرور کی نامنظوری جیسی ہی دکھتی ہے۔
دوبارہ منسلک ہوں اور ڈیوائس پر جانچیں
پہلے منقطع کریں، پھر ایپ کو پچھلا سیشن بحال کرنے دینے کے بجائے اُسی مخصوص پروفائل سے دوبارہ منسلک ہوں جو آپ نے ترمیم کیا۔ کنکشن لاگ کھولیں اور یقینی بنائیں کہ کلائنٹ نے نئی سطر تجزیہ کی؛ وہ راستہ ہدایت جسے انٹرفیس نظر انداز کرتا ہے غلط نقل کی ترمیم کا عام نتیجہ ہے۔
منزل کو نام سے نہیں، پتے سے جانچیں۔ کسی معروف سروس پورٹ پر TCP جانچ ping سے زیادہ معلومات دیتی ہے، کیونکہ بہت سے میزبان ICMP کا جواب دیتے ہیں جبکہ سروس پورٹ فلٹر ہوتا ہے۔ اگر پتہ جواب دے اور نام نہ دے تو یہ روٹنگ کا نہیں بلکہ ریزالور کا سوال ہے، اور اگلا حصہ آپ کے لیے نہیں۔
یہاں دو دائرہ جانچیں بھی ہیں۔ فی ایپ VPN کا مطلب ہے کہ پتہ راستہ موجود ہو سکتا ہے جبکہ جس ایپ سے آپ جانچ رہے ہیں وہ شامل سیٹ سے باہر ہو، اس لیے اُس ایپ سے جانچیں جو واقعی اندر ہو۔ اور IPv4 سابقہ IPv6 راستے کے بارے میں کچھ نہیں کہتا؛ اگر سروس dual-stack ہے تو متعلقہ IPv6 راستہ شامل کریں یا توقع رکھیں کہ کلائنٹ وہ راستہ ترجیح دے گا جو آپ نے نہیں چاہا تھا۔
ایک منفی نتیجہ جلدی پہچاننا بہتر ہے: اگر full-tunnel راستہ پہلے ہی 0.0.0.0/0 کو ڈھانپتا ہے تو سابقہ غائب نہیں اور دوبارہ شامل کرنے سے کچھ نہیں بدلتا۔ دوہرا احاطہ سرور کی جانب نامنظوری یا غائب جواب کی مرمت نہیں کرتا۔
سرور پر راستہ مکمل کریں
فون سے آگے تین چیزیں درست ہونی چاہئیں۔ گیٹ وے کو منزل تک راستہ اور فون کے ماخذ کو اُس جانب بھیجنے کی اجازت چاہیے۔ ہدف کو وہ ماخذ قبول کرنا اور جوابات گیٹ وے کے ذریعے واپس بھیجنے چاہئیں، ورنہ ڈیزائن کو اخراج پر سوچی سمجھی ترجمہ کاری چاہیے۔ OpenVPN دستی کا route آپشن کلائنٹ کی جانب ہدایت کا احاطہ کرتا ہے؛ بھیجنا اور واپسی روٹنگ الگ مشینوں پر الگ ترتیبات ہیں۔
اگر منزل گیٹ وے کے بالکل پیچھے نہیں بلکہ کسی دوسرے VPN کلائنٹ کے پیچھے ہے تو سرور کو اُس ساتھی کے ذیلی نیٹ ورک کے لیے iroute درکار ہے۔ وہ ہدایت سرور کی ہے اور بتاتی ہے کہ کون سا کلائنٹ کسی سابقے کا مالک ہے؛ فون اُسے اپنے پروفائل سے نہیں دے سکتا، اور کلائنٹ کی جانب کتنی بھی ترمیم اُس کا متبادل نہیں۔
واپسی راستہ واضح طور پر جانچیں۔ جو جواب ٹنل کے بجائے طے شدہ راستے سے نکلے وہ کلاسیکی نیم کھلا علامت پیدا کرتا ہے: کنکشن ایک سمت میں قائم ہوتا ہے اور کچھ واپس نہیں آتا۔ جب ہدف واپس روٹ نہیں کر سکتا تو گیٹ وے پر ماخذ ترجمہ جائز اصلاح ہے، لیکن یہ اپنے نتائج والا پالیسی فیصلہ ہے۔
واپسی اور قبولیت
ترمیم سے پہلے پچھلا پروفائل رکھیں۔ اگر تبدیلی معاملات بگاڑ دے تو اُس نقل کو اُسی دوبارہ درآمد راستے سے بحال کریں، دوبارہ منسلک ہوں، اور یقینی بنائیں کہ پرانا رویہ لوٹ آیا — یہ ثابت کرتا ہے کہ آپ نے وہی بدلا جو آپ نے سوچا تھا۔ جو واپسی پرانی حالت بحال نہ کرے اُس کا مطلب ہے کہ ایپ کے پاس تیسری نقل ہے جو آپ کو نہیں ملی۔
تبدیلی قبول کریں جب چار چیزیں قائم ہوں، نئے کنکشن کے بعد اِس ترتیب میں جانچ کر: منزل اپنے سروس پورٹ پر جواب دیتی ہے، متوقع ہو تو نجی نام حل ہوتا ہے، HTTPS اب بھی مطلوبہ ہوسٹ نام کی توثیق کرتا ہے، اور دوبارہ آغاز یا Wi-Fi سے سیلولر پر جانے کے بعد بھی سب کام کرتا ہے۔ آخری جانچ ہی وہ ہے جو ایسا راستہ پکڑتی ہے جو صرف اُس وقت تک ہے جب تک Android ٹنل دوبارہ قائم نہ کرے۔
- کچھ بھی ترمیم کرنے سے پہلے یقینی بنائیں کہ نیٹ ورک کا مالک منزل کی اجازت دیتا ہے۔
- راستہ اُس پروفائل میں رکھیں جو کلائنٹ لوڈ کرتا ہے، پھر دوبارہ درآمد کریں اور دوبارہ منسلک ہوں۔
- درست پتہ خاندان کے لیے، فی ایپ دائرے کے اندر، سروس پورٹ سے جانچیں۔
- بھیجنا، واپسی روٹنگ اور iroute سرور پر درست کریں، فون پر نہیں۔
- واپسی کی نقل رکھیں، اور دوبارہ آغاز کے بعد دوبارہ جانچیں۔