Android-VPN køyrer IPv6, men nettlesaren vel framleis IPv4

VPN-et er oppe, det private webgrensesnittet svarar over IPv6 frå ein berbar PC, og Android-telefonen opnar framleis same side over IPv4 eller nektar å laste ho i det heile. AAAA-posten finst. Tunnelen rapporterer ei IPv6-adresse. Ingenting i klienten ser feil ut. Fire kvar for seg avgjerder avgjer resultatet: kva resolvar som svara, kva VpnService erklærte til Android, kva adressefamilie nettlesaren var viljug til å prøve, og om ein pakke klarar turen fram og tilbake. Ta dei i den rekkjefølgja i staden for å leggje til ei standardrute og håpe at symptomet flyttar seg.

Trinn 1: prov kva resolvar som svara på AAAA-spurnaden

Android har ikkje éin einaste DNS-veg. Eit VPN kan skuve ein DNS-server til nettverket sitt, systemet kan bruke Private DNS for vertsnamn det reknar som kvalifiserte, og Chrome kan køyre sin eigen krypterte resolvar frå chrome://settings/security. På ein telefon der tunnelen skuvar 10.61.0.1, men Private DNS peikar på ein offentleg leverandør, blir namnet i sona di ikkje slått opp av maskina som eig sona. Nettlesaren får eit svar frå ein resolvar utan myndigheit over namnet og handsamar det som manglande, og feilteksten nemner aldri DNS.

Spør resolvaren til tunnelen direkte før du endrar noko anna. Dei to første kommandoane viser kva DNS-serverar Android knytte til det aktive nettverket og om Private DNS er i automatisk eller streng modus; den tredje blir køyrd frå ein kvar klient inne i tunnelen, ikkje frå telefonen.

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

Trinn 2: les kva VpnService faktisk erklærte

Android-sida er eksplisitt og ikkje utleidd. Ein VpnService.Builder legg til adresser med addAddress, ruter med addRoute, DNS-serverar med addDnsServer, og kan avgrense heile tunnelen til éin adressefamilie med allowFamily. Ein byggjar som kalla allowFamily(AF_INET) og seinare la til ei IPv6-rute, har fortalt systemet to motstridande ting, og det er familierestriksjonen systemet held på. Ei rute som dekkjer fd00:61::/64 saman med ei grensesnittadresse i eit anna prefiks feilar av ein liknande grunn: adressa finst, men ho er ikkje on-link for den ruta.

Les fråsegna i staden for å stole på brytaren i appen. dumpsys netd skriv ut adressene og rutene som er knytte til tun-grensesnittet, og LinkProperties per nettverk i dumpsys connectivity viser DNS-lista ved sida av familiane nettverket hevdar.

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"

Viss tun-grensesnittet har ei IPv6-adresse, men inga rute svarar til prefikset til tenesta, er IPv6-leveransen allereie øydelagd før ein nettlesar er med. Det er ein annan feil enn ein nettlesar som nektar å prøve, og han krev ei anna retting.

Trinn 3: nettlesaren avgjer om han vil prøve IPv6 i det heile

Chromium brukar ikkje kvar AAAA-post han får. Vertsresolvaren har IPv6-rekkjeviddetestar og kandidatfiltrering som kan droppe eller nedprioritere IPv6 når nettverket blir vurdert som ute av stand til å bere det, og kjeldekoden til resolvaren viser den testen saman med vilkåra kring. Logikken avheng av versjon og flagg, og det er nettopp derfor to telefonar på same tunnel kan oppføre seg ulikt. Når kandidatane finst, lèt Happy Eyeballs familiane konkurrere per tilkopling, så ein IPv6-veg som svarar seint kan framleis tape mot IPv4 som svarar raskt.

Observer avgjerda i staden for å leie ho ut. Ei økt teken opp via chrome://net-export og spelt av i netlog-visaren viser kvar oppslagning og den valde familien; chrome://net-internals/#dns viser dei bufra resultata. Ei oppslagning som berre returnerer A-postar for eit namn som har AAAA hos din eigen resolvar, peikar rett på dette trinnet.

Trinn 4: stadfest at ein pakke klarar turen fram og tilbake

Adresseval er ikkje levering. Android held rutetabellar og policyreglar per nettverk som vel tabell etter fwmark, så ei rute som er synleg i hovudtabellen er ikkje automatisk den ruta ein socket brukar. Å lese reglane og be kjernen slå opp ein destinasjon for ei kjeldeadresse skil dei to.

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

Det er utdataa frå route get som svarar på spurnaden. Viss ho nemner tun0 og pakkane framleis døyr, gå til MTU-en til tunnelen og IPv6-vidaresendinga til gatewayen i staden for tilbake til telefonen.

Kvifor det å leggje til ::/0 vanlegvis gjer det verre

Å leggje til ::/0 endrar kravet til tunnelen frå eitt prefiks til kvar IPv6-destinasjon. På telefonen kan det tilfredsstille ein rekkjeviddetest, fordi ei testadresse utanfor prefikset ditt no ser rutbar ut. Det skapar ikkje IPv6-oppstraums kapasitet på gatewayen, og mange heimegatewayar har inga fungerande IPv6-oppstraumslinje i det heile. Resultatet er eit svart hol for offentleg IPv6: namn som før fall tilbake til IPv4 heng no, og den private sida kan sjå betre ut berre fordi testen måler noko anna.

Det er også ein politisk kostnad. Med ::/0 i tunnelen går all IPv6-trafikk ut gjennom VPN-et, òg trafikk netteigaren aldri har samtykt i å bere. Handsame det som ei utrullingavgjerd med ein namngjeven eigar, ikkje som eit feilsøkingstrinn du tek klokka 1 om natta.

Arbeidsrekkjefølgja som avsluttar dette

Stadfest at AAAA-svaret kjem frå resolvaren som eig sona, les VpnService- og netd-tilstand for tun-grensesnittet, tak opp eit net-export-spor for å sjå om Chromium droppa kandidaten, og test deretter turen fram og tilbake med ip -6 route get. Rett laget som faktisk feila, og lat splittpolitikken vere. Viss private namn treng andre svar enn offentlege, er det nettopp det split tunneling er til.

Noter bygget til telefonen, versjonen av nettlesaren og resolvaren du spurde. Dei tre fakta gjer "IPv6 is broken" til noko neste person kan reprodusere.