Android VPN سرور: root فون کو قابلِ رسائی نہیں بناتا
تین الگ مسائل فیصلہ کرتے ہیں کہ فون VPN کلائنٹس کی خدمت کر سکتا ہے یا نہیں: اندر آنے والا راستہ، اختیارات کا ماڈل اور فارورڈنگ۔ root صرف درمیان والے کو چھوتا ہے۔
root بدلتا ہے کہ کسی عمل کو کون سی نیٹ ورک کارروائیاں آزمانے کی اجازت ہے۔ یہ فون کو عوامی طور پر قابلِ رسائی پتہ نہیں دیتا، آپریٹر کے پاس آنے والی میپنگ محفوظ نہیں کرتا، اور ری بوٹ کے بعد ڈیمون کو زندہ نہیں رکھتا۔ اگر آپ فیصلہ کر رہے ہیں کہ Android فون VPN سرور کا کردار ادا کر سکتا ہے یا نہیں، تو تین سوال الگ کریں: کیا مطلوبہ کلائنٹ سننے والے تک پہنچ ہی سکتا ہے، سرور کی تنفیذ کو کس اختیارات کے ماڈل کی ضرورت ہے، اور سرنگ کھڑی ہونے کے بعد کیا فارورڈ کرنا ہے۔
کون اور کہاں سے فون تک پہنچے
اسی اجازت یافتہ LAN میں موجود کلائنٹ اور موبائل ڈیٹا پر موجود کلائنٹ دو مختلف نیٹ ورک جانچ رہے ہیں۔ پہلے مطلوبہ کا فیصلہ کریں، کیونکہ جواب ایک دوسرے پر لاگو نہیں ہوتے۔ Wi-Fi پر غیر مطالبہ آنے والی ٹریفک کو عام طور پر اوپر والے راؤٹر پر میپنگ اور اس سے آگے قابلِ استعمال عوامی راستہ درکار ہوتا ہے۔ سیلولر پر آپریٹر سطح کا NAT یعنی آنے والا IPv4 اکثر دستیاب نہیں ہوتا، فون جو بھی اجازت دے۔
دراصل یہی آخری نکتہ ہے جسے root چھو نہیں سکتا۔ فون کا مقامی فائر وال اور آپریٹر کا NAT مختلف نظام ہیں، اور پہلے کو بدلنے کا دوسرے پر کوئی اثر نہیں ہوتا۔ نجی انٹرفیس پتہ، موبائل ڈیٹا کا آئیکن یا سنتا ہوا ساکٹ قابلِ رسائی ہونے کا ثبوت نہیں ہیں۔ اگر آپریٹر کا راستہ واقعی عالمی سطح پر روٹ ہونے والا IPv6 فراہم کرتا ہے، تو بھی اس کے لیے جان بوجھ کر سننے والا اور فائر وال پالیسی درکار ہے؛ پتہ ہونا کنکشن قبول کرنے کے برابر نہیں۔
| Client path | What actually decides reachability |
|---|---|
| Same LAN | The phone's listener and its local firewall |
| Wi-Fi, from the internet | A mapping on the upstream router plus a usable public path beyond it |
| Cellular IPv4 | The carrier's NAT, which the handset does not control |
| Cellular IPv6 | Address, listener and firewall policy together |
خدمت دینا اور فارورڈ کرنا دو الگ کامیابیاں ہیں
مکمل شدہ VPN ہینڈ شیک ثابت کرتا ہے کہ سرنگ موجود ہے۔ یہ ثابت نہیں کرتا کہ کلائنٹ فون کے پیچھے والے LAN تک پہنچ سکتا ہے، اور نہ یہ کہ فون انٹرنیٹ سے نکلنے کا راستہ بن سکتا ہے۔ یہ الگ ترتیبات ہیں جو اندرونی پتوں کے منصوبے، راستوں، واپسی کے رویے اور اس کام کے لیے تنگ فارورڈنگ پالیسی پر بنتی ہیں جو آپ واقعی چاہتے ہیں۔
ناکامی کا انداز متوقع ہے: ہینڈ شیک کامیاب ہوتا ہے، کلائنٹ جڑا ہوا دکھاتا ہے، اور کچھ لوڈ نہیں ہوتا۔ کلائنٹ کی ڈیبگنگ سے پہلے فیصلہ کریں کہ دو کرداروں میں سے کون سا بنا رہے ہیں۔ فون کے نیٹ ورک پر موجود ڈیوائس تک دور سے رسائی اور مکمل سرنگ کے ذریعے انٹرنیٹ سے نکلنا مختلف فارورڈنگ قواعد چاہتے ہیں، اور ایک چاہتے ہوئے دونوں دینا آپ کی مانگی ہوئی صلاحیت شامل کیے بغیر خطرہ بڑھاتا ہے۔
اختیارات کا ماڈل ایک انتخاب ہے، root یا کچھ نہیں ایسا نہیں
کرنل TUN ڈیوائس استعمال کرنے والا روایتی OpenVPN ڈیمون متعلقہ صلاحیتیں، ڈیوائس نوڈ تک رسائی اور Android کی سیکیورٹی پالیسی کا تعاون چاہتا ہے۔ root SELinux سے ہمہ گیر استثنا نہیں؛ اختیارات والا عمل بھی پلیٹ فارم پالیسی سے محدود رہتا ہے۔ اسی لیے Linux سرور پر آسانی سے چلنے والی بائنری فون پر اجازتوں کے بارے میں واضح خرابی کے بغیر ناکام ہو سکتی ہے۔
یوزر اسپیس گیٹ وے کی تنفیذ کا اختیارات کا ماڈل بالکل مختلف ہو سکتا ہے، لہٰذا یہ عام دعویٰ کہ Android پر ہر VPN سرور کو root درکار ہے بہت وسیع ہے۔ root آپ کو زیادہ کارروائیاں آزمانے کی صلاحیت دیتا ہے، یہ ضمانت نہیں کہ انہیں اجازت ملے گی یا نتیجہ قابلِ رسائی ہوگا۔
Android کی اپنی VPN سروس رجسٹریشن پھر ایک الگ طریقہ کار ہے۔ یہ ایپ کو متعین لائف سائیکل کے ساتھ منظم کلائنٹ انٹرفیس دیتا ہے؛ یہ عام سرور انسٹالر نہیں، اور ٹرمینل سے ڈیمون شروع کرنے سے اسے مستقل انتظام، فی ایپ پالیسی یا اپنا بازیابی راستہ نہیں ملتا۔
اگر آپ کو نکلنے کا مقام چاہیے تو فنِ تعمیر بدلیں
جب مقصد موجودہ OpenVPN پروفائل سے مطابقت نہیں بلکہ صرف فون کے ذریعے دور سے انٹرنیٹ سے نکلنا ہے، تو اوورلے نیٹ ورک کا معاون اخراج نوڈ زیادہ موزوں ڈیزائن ہے۔ Tailscale اپنے رجسٹریشن، اجازت اور کلائنٹ کے انتخاب کے مراحل کے ساتھ Android اخراج نوڈ کا کردار دستاویز کرتا ہے۔
یہ تبادلہ حقیقی ہے اور صاف کہنے کے قابل ہے: آپ مختلف پروٹوکول، مختلف اعتماد کا ماڈل اور اس اکاؤنٹ و ہم آہنگی سروس پر انحصار قبول کرتے ہیں۔ یہ نہ بدلی ہوئی OpenVPN کلائنٹ کو اوورلے میں شامل کرتا ہے اور نہ عوامی پتے پر OpenVPN سننے والا دیتا ہے۔
تعیناتی کو ابھی اور کیا چاہیے
آپ جو بھی راستہ چنیں، بنیادی آپریشنل چیزیں فیصلہ کرتی ہیں کہ یہ ایک ہفتہ چلے گا یا نہیں۔ سرور کی اسناد نجی رکھیں، الگ الگ کلائنٹ شناختیں جاری کریں، اور ضرورت سے پہلے منسوخی کی منصوبہ بندی کریں۔ فیصلہ کریں کہ اپ ڈیٹس کیسے آتی ہیں، پس منظر میں سروس کو کیا چلاتا رہتا ہے، اور ری بوٹ یا نیٹ ورک کی تبدیلی کے بعد یہ کیسے بحال ہوتی ہے۔
آسان لگنے والے شارٹ کٹ سے بچیں: پرانی اسٹیٹک بائنری، ہارڈ کوڈ شدہ انٹرفیس نام، اور موجودہ فائر وال پالیسی مٹا دینے والی اسٹارٹ اپ اسکرپٹ۔ پھر نتیجہ صرف ایک ٹھوس امتحان پر قبول کریں: مجاز دور کا کلائنٹ مطلوبہ وسیلے تک پہنچتا ہے، ممنوع منزلیں دستیاب نہیں رہتیں، اور معاون لائف سائیکل واقعے کے بعد ڈیوائس خود بخود واپس آتا ہے۔ root رسائی اس نتیجے کا ایک ممکنہ جزو ہے، اور شاذ و نادر ہی فیصلہ کن۔