Android-VPN wurket mei IPv6, mar de browser kiest noch altyd IPv4

De VPN is oan, de privee webynterface antwurdet oer IPv6 fan in laptop, en de Android-tillefoan iepenet deselde side noch altyd oer IPv4 of wegeret dy hielendal te laden. It AAAA-record bestiet. De tunnel meldt in IPv6-adres. Neat yn 'e klient liket ferkeard. Fjouwer aparte besluten bepale de útkomst: hokker resolver antwurde, wat de VpnService oan Android ferklearre, hokker adresfamylje de browser ree wie om te besykjen, en oft in pakket de hin-en-wer reis meitsje kin. Wurkje se yn dy folchoarder ôf yn plak fan in standertrûte ta te foegjen en te hoopjen dat it symptoom ferpleatst.

Stap 1: bewize hokker resolver de AAAA-fraach beantwurde

Android hat net ien DNS-paad. In VPN kin in DNS-tsjinner foar syn netwurk triuwe, it systeem kin Private DNS brûke foar hostnammen dy't it geskikt achtet, en Chrome kin syn eigen fersifere resolver draaie fan chrome://settings/security ôf. Op in tillefoan wêr't de tunnel 10.61.0.1 triuwt mar Private DNS nei in iepenbiere oanbieder wiist, wurdt de namme yn jo privee sône net oplost troch de masine dy't de sône besit. De browser krijt in antwurd fan in resolver sûnder gesach oer dy namme en behannelet it as ûntbrekkend, en de flertekst neamt DNS nea.

Freegje de resolver fan 'e tunnel direkt foardat jo eat oars feroarje. De earste twa opdrachten litte sjen hokker DNS-tsjinners Android oan it aktive netwurk keppele hat en oft Private DNS yn automatyske of strikte modus is; de tredde rint fan elke klient binnen de tunnel, net fan 'e tillefoan.

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

Stap 2: lês wat de VpnService eins ferklearre

De Android-kant is eksplisyt en net ôflaat. In VpnService.Builder foeget adressen ta mei addAddress, rûtes mei addRoute, DNS-tsjinners mei addDnsServer, en kin de hiele tunnel beheine ta ien adresfamylje mei allowFamily. In bouwer dy't allowFamily(AF_INET) oanrôp en letter in IPv6-rûte tafoege, hat it systeem twa tsjinstridige dingen ferteld, en de famyljebeheining is wat it systeem hâldt. In rûte dy't fd00:61::/64 beslacht yn kombinaasje mei in ynterface-adres yn in oar prefiks mislearret om in ferlykbere reden: it adres bestiet, mar it is net on-link foar dy rûte.

Lês de ferklearring yn plak fan de skeakel yn 'e app te fertrouwen. dumpsys netd printsje de adressen en rûtes dy't oan 'e tun-ynterface keppele binne, en de per-netwurk LinkProperties yn dumpsys connectivity toant de DNS-list neist de famyljes dy't it netwurk beweart.

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"

As de tun-ynterface in IPv6-adres hat mar gjin rûte oerienkomt mei it prefiks fan 'e tsjinst, is IPv6-levering al stikken foardat in browser der by belutsen is. Dat is in oare bug as in browser dy't wegeret te besykjen, en it freget in oare oplossing.

Stap 3: de browser beslút oft er IPv6 besykje sil

Chromium brûkt net elk AAAA-record dat it krijt. Syn hostresolver hat IPv6-berikberenskoppen en kandidaatfiltering dy't IPv6 falle of degradeare kinne as it netwurk as net by steat beoardiele wurdt om it te dragen, en de resolverboarne toant dy probe tegearre mei de betingsten deromhinne. De logika hinget ôf fan ferzje en flaggen, en dêrom kinne twa tillefoans op deselde tunnel har oars gedrage. Sadree't kandidaten besteane, lit Happy Eyeballs de famyljes per ferbining race, sadat in IPv6-paad dat stadich antwurdet noch altyd ferlieze kin fan IPv4 dat fluch antwurdet.

Besjoch it beslút yn plak fan it ôf te lieden. In sesje opnommen fia chrome://net-export en ôfspile yn 'e netlog-werjefte toant elke oplossing en de keazen famylje; chrome://net-internals/#dns toant de cachede resultaten. In oplossing dy't allinnich A-records werombringt foar in namme dy't AAAA hat by jo eigen resolver wiist direkt nei dizze faze.

Stap 4: ferifiearje dat in pakket de hin-en-wer reis meitsje kin

Adreskar is gjin levering. Android hâldt per-netwurk rûtearringstabellen en beliedsregels dy't in tabel kieze op fwmark, dus in rûte sichtber yn 'e haadtabel is net automatysk de rûte dy't in socket brûkt. Regels lêze en it kearn freegje om in bestimming foar in boarne-adres op te lossen skiedt dy twa.

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

De útfier fan route get is dejinge dy't de fraach beantwurdet. As it tun0 neamt en pakketten stjerre noch altyd, gean dan nei de MTU fan 'e tunnel en it IPv6-trochstjoeren fan 'e gateway yn plak fan werom nei de tillefoan.

Wêrom't it tafoegjen fan ::/0 it meastentiids slimmer makket

It tafoegjen fan ::/0 feroaret de oanspraak fan 'e tunnel fan ien prefiks nei elk IPv6-bestimming. Op 'e tillefoan kin dat in berikberensprobe befredigje, om't in testadres bûten jo prefiks no rûteber liket. It makket gjin IPv6-opstreamkapasiteit op 'e gateway, en in protte hûsgateways hawwe hielendal gjin wurkjende IPv6-opstreamferbining. It resultaat is in swart gat foar iepenbier IPv6: nammen dy't earder weromfoelen nei IPv4 hingje no, en de privee side kin better lykje allinnich om't de probe eat oars mjit.

Der is ek in beliedskosten. Mei ::/0 yn 'e tunnel ferlit alle IPv6-ferkear it netwurk fia de VPN, ynklusyf ferkear dat de netwurkeigenaar nea akseptearre hat om te dragen. Behannelje dat as in útrôlbeslút mei in neamde eigner, net as in debugstap dy't jo om 1 oere nachts nimme.

De wurkfolchoarder dy't dit einiget

Befêstigje dat it AAAA-antwurd fan 'e resolver komt dy't de sône hâldt, lês de VpnService- en netd-steat foar de tun-ynterface, meitsje in net-export-spoar om te sjen oft Chromium de kandidaat falle liet, en test dan de hin-en-wer reis mei ip -6 route get. Reparearje de laach dy't echt mislearre en lit it splitbelied gewurde. As privee nammen oare antwurden nedich hawwe as iepenbiere, dêr is split tunneling foar.

Notearje de build fan 'e tillefoan, de ferzje fan 'e browser en de resolver dy't jo fregen. Dy trije feiten meitsje "IPv6 is broken" ta eat dat de folgjende persoan reprodusearje kin.