اینڈرائیڈ ایمولیٹر اور ہوسٹ VPN: DNS اسنیپ شاٹ اور NAT

جب ایمولیٹر اُس بلڈ سرور تک نہیں پہنچ پاتا جسے ہوسٹ کا براؤزر بآسانی کھولتا ہے، تو مفید سوال یہ نہیں کہ VPN کام کرتی ہے یا نہیں۔ سوال یہ ہے کہ مہمان کو دو میکانزم میں سے کون سا غائب ہے۔ مجازی آلہ ایمولیٹر کے NAT کے پیچھے اپنا نیٹ ورک اسٹیک چلاتا ہے، اور اس کی resolver فہرست بوٹ کے وقت لی گئی کاپی ہے، اس لیے بعد میں اوپر آنے والی ٹنل ہوسٹ کا راستہ بدلتی ہے مگر وہ نہیں بدلتی جو مہمان پوچھتا ہے۔ ان دو تہوں کو سمجھنا اس مسئلے کی تقریباً ہر شکل کی وضاحت کرتا ہے۔

مہمان مقررہ NAT کے پیچھے الگ اسٹیک ہے

QEMU کی user-mode نیٹ ورکنگ مہمان کو 10.0.2.15 پر، گیٹ وے کو 10.0.2.2 پر اور DNS سروس کو 10.0.2.3 سے 10.0.2.6 تک رکھتی ہے۔ مہمان کی باہر جانے والی ٹریفک ہوسٹ کرنل فارورڈ نہیں کرتا؛ وہ ہوسٹ کی طرف ساکٹ میں تبدیل ہوتی ہے، ہر مہمان کنکشن کے لیے ایک، اور وہ ساکٹ ہوسٹ کے ایڈریس اسپیس سے باہر جاتے ہیں۔ اسی لیے مہمان کنکشن بننے کے لمحے ہوسٹ کے روٹنگ فیصلے کو ورثے میں لیتا ہے، اور اسی لیے مہمان کے روٹ ٹیبل میں کوئی اندراج نہیں جو آپ کی ٹنل کا نام لے۔

یہی میکانزم مہمان کو ایک مفید راستہ دیتا ہے۔ 10.0.2.2 ہوسٹ کے loopback انٹرفیس کا عرفی نام ہے، اس لیے لیپ ٹاپ پر 127.0.0.1 پر سننے والی سروس اس پتے پر مہمان سے قابلِ رسائی ہے۔ کلائنٹ loopback پر جو کچھ بھی ظاہر کرتا ہے اس تک اس راستے سے پہنچا جا سکتا ہے، اور یہی نیچے بیان کردہ پراکسی ترتیب کی بنیاد ہے۔

مہمان جو نہیں کر سکتا وہ ہوسٹ کے نیٹ ورک کو یوں دیکھنا ہے جیسے وہ اس کا namespace ہو۔ کوئی برج نہیں، مشترکہ روٹ ٹیبل نہیں اور ورثے میں ملا resolver نہیں؛ صرف وہ NAT سروس جو اس کے پیکٹ وصول کرتی ہے اور وہ اسنیپ شاٹ جو لانچر نے مجازی آلے کے آغاز پر لیا تھا۔

DNS ایک اسنیپ شاٹ ہے، زندہ منظر نہیں

آغاز پر ایمولیٹر ہوسٹ کی resolver فہرست پڑھتا ہے اور مہمان کو زیادہ سے زیادہ چار سرور دیتا ہے، جو 10.0.2.3 سے 10.0.2.6 پتوں پر ظاہر ہوتے ہیں۔ اگر اُس لمحے ٹنل نیچے تھی تو اسنیپ شاٹ میں وہی عوامی resolver ہوگا جو لیپ ٹاپ استعمال کر رہا تھا، اور مہمان ساری عمر اسی سے پوچھتا رہے گا۔ عوامی نام حل ہوتے ہیں، اندرونی نام ناکام ہوتے ہیں، اور تمام علامات VPN کی طرف اشارہ کرتی ہیں جبکہ اصل پرانی قدر resolver فہرست ہے جو ٹنل اوپر آنے سے چند منٹ پہلے لی گئی تھی۔

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

adb shell dumpsys connectivity | grep -i -A2 dns
adb shell ping -c 1 build.internal.example

ایمولیٹر آغاز پر واضح resolver بھی قبول کرتا ہے، جو اُس وقت مفید ہے جب آپ کو معلوم ہو کہ مہمان کو کون سا سرور استعمال کرنا چاہیے، اور خطرناک ہے جب وہ سرور عوامی ہو:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

عوامی resolver کے پاس اندرونی زون کی کاپی نہیں ہوتی، اس لیے ایک کو پن کرنا ترتیب کے مسئلے کو مستقل ناکامی میں بدل دیتا ہے۔ اگر پروفائل نجی DNS دھکیلتا ہے تو ٹنل کو وہ فراہم کرنے دیں اور پتہ سخت کوڈ کرنے کی بجائے مہمان کو کولڈ بوٹ کریں۔

روٹنگ کنکشن کے وقت ہوسٹ کی پیروی کرتی ہے

چونکہ مہمان کے کنکشن ہوسٹ کے ساکٹ بنتے ہیں، روٹنگ کا فیصلہ ساکٹ بننے کے وقت ہوتا ہے۔ درخواست سے پہلے ٹنل اوپر ہونا یعنی درخواست پروفائل کے روٹس کے تابع ٹنل سے باہر جاتی ہے۔ صرف منتخب prefix اٹھانے والا split-tunnel پروفائل آپ کے نجی subnet کو خوشی سے باہر چھوڑ دے گا، اس لیے ہوسٹ تک رسائی مہمان کے بارے میں ایک مفروضہ ہے، نتیجہ نہیں۔ موجودہ مہمان کنکشن اُس راستے کو برقرار رکھتے ہیں جس پر بنے تھے، اسی لیے دوبارہ جڑنے والا کلائنٹ ایمولیٹر میں اٹکا ہوا ڈاؤن لوڈ ہمیشہ درست نہیں کرتا۔

تصدیق ہوسٹ کے انٹرفیس پر ہوتی ہے، مہمان کے اعداد و شمار میں نہیں:

sudo tcpdump -ni tun0 'host 203.0.113.10'

اگر مہمان کی درخواست ٹنل انٹرفیس پر نظر آئے تو روٹنگ کام کر رہی ہے اور مسئلہ اس کے اوپر ہے۔ اگر وہ فزیکل انٹرفیس پر نظر آئے تو پروفائل اُس prefix کو نہیں ڈھکتی، اور مہمان کی طرف کوئی دوبارہ ترتیب اسے نہیں بدلے گی۔

جب کلائنٹ صرف loopback پراکسی فراہم کرے

کچھ تجارتی کلائنٹ سسٹم ٹنل بالکل نہیں بناتے۔ وہ 127.0.0.1 پر HTTP یا SOCKS سننے والا ظاہر کرتے ہیں اور توقع کرتے ہیں کہ ایپلیکیشنز اسے استعمال کریں۔ مہمان وہ ساکٹ براہِ راست نہیں دیکھ سکتا، مگر ایمولیٹر کو اسے استعمال کرنے کو کہا جا سکتا ہے، یا تو توسیعی کنٹرولز سے (Settings، پھر Proxy، دستی موڈ، ہوسٹ 127.0.0.1 اور وہ پورٹ جو کلائنٹ پرنٹ کرتا ہے) یا آغاز پر:

emulator -avd Pixel_API_34 -http-proxy http://127.0.0.1:8080

پورٹ کلائنٹ کی ونڈو سے کاپی کریں؛ اندازہ لگایا گیا پورٹ خاموشی سے ناکام ہوتا ہے اور ٹوٹی ٹنل جیسا لگتا ہے۔ یاد رکھیں یہ کیا ڈھکتا ہے: HTTP پراکسی کی ترتیب کو پراکسی جاننے والی ایپلیکیشنز مانتی ہیں، اور خام ساکٹ اسے مکمل نظر انداز کرتے ہیں۔ اگر کام وہ native binary ہو جو اپنے کنکشن خود کھولتا ہے تو پراکسی کا راستہ ٹنل کے برابر نہیں اور موازنہ واضح طور پر کرنا ہوگا۔

نتیجہ مہمان کے اندر سے ثابت کریں

ایک ہی سیشن میں دو ٹیسٹوں سے حل اور روٹنگ کو الگ کریں۔ وہ نام جو ناکام ہو جبکہ عددی پتہ جواب دے، DNS اسنیپ شاٹ کا مسئلہ ہے، اور حل ترتیب یا واضح resolver ہے۔ دونوں ناکام ہوں تو یہ روٹنگ یا پالیسی کی طرف اشارہ ہے، اور اگلا معائنہ یہ ہے کہ ایپ اپنی نیٹ ورک پابندیوں والے work profile میں چل رہی ہے یا نہیں۔

آخر میں، جانیں کہ آپ کس مہمان پر جانچ کر رہے ہیں۔ بہت پرانی ایمولیٹر امیجز اُس tun سپورٹ کے بغیر جاری ہوتی تھیں جو مہمان کی طرف VPN کلائنٹ کو درکار ہے، اس لیے وہاں کوئی پروفائل کبھی کام نہ کر سکی؛ موجودہ امیجز میں یہ موجود ہے۔ موجودہ امیج پر ناکام ہونے والا کلائنٹ کلائنٹ یا پروفائل کا مسئلہ ہے، اور ہوسٹ کی ٹنل دوبارہ بنانا نتیجہ نہیں بدلے گا۔