Android chroot VPN: سرنگ کیوں کام کرتی ہے اور ایپس اسے نظرانداز کیوں کرتی ہیں

آپ فون پر chroot کے تحت چلنے والی Linux ڈسٹری بیوشن لاتے ہیں، اس میں VPN کلائنٹ انسٹال کرتے ہیں، اور شیل اعلان کرتا ہے کہ سرنگ مکمل ہو گئی۔ پھر آپ براؤزر پر جاتے ہیں اور ٹریفک ایسے موبائل ڈیٹا سے باہر جاتی ہے جیسے کچھ ہوا ہی نہ ہو۔ یا اس کے برعکس: کلائنٹ نے اسی نیم اسپیس میں ڈیفالٹ راستہ ڈال دیا جو Android واقعی استعمال کرتا ہے، اس لیے فون کی ہر ایپ کنیکٹیویٹی کھو دیتی ہے۔ یہ دونوں علامات ایک ہی گمشدہ حصے سے آتی ہیں، اور ان میں سے کوئی بھی VPN کلائنٹ کی خرابی نہیں ہے۔

شیل کہتا ہے جڑ گیا، ایپس متفق نہیں

پہلا نتیجہ عام ہے۔ chroot سے کھلی یوزر اسپیس سرنگ اپنا ہینڈ شیک مکمل کر سکتی ہے، اپنے اعداد و شمار چھاپ سکتی ہے اور وہی ٹریفک لے جا سکتی ہے جو یہی شیل پیدا کرتا ہے، جبکہ Android کی ایپس فون کا ڈیفالٹ نیٹ ورک استعمال کرتی رہتی ہیں۔ کوئی انہیں روک نہیں رہا، کیونکہ کسی نے Android کو نہیں بتایا کہ VPN موجود ہے۔

دوسرا نتیجہ خطرناک ہے۔ اگر chroot Android کا نیٹ ورک نیم اسپیس شیئر کرتا ہے، جو ڈیفالٹ طور پر کرتا ہے، تو کافی اختیارات والا عمل پورے فون پر اثر ڈالنے والے راستے اور TUN انٹرفیس شامل کر سکتا ہے۔ پھر سرنگ ہر ایپ کے لیے کام کرتی ہے، ان ایپس سمیت جنہیں آپ راستہ دینا نہیں چاہتے تھے، اور فون کی کنیکٹیویٹی اب ایسے ڈیمون پر منحصر ہے جس کے پاس لائف سائیکل مینجمنٹ، کنکشن اشارے اور always-on پالیسی نہیں ہے۔

آپ کو دونوں میں سے کون سا ملا، ایک ہی کمانڈ سے معلوم ہو سکتا ہے۔ chroot کے اندر ip route کا موازنہ اس کے باہر کے Android شیل سے اسی کمانڈ سے کریں۔ یکساں آؤٹ پٹ کا مطلب ہے chroot ہوسٹ نیم اسپیس میں ہے: یہ جو بھی نیٹ ورکنگ تبدیلی کرتا ہے وہ پورے فون پر لاگو ہوتی ہے۔ مختلف آؤٹ پٹ کا مطلب ہے لانچر نے اس کے لیے نیم اسپیس بنایا، اور اس کی سرنگ Android کے لیے ساخت کے اعتبار سے پوشیدہ ہے۔

chroot نے کیا بدلا اور کیا نہیں

chroot سسٹم کال ایک ہی کام کرتی ہے: وہ ڈائریکٹری بدلتی ہے جو راستوں کے نام حل کرنے کے لیے استعمال ہوتی ہے۔ مین پیج صریحاً کہتا ہے کہ یہ حفاظتی حد نہیں، اور انٹرفیس، راستوں یا VPN کی حالت کے بارے میں کچھ نہیں کہتا۔ لوگ Linux کنٹینر سے جو کچھ توقع کرتے ہیں — نجی نیٹ ورک اسٹیک، فلٹر شدہ فائل سسٹم، وسائل کی حدیں — وہ دیگر میکانزم سے آتا ہے جو لانچر نے استعمال کیے ہوں یا نہ ہوں۔

اسی لیے یہ دعوے کہ chroot VPN کو الگ کرتا ہے، عام طور پر غلط سوال کا جواب دیتے ہیں۔ متعلقہ سوال یہ ہے کہ عمل کس نیم اسپیس میں چلتا ہے اور کس SELinux ڈومین میں محدود ہے، اور دونوں اس بات کی خصوصیات ہیں کہ یہ کیسے شروع کیا گیا، chroot کے لفظ کی نہیں۔

TUN کو تین چیزیں چاہیے، اور ڈیوائس نوڈ ان میں سے ایک ہے

روایتی یوزر اسپیس سرنگ کو کھلنے والا TUN ڈیوائس، اس ڈیوائس کے لیے کرنل سپورٹ، اور انٹرفیس و راستے ترتیب دینے کی اجازت چاہیے۔ یہ الگ الگ شرطیں ہیں، اور /dev کے تحت راستے کا نام بنانا بذات خود ان میں سے کوئی پوری نہیں کرتا:

ls -l /dev/net/tun
ip tuntap add dev tun0 mode tun

Android پر کرنل میں TUN سپورٹ عام طور پر شامل ہوتا ہے، کیونکہ پلیٹ فارم کی اپنی VPN سروس اسے استعمال کرتی ہے، لیکن اس کا مطلب یہ نہیں کہ آپ کا عمل اسے استعمال کر سکتا ہے۔ انٹرفیس کی ترتیب کے لیے نیٹ ورک ایڈمنسٹریشن کی صلاحیت چاہیے، اور SELinux فیصلہ کرتا ہے کہ عمل ڈیوائس نوڈ تک پہنچ سکتا ہے یا نہیں۔ انکار بغیر واضح وجہ کے اجازت کی خرابی لگتا ہے، اور جواب آڈٹ ریکارڈ میں ہے:

dmesg | grep avc
logcat -d | grep "avc: denied"

Root اسے حل نہیں کرتا۔ SELinux uid 0 کے طور پر چلنے والے عملوں کو بھی دوسروں کی طرح محدود کرتا ہے، اس لیے root شیل سے شروع کیا گیا chroot بھی اس ڈیوائس سے انکار کا شکار ہو سکتا ہے جو وہ دیکھتا ہے۔ پرانے انسٹالر کو چلانے کے لیے نفاذ بند کرنا پورے فون کا فیصلہ ہے جس کے اثرات سرنگ سے کہیں آگے ہیں، اور یہ باسی بائنری کا حل نہیں ہے۔

Android ایپس آپ کی سرنگ کو کیوں نظرانداز کرتی ہیں

Android کا تعاون یافتہ ماڈل یہ ہے کہ VPN ایپ پلیٹ فارم کی VPN سروس کے ذریعے رجسٹر ہو، صارف سے ایک بار رضامندی مانگے اور اپنی سرنگ کے لیے فائل ڈسکرپٹر وصول کرے۔ پھر پلیٹ فارم ٹریفک کو اسی ڈسکرپٹر کی طرف بھیجتا ہے اور صارف یا منتظم کی منتخب کردہ ایپ حد نافذ کرتا ہے؛ اسی لیے وہی میکانزم فی ایپ، فی پروفائل ہو سکتا ہے اور always-on اور block-without-VPN ترتیبات کے ساتھ ملایا جا سکتا ہے۔ Android VPN ڈیولپمنٹ گائیڈ اسی ہینڈ شیک کی وضاحت کرتی ہے، اور اہم نکتہ یہ ہے کہ یہ رجسٹریشن ہے، روٹنگ کی چال نہیں۔

chroot کے اندر کا ڈیمون کبھی رجسٹر نہیں ہوتا۔ رضامندی کا ڈائیلاگ نہیں، اسٹیٹس بار میں چابی کا نشان نہیں، فی ایپ شامل یا خارج کرنے کی فہرست نہیں، اور always-on پالیسی میں شرکت نہیں۔ اس لیے ایپس ڈیفالٹ نیٹ ورک استعمال کرتی رہتی ہیں، اور سرنگ صرف وہی لے جاتی ہے جو شیل خود بھیجتا ہے۔

دوسری سمت جانا بھی مدد نہیں کرتا۔ ہوسٹ نیم اسپیس میں راستے دھکیلنا سب کچھ پکڑ لیتا ہے، وہ ٹریفک بھی جو پلیٹ فارم مقامی رکھنے کی توقع رکھتا تھا، اور یہ فی ایپ کنٹرول کے بغیر اور صارف کے دیکھنے یا منسوخ کرنے کے بغیر کرتا ہے۔ کوئی درمیانی ترتیب نہیں جہاں chroot ڈیمون صرف ایک ایپ کے لیے ٹریفک روٹ کرے۔

بائنری مطابقت ایک الگ دیوار ہے

نیٹ ورک پہلو دلچسپ ہونے کے باوجود، ایگزیکیوٹیبل کی اپنی شرطیں ہیں: CPU آرکیٹیکچر، ڈائنامک لوڈر، C لائبریری، اور وہ کرنل سہولیات جن کی وہ توقع کرتا ہے۔ Android glibc کے بجائے bionic استعمال کرتا ہے، اور ڈیسک ٹاپ ڈسٹری بیوشن کے لیے بنائی گئی پرانی بائنری کو ایسی لائبریریاں درکار ہو سکتی ہیں جو اب ڈیوائس پر نہیں ہیں۔

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

Android سیاق میں اسے ثابت کریں اور بعد میں صاف کریں

جو واقعی آپ کے لیے اہم ہے، اہم پہلو سے جانچیں: مخصوص ایپ کھولیں، مخصوص نجی منزل تک پہنچیں، تصدیق کریں کہ کون سا حل کنندہ جواب دے رہا ہے، پھر سرنگ منقطع کریں اور دستاویزی رویے کی تصدیق کریں۔ chroot کے اندر ٹرمینل سے آنے والا نتیجہ صرف اسی ٹرمینل کے عمل کے سیاق کا ثبوت ہے، اس سے زیادہ کچھ نہیں۔

اگر تجربات کے دوران ہوسٹ راستے بدلے تو انہیں واپس رکھیں اور لکھیں کہ کیا بدلا۔ پھر دیکھیں کہ فون میں always-on VPN ترتیب دیا گیا ہے یا نہیں، کیونکہ اصول چھوڑنے والا پرانا تجربہ مہینوں بعد پلیٹ فارم کی خرابی لگ سکتا ہے۔

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