Gumagana sa IPv6 ang VPN sa Android, pero IPv4 pa rin ang pinipili ng browser

Aktibo ang VPN, sumasagot ang pribadong web UI sa IPv6 mula sa laptop, at binubuksan pa rin ng Android phone ang parehong pahina sa IPv4 o tumatanggi itong i-load. Umiiral ang AAAA record. Nag-uulat ng IPv6 address ang tunnel. Walang mukhang mali sa client. Apat na magkakahiwalay na desisyon ang nagtatakda ng resulta: aling resolver ang sumagot, ano ang idineklara ng VpnService sa Android, aling pamilya ng address ang handang subukan ng browser at kung kayang gawin ng packet ang paglalakbay pabalik-balik. Gawin ang mga ito sa ayos na iyon sa halip na magdagdag ng default route at umasang gagalaw ang sintomas.

Hakbang 1: patunayang aling resolver ang sumagot sa AAAA query

Walang iisang DNS path ang Android. Maaaring itulak ng VPN ang isang DNS server para sa network nito, maaaring gumamit ang system ng Private DNS para sa mga hostname na itinuturing nitong karapat-dapat, at maaaring patakbuhin ng Chrome ang sarili nitong naka-encrypt na resolver mula sa chrome://settings/security. Sa teleponong itinutulak ng tunnel ang 10.61.0.1 ngunit tumuturo ang Private DNS sa isang pampublikong provider, ang pangalan sa loob ng pribadong zone mo ay hindi nire-resolve ng makinang nagmamay-ari ng zone. Nakakakuha ang browser ng sagot mula sa resolver na walang awtoridad sa pangalang iyon at itinuturing itong wala, at hindi kailanman binabanggit ng teksto ng error ang DNS.

Tanungin nang direkta ang resolver ng tunnel bago magbago ng kahit ano. Ipinapakita ng unang dalawang utos kung aling DNS server ang ikinabit ng Android sa aktibong network at kung ang Private DNS ay nasa awtomatiko o mahigpit na mode; ang pangatlo ay tumatakbo mula sa alinmang client sa loob ng tunnel, hindi mula sa telepono.

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

Hakbang 2: basahin kung ano talaga ang idineklara ng VpnService

Ang panig ng Android ay tahasan at hindi hinulaan. Ang VpnService.Builder ay nagdadagdag ng address gamit ang addAddress, ruta gamit ang addRoute, DNS server gamit ang addDnsServer, at maaaring limitahan ang buong tunnel sa isang pamilya ng address gamit ang allowFamily. Ang builder na tumawag sa allowFamily(AF_INET) at pagkatapos ay nagdagdag ng IPv6 route ay nagsabi sa system ng dalawang magkasalungat na bagay, at ang paghihigpit sa pamilya ang pinapanatili ng system. Ang rutang sumasaklaw sa fd00:61::/64 kasama ng interface address sa ibang prefix ay nabibigo sa katulad na dahilan: umiiral ang address, ngunit hindi ito on-link para sa rutang iyon.

Basahin ang deklarasyon sa halip na magtiwala sa toggle sa app. Ipiniprint ng dumpsys netd ang mga address at rutang nakakabit sa interface ng tun, at ipinapakita ng LinkProperties bawat network sa loob ng dumpsys connectivity ang listahan ng DNS sa tabi ng mga pamilyang inaangkin ng network.

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"

Kung may IPv6 address ang interface ng tun ngunit walang rutang tumutugma sa prefix ng serbisyo, sira na ang paghahatid ng IPv6 bago pa pumasok ang browser. Ibang bug ito kaysa sa browser na tumatangging subukan, at ibang pagwawasto ang kailangan.

Hakbang 3: ang browser ang nagpapasya kung susubukan ang IPv6

Hindi ginagamit ng Chromium ang bawat AAAA record na natatanggap nito. May dalang IPv6 reachability checks at candidate filtering ang host resolver nito na maaaring magtapon o magpababa ng priyoridad ng IPv6 kapag hinuhusgahang hindi kaya ng network na dalhin ito, at ipinapakita ng source ng resolver ang probe na iyon kasama ng mga kondisyon sa paligid nito. Nakadepende ang lohika sa bersyon at mga flag, at iyon mismo ang dahilan kung bakit dalawang telepono sa isang tunnel ay maaaring magkaibang umasal. Kapag may mga kandidato na, pinapagpatimpalak ng Happy Eyeballs ang mga pamilya kada koneksyon, kaya ang IPv6 path na mabagal sumagot ay maaari pa ring matalo sa IPv4 na mabilis sumagot.

Pagmasdan ang desisyon sa halip na hulaan ito. Ang session na naitala sa pamamagitan ng chrome://net-export at na-play muli sa netlog viewer ay nagpapakita ng bawat resolution at ng napiling pamilya; ipinapakita ng chrome://net-internals/#dns ang mga naka-cache na resulta. Ang resolution na nagbabalik lamang ng A record para sa pangalang may AAAA sa sarili mong resolver ay direktang tumuturo sa yugtong ito.

Hakbang 4: tiyakin na kayang gawin ng packet ang paglalakbay pabalik-balik

Ang pagpili ng address ay hindi paghahatid. Nagtatago ang Android ng routing table at policy rule kada network na pumipili ng table ayon sa fwmark, kaya ang rutang nakikita sa pangunahing table ay hindi awtomatikong ang rutang ginagamit ng socket. Ang pagbasa ng mga rule at paghiling sa kernel na i-resolve ang destinasyon para sa source address ay naghihiwalay sa dalawa.

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

Ang output ng route get ang sumasagot sa tanong. Kung pinapangalanan nito ang tun0 at namamatay pa rin ang mga packet, pumunta sa MTU ng tunnel at sa IPv6 forwarding ng gateway sa halip na bumalik sa telepono.

Bakit karaniwang pinapalala ng pagdaragdag ng ::/0

Binabago ng pagdaragdag ng ::/0 ang claim ng tunnel mula sa isang prefix tungo sa bawat destinasyong IPv6. Sa telepono, matutugunan nito ang isang reachability probe, dahil ang test address sa labas ng prefix mo ay mukhang maruruta na ngayon. Hindi ito lumilikha ng IPv6 upstream capacity sa gateway, at maraming home gateway ang walang gumaganang IPv6 uplink. Ang resulta ay black hole para sa pampublikong IPv6: ang mga pangalang dating bumabalik sa IPv4 ay nakabitin na ngayon, at ang pribadong pahina ay maaaring mukhang mas mahusay dahil lamang sa ibang bagay ang sinusukat ng probe.

May halaga rin sa patakaran. Sa ::/0 sa tunnel, lahat ng IPv6 traffic ay lumalabas sa VPN, kasama ang traffic na hindi kailanman sinang-ayunan ng may-ari ng network na dalhin. Ituring itong desisyon sa deployment na may pinangalanang may-ari, hindi bilang hakbang sa pag-debug na ginagawa mo nang 1 ng madaling araw.

Ang pagkakasunod-sunod ng trabaho na magtatapos nito

Kumpirmahin na ang sagot ng AAAA ay nagmumula sa resolver na may hawak ng zone, basahin ang estado ng VpnService at netd para sa interface ng tun, kumuha ng net-export trace para makita kung itinapon ng Chromium ang kandidato, pagkatapos ay subukan ang paglalakbay pabalik-balik gamit ang ip -6 route get. Ayusin ang layer na talagang nabigo at hayaan ang split policy. Kung kailangan ng mga pribadong pangalan ng ibang sagot kaysa sa mga pampubliko, para doon ang split tunneling.

Itala ang build ng telepono, bersyon ng browser at resolver na tinanong mo. Ang tatlong katotohanang iyon ay ginagawang isang bagay na maaaring muling gawin ng susunod na tao ang "IPv6 is broken".