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

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

وقت پہلا امتیاز ہے۔ لاگ بفر صاف کریں، ناکامی دوبارہ پیدا کریں اور دیکھیں کہ ایپ نے شکایت سے پہلے کیا کیا:

adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60

اگر ایپ کسی بھی بیرونی درخواست کی کوشش سے پہلے انکار کرتی ہے تو آپ مقامی فیصلے کو دیکھ رہے ہیں۔ اگر وہ جڑتی ہے، کچھ بھیجتی ہے اور پھر غلطی دکھاتی ہے تو انکار دوسری طرف سے آیا۔ اگر ٹنل بند ہونے پر بھی ایپ اسی طرح ناکام ہوتی ہے تو VPN کبھی متغیر نہیں تھا۔

اس وقت کو ثبوت سمجھیں، حتمی فیصلہ نہیں۔ ایپ کیش شدہ جواب دوبارہ چلا سکتی ہے، اور پس منظر کی درخواستیں آپ کے دیکھنے سے پہلے کامیاب یا ناکام ہو سکتی ہیں۔ آخری کامیاب درخواست اور غلطی کے اوقات لکھیں، صرف وہ لمحہ نہیں جب پیغام ظاہر ہوا۔

مرحلہ 2: فون کا نیٹ ورک کے بارے میں اپنا نظریہ پڑھیں

Android VPN حالت کو نیٹ ورک کی صلاحیت کے طور پر ظاہر کرتا ہے، اس لیے ایپ کو فعال ٹنل محسوس کرنے کے لیے تجارتی فراہم کنندگان کی فہرست کی ضرورت نہیں۔ یہ کنیکٹیویٹی سروس سے پوچھتی ہے کہ موجودہ نیٹ ورک کون سا ہے، اور جواب میں VPN ٹرانسپورٹ بٹ شامل ہوتا ہے:

val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true

وہ جانچ مقامی اور سستی ہے، اور کسی بھی دور دراز درجہ بندی کے بغیر "یہ ایپ VPN پر کام نہیں کرتی" جیسی رپورٹوں کی پوری قسم کی وضاحت کرتی ہے۔ ایپ جو دیکھ سکتی ہے وہ اب بھی اس کے اپنے نیٹ ورک سیاق پر منحصر ہے، اس لیے یہ مت سمجھیں کہ ہر ایپ ڈیوائس پر ہر پروفائل کا معائنہ کرتی ہے۔

ورک اسٹیشن سے آپ adb shell dumpsys connectivity اور VPN نیٹ ورک اندراج تلاش کر کے ٹیسٹ ڈیوائس پر وہی حالت دیکھ سکتے ہیں۔ ٹنل کھلا ہونے والی ایک رن کا موازنہ بند ہونے والی رن سے کریں اور دونوں نتائج محفوظ رکھیں۔

مرحلہ 3: پڑھیں کہ سرور واقعی کیا دیکھتا ہے

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

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

اگر ایپ سیلولر نیٹ ورک پر چلتی ہے اور اسی اکاؤنٹ کے ساتھ ٹنل پر ناکام ہوتی ہے تو انکار دور والے سرے پر یا ایپ کی اپنی پالیسی میں ہے۔ اگر دونوں میں ناکام ہو تو VPN فرق نہیں ہے اور آپ کو اینڈ پوائنٹس کی جانچ بند کر دینی چاہیے۔

مرحلہ 4: ثبوت کو تین فیصلوں میں سے ایک سے ملائیں

تین امتزاج تقریباً ہر رپورٹ کو ڈھانپ لیتے ہیں۔ ٹنل فعال ہونے کے دوران بغیر کسی بیرونی کوشش کے انکار مقامی ٹرانسپورٹ جانچ کی طرف اشارہ کرتا ہے۔ ایسی درخواست جو جائے اور غلطی کے ساتھ واپس آئے، کسی مخصوص ہوسٹ پر وقت کا ختم ہونا یا علاقے کا پیغام دور والے فریق کی طرف اشارہ کرتا ہے۔ ٹنل کے بغیر سیلولر پر دہرائی جانے والی ناکامی اکاؤنٹ، ایپ ورژن یا سروس کی اپنی پالیسی کی طرف اشارہ کرتی ہے، اور کوئی VPN تبدیلی اسے ہلا نہیں سکتی۔

فیصلہ اس ثبوت کے ساتھ لکھیں جس نے اسے پیدا کیا۔ اس مرحلے کی قدر یہ ہے کہ یہ اس چکر کو روکتا ہے جس میں کوئی فون پر چلنے والی جانچ ٹھیک کرنے کے لیے چار بار ایگزٹ نوڈس بدلتا ہے۔

یہ دعووں کو بھی دیانت دار رکھتا ہے۔ اپنا سرور ہوسٹ کرنا اینڈ پوائنٹ اور اس کے انٹرنیٹ اخراج کو بدلتا ہے؛ یہ Android کو یہ بھلانے پر مجبور نہیں کرتا کہ VPN نیٹ ورک فعال ہے اور ایسی سروس کی قبولیت کی ضمانت نہیں دیتا جو ایڈریس کی درجہ بندی کرتی ہے۔ مقامی فلٹر آپ کے اپنے VPN نیٹ ورک پر بھی اتنی ہی آسانی سے متحرک ہو سکتا ہے جتنا تجارتی پر۔

مرحلہ 5: حمایت یافتہ راستہ اختیار کریں اور اسے جانچیں

پروڈکٹ کی دستاویزی پالیسی اور اس کے سپورٹ مالک سے شروع کریں۔ کلائنٹ ورژن، درست پیغام اور ناکامی کی ایک تنگ کھڑکی بھیجیں؛ صرف یہ ثابت کرنے کے لیے کہ غلطی موجود ہے مکمل ٹریفک کیپچر یا اسناد نہ بھیجیں۔

اگر سروس براہ راست رسائی کی اجازت دیتی ہے اور ڈیوائس پالیسی بھی اجازت دیتی ہے تو ایک ایپ کے لیے استثنا حمایت یافتہ طریقہ ہے، اور یہ ٹنل چھپانے کے بجائے اس ایپ کو جان بوجھ کر ٹنل سے نکال دیتا ہے۔ پھر ایپ کا ٹریفک اپنے راستے سے نکلتا ہے، جو ایک پالیسی فیصلہ ہے جس کی ذمہ داری کسی کو لینی ہوگی۔ VPN کے بغیر بلاک کرنے کی ترتیب میں، مستثنیٰ ایپ آسانی سے کنیکٹیویٹی کھو سکتی ہے، اس لیے یہ کہنے سے پہلے کہ یہ کام کرتا ہے اس امتزاج کو آزمائیں۔

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

متعلقہ مضامین