Android ایپ VPN کے باہر نام حل کرتی ہے: بائنڈنگ چیک لسٹ

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

مرحلہ 1: ثابت کریں کہ ایپ کس نیٹ ورک پر ہے

اسٹیٹس بار کے بجائے ایپ کا اپنا منظر پڑھیں۔ ConnectivityManager سے فعال نیٹ ورک، اس کا LinkProperties، DNS سرورز کی فہرست اور نجی DNS کی ترتیب حاصل کریں۔ اگر فہرست میں VPN کا resolver ہے تو ایپ کے پاس اس تک راستہ ہے؛ اگر اس میں Wi-Fi کا resolver ہے تو ٹنل اس عمل کے لیے ڈیفالٹ نیٹ ورک نہیں ہے۔

VPN آئیکن صرف یہ بتاتا ہے کہ ٹنل موجود ہے۔ یہ نہیں بتاتا کہ ایپ کا عمل اس سے بائنڈ تھا، اور Android ہمیشہ نام کی حل پذیری کو اس نیٹ ورک سے نہیں گزارتا جو فعال دکھائی دیتا ہے۔ دوسرے آلے کو فارورڈ کرنے والی مقامی VPN ایپس، بغیر انٹرنیٹ والے Wi-Fi نیٹ ورک اور بنانے والوں کے بلڈز ایپ کو ٹنل کے سرورز کے بجائے ڈیفالٹ resolver سے پوچھتے رہنے دے سکتے ہیں۔

مرحلہ 2: VPN ٹرانسپورٹ طلب کریں اور عمل کو بائنڈ کریں

جب ایپ کو ٹنل کا resolver لازماً استعمال کرنا ہو تو VPN ٹرانسپورٹ والا نیٹ ورک طلب کریں اور کال بیک میں عمل کو بائنڈ کریں، تاکہ کوڈ اندازہ نہ لگائے کہ نیٹ ورک کب آئے گا:

val request = NetworkRequest.Builder()
    .addTransportType(NetworkCapabilities.TRANSPORT_VPN)
    .build()

connectivityManager.requestNetwork(request, object : NetworkCallback() {
    override fun onAvailable(network: Network) {
        val bound = connectivityManager.bindProcessToNetwork(network)
        Log.i(TAG, "bound to VPN network: " + bound)
    }
})

یہ کال پورے عمل کا ڈیفالٹ نیٹ ورک بدل دیتی ہے، اس لیے اس کے بعد بنایا گیا ہر ساکٹ اسی کو استعمال کرتا ہے۔ پہلے سے موجود ساکٹ وہی نیٹ ورک برقرار رکھتے ہیں جس پر بنے تھے، اسی لیے بائنڈنگ سے پہلے کھلا کنکشن پول پرانے راستے سے حل کرتا رہ سکتا ہے۔ واپس ملنے والی قدر boolean ہے، اور false نتیجے کا مطلب ہے کہ بائنڈنگ نہیں ہوئی؛ مختصر تاخیر سے دوبارہ کوشش کریں اور دونوں کوششیں لاگ کریں۔

مرحلہ 3: بائنڈنگ کو صرف ضرورت تک محدود رکھیں

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

resolver کی دو خصوصیات بغیر کسی خرابی کے بائنڈنگ کو ہرا سکتی ہیں۔ سخت موڈ میں نجی DNS سوالات کو نیٹ ورک resolver کے بجائے نامزد DoT سرور پر بھیجتا ہے، اور اپنا DNS-over-HTTPS کلائنٹ رکھنے والی ایپ سسٹم resolver کو مکمل طور پر نظر انداز کر دیتی ہے۔ یہ طے کرنے سے پہلے کہ بائنڈنگ ناکام ہوئی، دونوں جانچیں۔ وہ سوال جو کبھی VPN کے DNS سرور تک نہ پہنچے، ٹنل کی طرف کے کسی لاگ میں ظاہر نہیں ہوگا۔

مرحلہ 4: CONNECTED پابندی پر بھروسا نہ کریں

WorkManager میں NetworkType.CONNECTED کا مطلب ہے کہ نیٹ ورک جڑا ہوا ہے، اور VPN ٹرانسپورٹ اسے اس وقت بھی پورا کرتا ہے جب نیچے کا Wi-Fi یا سیلولر لنک ختم ہو چکا ہو۔ کام چلتا ہے، ہر درخواست ناکام ہوتی ہے، اور دوبارہ کوشش کی پالیسی اسے شیڈولنگ بگ جیسا طوفان بنا دیتی ہے۔ ٹنل ایک نیٹ ورک ہے؛ یہ پابندی کبھی انٹرنیٹ کی جانچ نہیں تھی۔

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

مرحلہ 5: ثبوت درج کریں اور حد دوبارہ جانچیں

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

اسے اپنے معاونت یافتہ قدیم ترین Android ورژن اور ایک موجودہ ریلیز پر دہرائیں۔ resolver کا وہ رویہ جو ڈیفالٹ راستے کو درست دکھاتا ہے، بالکل وہی جگہ ہے جہاں آلات اور ورژن مختلف ہوتے ہیں، اور جو بلڈ صرف جدید ترین ٹیسٹ ڈیوائس پر پاس ہوتا ہے وہ آپ کی بھیجی جانے والی حد کے لیے تصدیق شدہ نہیں۔ adb shell dumpsys connectivity یہ تصدیق کرنے کا تیز طریقہ ہے کہ ناکامی دہراتے وقت ڈیوائس کون سے نیٹ ورک اور صلاحیتیں بتاتا ہے۔