Android پر VPN IPv6 کے ساتھ چلتا ہے، مگر براؤزر اب بھی IPv4 چنتا ہے

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

مرحلہ 1: ثابت کریں کہ AAAA استفسار کا جواب کس حل کنندہ نے دیا

Android کے پاس ایک ہی DNS راستہ نہیں۔ VPN اپنے نیٹ ورک کے لیے DNS سرور دھکیل سکتا ہے، نظام ان ہوسٹ ناموں کے لیے Private DNS استعمال کر سکتا ہے جنہیں وہ موزوں سمجھتا ہے، اور Chrome chrome://settings/security سے اپنا خفیہ کردہ حل کنندہ چلا سکتا ہے۔ ایسے فون پر جہاں ٹنل 10.61.0.1 دھکیلتی ہے مگر Private DNS کسی عوامی فراہم کنندہ کی طرف اشارہ کرتا ہے، آپ کے نجی زون کے اندر کا نام اس مشین سے حل نہیں ہوتا جو زون کی مالک ہے۔ براؤزر اس نام پر اختیار نہ رکھنے والے حل کنندہ سے جواب پاتا ہے اور اسے غیر موجود سمجھتا ہے، اور خرابی کی عبارت میں DNS کا ذکر کبھی نہیں آتا۔

کچھ اور بدلنے سے پہلے ٹنل کے حل کنندہ سے براہ راست پوچھیں۔ پہلی دو کمانڈیں دکھاتی ہیں کہ Android نے فعال نیٹ ورک سے کون سے DNS سرور جوڑے اور Private DNS خودکار یا سخت موڈ میں ہے؛ تیسری فون سے نہیں بلکہ ٹنل کے اندر کسی بھی کلائنٹ سے چلتی ہے۔

adb shell dumpsys connectivity | grep -A3 "DnsAddresses"
adb shell settings get global private_dns_mode
nslookup -type=AAAA nas.lan 10.61.0.1

مرحلہ 2: پڑھیں کہ VpnService نے اصل میں کیا اعلان کیا

Android کا پہلو واضح ہے، اندازہ نہیں۔ VpnService.Builder addAddress سے پتے، addRoute سے راستے، addDnsServer سے DNS سرور شامل کرتا ہے، اور allowFamily سے پوری ٹنل کو ایک ہی پتہ خاندان تک محدود کر سکتا ہے۔ جس بلڈر نے allowFamily(AF_INET) بلایا اور بعد میں IPv6 راستہ شامل کیا، اس نے نظام کو دو متضاد باتیں بتائی ہیں، اور نظام خاندان کی پابندی ہی رکھتا ہے۔ fd00:61::/64 کو ڈھکنے والا راستہ کسی دوسرے سابقے میں موجود انٹرفیس پتے کے ساتھ مل کر اسی وجہ سے ناکام ہوتا ہے: پتہ موجود ہے، مگر اس راستے کے لیے on-link نہیں۔

ایپ کے ٹوگل پر بھروسا کرنے کی بجائے اعلان پڑھیں۔ dumpsys netd tun انٹرفیس سے جڑے پتے اور راستے چھاپتا ہے، اور dumpsys connectivity کے اندر فی نیٹ ورک LinkProperties نیٹ ورک کے دعوے کردہ خاندانوں کے ساتھ DNS فہرست دکھاتا ہے۔

adb shell ip -6 addr show tun0
adb shell ip -6 route show table all | grep tun0
adb shell dumpsys connectivity | grep -E "LinkAddresses|Routes"

اگر tun انٹرفیس پر IPv6 پتہ ہے مگر سروس کے سابقے سے کوئی راستہ نہیں ملتا، تو براؤزر آنے سے پہلے ہی IPv6 ترسیل ٹوٹی ہوئی ہے۔ یہ آزمانے سے انکار کرنے والے براؤزر سے مختلف خرابی ہے، اور اس کے لیے مختلف اصلاح چاہیے۔

مرحلہ 3: IPv6 آزمانا ہے یا نہیں، یہ براؤزر طے کرتا ہے

Chromium اپنے پاس آنے والا ہر AAAA ریکارڈ استعمال نہیں کرتا۔ اس کے ہوسٹ حل کنندہ میں IPv6 رسائی جانچ اور امیدوار چھانٹی ہے جو نیٹ ورک کو اسے اٹھانے سے قاصر سمجھے جانے پر IPv6 خارج کر سکتی ہے یا اس کی ترجیح کم کر سکتی ہے، اور حل کنندہ کا ماخذ وہ جانچ اس کے گرد شرائط کے ساتھ دکھاتا ہے۔ منطق ورژن اور جھنڈوں پر منحصر ہے، اور اسی وجہ سے ایک ہی ٹنل پر دو فون مختلف برتاؤ کر سکتے ہیں۔ امیدوار بن جانے کے بعد Happy Eyeballs ہر کنکشن کے لیے خاندانوں کو دوڑاتا ہے، اس لیے آہستہ جواب دینے والا IPv6 راستہ تیز جواب دینے والے IPv4 سے ہار سکتا ہے۔

فیصلے کا اندازہ لگانے کی بجائے اسے دیکھیں۔ chrome://net-export کے ذریعے ریکارڈ شدہ اور netlog ویور میں دوبارہ چلایا گیا سیشن ہر حل اور منتخب خاندان دکھاتا ہے؛ chrome://net-internals/#dns محفوظ شدہ نتائج دکھاتا ہے۔ آپ کے اپنے حل کنندہ پر AAAA والے نام کے لیے صرف A ریکارڈ واپس کرنے والا حل سیدھا اسی مرحلے کی طرف اشارہ کرتا ہے۔

مرحلہ 4: یقینی بنائیں کہ پیکٹ آنے جانے کا سفر کر سکتا ہے

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

adb shell ip -6 rule show
adb shell ip -6 route get fd00:61::20 from fd00:61::10

سوال کا جواب route get کا آؤٹ پٹ دیتا ہے۔ اگر یہ tun0 بتاتا ہے اور پیکٹ پھر بھی مرتے ہیں، تو فون کی طرف واپس جانے کی بجائے ٹنل کے MTU اور گیٹ وے کی IPv6 فارورڈنگ کی طرف جائیں۔

::/0 شامل کرنا عام طور پر مزید خراب کیوں کرتا ہے

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

پالیسی کی قیمت بھی ہے۔ ٹنل میں ::/0 ہونے پر سارا IPv6 ٹریفک VPN سے باہر جاتا ہے، وہ ٹریفک بھی جسے اٹھانے پر نیٹ ورک مالک نے کبھی رضامندی نہیں دی۔ اسے نامزد مالک والا تعیناتی فیصلہ سمجھیں، رات 1 بجے لیا جانے والا ڈیبگ قدم نہیں۔

وہ کام کی ترتیب جو اسے ختم کرتی ہے

یقینی بنائیں کہ AAAA جواب اسی حل کنندہ سے آتا ہے جس کے پاس زون ہے، tun انٹرفیس کے لیے VpnService اور netd کی حالت پڑھیں، Chromium نے امیدوار خارج کیا یا نہیں یہ دیکھنے کے لیے net-export نشان لیں، پھر ip -6 route get سے آنے جانے کی جانچ کریں۔ جس تہہ نے واقعی ناکامی دی اسے ٹھیک کریں اور تقسیمی پالیسی کو چھیڑیں نہیں۔ اگر نجی ناموں کو عوامی ناموں سے مختلف جواب چاہیے تو split tunneling اسی کے لیے ہے۔

فون کا build، براؤزر کا ورژن اور وہ حل کنندہ جس سے آپ نے پوچھا لکھ لیں۔ یہ تین حقائق "IPv6 is broken" کو ایسی چیز بنا دیتے ہیں جسے اگلا شخص دوبارہ پیدا کر سکے۔