په Android کې VPN له IPv6 سره کار کوي، خو براوزر لا هم IPv4 غوره کوي

VPN فعال دی، شخصي ویب انٹرفیس له لیپ ټاپ څخه د IPv6 له لارې ځواب ورکوي، او Android ټیلیفون لا هم هماغه پاڼه د IPv4 له لارې پرانیزي یا په بشپړ ډول یې له لوډ کولو څخه انکار کوي. د AAAA ریکارډ شته. ټنل د IPv6 پته راپور کوي. په کلاینت کې هیڅ شی غلط نه ښکاري. نتیجې ته څلور جلا پریکړې ټاکي: کوم حل کوونکي ځواب ورکړ، VpnService اندرویډ ته څه اعلان کړل، براوزر کوم د پتو کورنۍ ازمویلو ته چمتو و، او ایا یو پاکټ کولی شي د تلو او راتلو سفر وکړي. د دې پرځای چې ډیفالټ لاره اضافه کړئ او هيله وکړئ چې نښه به ځای بدل کړي، په همدې ترتیب سره ورسره کار وکړئ.

ګام 1: ثابته کړئ چې کوم حل کوونکي د AAAA پوښتنې ځواب ورکړ

اندرویډ یوازې یوه DNS لاره نه لري. VPN کولی شي د خپل شبکې لپاره DNS سرور ورته وټېله کړي، سیستم کولی شي هغو هوسټ نومونو لپاره چې وړ یې بولي Private DNS وکاروي، او Chrome کولی شي خپل کوډ شوی حل کوونکی له chrome://settings/security څخه چل کړي. په هغه ټیلیفون کې چې ټنل 10.61.0.1 ټېله کوي خو Private DNS یو عامه چمتو کوونکي ته اشاره کوي، ستاسو په شخصي زون کې دننه نوم هغه ماشین نه حل کوي چې زون لري. براوزر له هغه حل کوونکي څخه ځواب ترلاسه کوي چې پر دې نوم واک نه لري او هغه ورک ګڼي، او د غلطۍ متن کله هم DNS ته اشاره نه کوي.

له هر بل بدلون څخه دمخه د ټنل له حل کوونکي څخه مستقیم وپوښتئ. لومړني دوه کمانډونه ښیي چې اندرویډ فعالې شبکې ته کوم 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 په رښتیا څه اعلان کړل

د اندرویډ خوا څرګنده ده نه اټکل شوې. VpnService.Builder پتې د addAddress له لارې، لارې د addRoute له لارې، DNS سرورونه د addDnsServer له لارې اضافه کوي، او کولی شي ټول ټنل د 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: وګورئ چې پاکټ کولی شي د تلو او راتلو سفر وکړي

د پتې غوره کول رسول نه دي. اندرویډ د هرې شبکې لپاره د لارښوونې جدولونه او د پالیسۍ قواعد ساتي چې جدول د 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 حالت ولولئ، د net-export نښه واخلئ ترڅو وګورئ چې Chromium کاندید وباسه، بیا د ip -6 route get په مرسته د تلو او راتلو ازموینه وکړئ. هغه طبقه سمه کړئ چې واقعاً ناکامه شوې او د ویش پالیسۍ ته لاس مه وروړئ. که شخصي نومونو ته له عامه نومونو بېل ځوابونه ته اړتیا وي، split tunneling همدې لپاره دی.

د ټیلیفون build، د براوزر نسخه او هغه حل کوونکی چې تاسو ترې پوښتلی ولیکئ. هغه درې حقایق "IPv6 is broken" په داسې شي بدلوي چې بل کس یې بیا تولید کولی شي.