Android VpnService کی اجازت فہرست: اجازت شدہ صفحات پھر بھی کیوں رک جاتے ہیں

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

مماثل کرنے والا ہی شاذ و نادر مجرم ہوتا ہے

پہلے الگ کرنا ہے مسدود اور ٹوٹا ہوا۔ مسدود نام کو تیزی سے اور نظر آنے والے انداز میں ناکام ہونا چاہیے، کیونکہ براؤزر کو جواب ملتا ہے کہ نام موجود نہیں اور وہ رک جاتا ہے۔ ٹوٹا ہوا نام رکا رہتا ہے، IPv6 پر دوبارہ کوشش کرتا ہے، دوسرے ٹرانسپورٹ پر منتقل ہوتا ہے، اور آپ کو گھومتا ہوا اشارہ دے کر چھوڑ دیتا ہے۔ اگر آپ کو گھومتا اشارہ نظر آئے تو آپ کی اجازت فہرست ایسی چیز کا جواب دے رہی ہے جس پر کلائنٹ کچھ نہیں کر سکتا۔

خالی A ریکارڈ روایتی غلطی ہے۔ صفر جوابات کے ساتھ NOERROR واپس کرنا درست جواب معلوم ہوتا ہے، اس لیے stub حل کنندہ اسے قبول کر لیتا ہے، براؤزر دوبارہ کوشش کرتا ہے، AAAA آزماتا ہے، دوسرا حل کنندہ آزماتا ہے، اور بہت دیر بعد ہار مان جاتا ہے۔ سوال کا حصہ دہرا کر اور ٹرانزیکشن ID نقل کر کے دیا گیا جواب کوڈ 3، یعنی NXDOMAIN، گفتگو فوراً ختم کر دیتا ہے۔ اسے ہر اس نام کے لیے استعمال کریں جسے آپ دانستہ مسترد کرتے ہیں۔

IPv6 بھی ڈیفالٹ کے بجائے اسی فیصلے کا حق دار ہے۔ اگر آپ A کے لیے NXDOMAIN جواب دیں اور AAAA گزرنے دیں تو کلائنٹ IPv6 کے ذریعے مسدود نام تک پہنچ سکتا ہے اور فلٹر لیک ہوتا ہے۔ بعض عمل درآمدات مسدود AAAA استفسارات کا جواب loopback پتے سے دیتے ہیں تاکہ رابطہ متبادل پر جانے کے بجائے فوراً ناکام ہو۔ ایک پالیسی منتخب کریں، اسے دونوں ریکارڈ اقسام پر نافذ کریں، اور دونوں کو لاگ کریں۔

جو سب کچھ پکڑے وہ سب کا مالک ہے

صرف DNS پر مبنی ڈیزائن کبھی addRoute("0.0.0.0", 0) شامل نہیں کرتا، اس لیے TUN انٹرفیس میں صرف استفسارات داخل ہوتے ہیں اور باقی سب نیچے والا نیٹ ورک استعمال کرتا رہتا ہے۔ یہی محفوظ شکل ہے، اور یہ بھی بتاتا ہے کہ کچھ اجازت فہرستیں Wi-Fi پر کام کرتی اور موبائل نیٹ ورک پر کیوں ناکام ہوتی دکھتی ہیں۔

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

حل کنندہ ساکٹ کو سرنگ سے باہر جانا ہوگا

فارورڈنگ ہی اگلے جال کی جگہ ہے۔ کیریئر کے حل کنندہ اکثر ایسے نجی پتے پر رہتے ہیں جہاں سرنگ نہیں پہنچتی، اس لیے آپ کا بھیجا استفسار کہیں نہیں جاتا اور ایپ پڑھنے کا وقت ختم ہونے کی اطلاع دیتی ہے۔ منظور شدہ استفسارات ایسے حل کنندہ کو بھیجیں جسے آپ قابل رسائی جانتے ہیں، اور وہ ساکٹ پہلے VpnService.protect() کو دیں۔ غیر محفوظ ساکٹ استفسار کو آپ ہی کی سرنگ میں واپس بھیجتا ہے، جہاں یہ دوبارہ ایپ تک پہنچتا ہے اور وقت کی حد تک گھومتا رہتا ہے۔

خرابی نیٹ ورک بندش جیسی دکھتی ہے، اسی لیے بگ رپورٹس میں اتنی دیر زندہ رہتی ہے۔ بھیجے گئے استفسارات اور موصول جوابات کے لیے شمار رکھیں: اگر پہلا عدد بڑھے اور دوسرا صفر پر رہے تو آپ فہرست نہیں، ساکٹ دیکھ رہے ہیں۔

سائز اور چیک سم بغیر پیغام ناکام ہوتے ہیں

خاموش اخراج سائز سے بھی آتا ہے۔ بڑے جوابی مجموعے والا DNS جواب، یا کشادہ اختیارات کے ساتھ TCP ہاتھ ملانا، ایسے راستے کے MTU سے تجاوز کر سکتا ہے جو آپ نے کبھی واضح طور پر مقرر نہیں کیا؛ ٹکڑا اوپر غائب ہو جاتا ہے اور کلائنٹ یا چھوٹے سائز میں دوبارہ کوشش کرتا ہے یا کوشش چھوڑ دیتا ہے۔ انٹرفیس MTU کو 1280 پر مقرر کرنا قدامت پسند انتخاب ہے جو بیشتر موبائل راستوں پر قائم رہتا ہے، اور واضح رہنا ایسی ڈیفالٹ کے ورثے سے بہتر ہے جسے کسی نے ناپا نہیں۔

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

VpnService آپ کے لیے کیا نہیں کرے گا

ان کے گرد ڈیزائن کرنے سے پہلے دو حدیں جاننا مفید ہے۔ کوئی عام ایپ Wi-Fi سے باہر نظام گیر پراکسی یا PAC فائل نصب نہیں کر سکتی، اور وہ حصہ تبدیل نہیں ہوا۔ فی ایپ راستہ بدل گیا ہے: API 29 سے پہلے VpnService.Builder پراکسی بالکل نہیں لے جا سکتا تھا، اور API 29 سے setHttpProxy(ProxyInfo.buildPacProxy(uri)) پلیٹ فارم کو VPN نیٹ ورک کے لیے جانچنے کے لیے PAC اسکرپٹ دیتا ہے۔ جب آپ پرانے API کو ہدف بنائیں یا PAC ماڈل قاعدہ بیان نہ کر سکے تو قواعد اپنے کوڈ میں جانچیں۔ UDP بھی مفت نہیں: براؤزر SOCKS پراکسی کے ذریعے صرف TCP بھیجتے ہیں، اور بیشتر SOCKS5 کلائنٹ کبھی UDP ASSOCIATE نافذ نہیں کرتے، اس لیے پراکسی پر مبنی ڈیزائن TCP صحت مند دکھنے کے دوران UDP گراتا یا لیک کرتا ہے۔

یہی دوسری حد وجہ ہے کہ UDP پر مبنی پروٹوکول عام نیٹ ورک پر کام کر کے آپ کے VPN کے جڑنے کے لمحے ناکام ہو سکتا ہے۔ اگر سرنگ سے UDP لے جانے کی توقع ہو تو فارورڈر کو اس کے لیے فارورڈنگ راستہ نافذ کرنا ہوگا، نہ کہ صرف دوسری ساکٹ قسم والا TCP راستہ۔

اسی ترتیب سے جانچیں

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

1. نصب شدہ روٹ کی فہرست بنائیں اور تصدیق کریں کہ غیر DNS پیکٹ TUN انٹرفیس میں داخل ہوتے ہیں یا نہیں۔
2. ایک مسدود اور ایک منظور شدہ نام کے لیے استفسار کا نام، فیصلہ اور جواب کوڈ لاگ کریں۔
3. تصدیق کریں کہ حل کنندہ ساکٹ محفوظ ہے اور منتخب حل کنندہ سرنگ کے اندر سے جواب دیتا ہے۔
4. انٹرفیس MTU اور ہاتھ سے بنائے گئے ایک جواب کی چیک سم کی تصدیق کریں۔
5. وہی صفحہ Wi-Fi اور موبائل نیٹ ورک پر دہرائیں، کیونکہ کیریئر حل کنندہ اور راستے کا MTU مختلف ہیں۔

اگر پانچوں قائم رہیں اور صفحہ پھر بھی رکا رہے تو اگلا مشتبہ خود فارورڈر ہے: پکڑی گئی درخواست کا پکڑے گئے جواب سے موازنہ کریں اور گمشدہ بائٹ شمار یا آدھی بند ساکٹ تلاش کریں۔ VpnService.Builder حوالہ روٹ، DNS اور MTU کے معاہدے محیط ہے، اور protect() builder اختیار نہیں بلکہ الگ VpnService کال ہے؛ جڑا ہوا انٹرفیس صرف یہ بتاتا ہے کہ پہلا معاہدہ پورا ہوا۔