VPN v Androidu deluje prek IPv6, a brskalnik vseeno izbere IPv4

VPN je vklopljen, zasebni spletni vmesnik odgovarja prek IPv6 s prenosnika, telefon Android pa še vedno odpira isto stran prek IPv4 ali je sploh noče naložiti. Zapis AAAA obstaja. Tunel poroča naslov IPv6. V odjemalcu nič ne izgleda narobe. Izid določajo štiri ločene odločitve: kateri resolver je odgovoril, kaj je VpnService deklariral Androidu, katero družino naslovov je bil brskalnik pripravljen preizkusiti in ali lahko paket opravi pot tja in nazaj. Obravnavajte jih v tem vrstnem redu, namesto da dodate privzeto pot in upate, da se bo simptom premaknil.

Korak 1: dokažite, kateri resolver je odgovoril na poizvedbo AAAA

Android nima ene same poti DNS. VPN lahko potisne strežnik DNS za svoje omrežje, sistem lahko uporabi Private DNS za imena gostiteljev, ki jih šteje za ustrezna, Chrome pa lahko zažene svoj šifrirani resolver iz chrome://settings/security. Na telefonu, kjer tunel potisne 10.61.0.1, a Private DNS kaže na javnega ponudnika, imena v vašem zasebnem območju ne razreši stroj, ki ima območje v lasti. Brskalnik dobi odgovor od resolverja brez pristojnosti za to ime in ga obravnava kot manjkajočega, besedilo napake pa DNS nikoli ne omeni.

Vprašajte resolver tunela neposredno, preden karkoli drugega spremenite. Prva dva ukaza pokažeta, katere strežnike DNS je Android pripnel aktivnemu omrežju in ali je Private DNS v samodejnem ali strogem načinu; tretji se izvaja s katerega koli odjemalca znotraj tunela, ne s telefona.

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

Korak 2: preberite, kaj je VpnService dejansko deklariral

Stran Androida je izrecna, ne izpeljana. VpnService.Builder doda naslove z addAddress, poti z addRoute, strežnike DNS z addDnsServer in lahko omeji celoten tunel na eno družino naslovov z allowFamily. Graditelj, ki je poklical allowFamily(AF_INET) in pozneje dodal pot IPv6, je sistemu povedal dve nasprotujoči si stvari, sistem pa obdrži omejitev družine. Pot, ki pokriva fd00:61::/64, skupaj z naslovom vmesnika v drugem predponi spodleti iz podobnega razloga: naslov obstaja, vendar ni on-link za to pot.

Berite izjavo, namesto da zaupate stikalu v aplikaciji. dumpsys netd izpiše naslove in poti, pripete vmesniku tun, LinkProperties za vsako omrežje v dumpsys connectivity pa prikaže seznam DNS ob družinah, ki jih omrežje zatrjuje.

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"

Če ima vmesnik tun naslov IPv6, a nobena pot ne ustreza predponi storitve, je dostava IPv6 že pokvarjena, preden se vključi brskalnik. To je drugačna napaka kot pri brskalniku, ki noče poskusiti, in zahteva drugačen popravek.

Korak 3: brskalnik odloči, ali bo sploh poskusil IPv6

Chromium ne uporabi vsakega prejetega zapisa AAAA. Njegov resolver gostiteljev nosi preverjanja dosegljivosti IPv6 in filtriranje kandidatov, ki lahko IPv6 zavržeta ali mu znižata prednost, ko je omrežje ocenjeno kot nesposobno, da bi ga prenašalo, in izvorna koda resolverja prikazuje to preverjanje skupaj s pogoji okoli njega. Logika je odvisna od različice in zastavic, in prav zato se lahko dva telefona na istem tunelu obnašata različno. Ko kandidati obstajajo, Happy Eyeballs spusti družine v tekmo za vsako povezavo, zato lahko pot IPv6, ki odgovarja počasi, še vedno izgubi proti IPv4, ki odgovarja hitro.

Opazujte odločitev, namesto da jo izpeljujete. Seja, posneta prek chrome://net-export in predvajana v pregledovalniku netlog, prikaže vsako razrešitev in izbrano družino; chrome://net-internals/#dns prikaže predpomnjene rezultate. Razrešitev, ki za ime z AAAA na vašem lastnem resolverju vrne le zapise A, kaže neposredno na to stopnjo.

Korak 4: preverite, ali lahko paket opravi pot tja in nazaj

Izbira naslova ni dostava. Android hrani usmerjevalne tabele in pravila politik za vsako omrežje, ki izberejo tabelo po fwmarku, zato pot, vidna v glavni tabeli, ni samodejno tista, ki jo uporablja vtičnica. Branje pravil in prošnja jedra, naj razreši cilj za izvorni naslov, loči to dvoje.

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

Prav izhod route get odgovori na vprašanje. Če navaja tun0 in paketi še vedno umirajo, pojdite na MTU tunela in posredovanje IPv6 na prehodu, ne pa nazaj na telefon.

Zakaj dodajanje ::/0 običajno poslabša stanje

Dodajanje ::/0 spremeni zahtevek tunela iz ene predpone v vsak cilj IPv6. V telefonu lahko to zadovolji preverjanje dosegljivosti, ker je preskusni naslov zunaj vaše predpone zdaj videti usmerljiv. Ne ustvari pa zmogljivosti IPv6 navzgor na prehodu, in veliko domačih prehodov sploh nima delujoče povezave IPv6 navzgor. Rezultat je črna luknja za javni IPv6: imena, ki so prej padla nazaj na IPv4, zdaj visijo, zasebna stran pa je lahko videti bolje le zato, ker preverjanje meri nekaj drugega.

Obstaja tudi cena za politiko. Z ::/0 v tunelu vsa komunikacija IPv6 odide skozi VPN, vključno s prometom, ki ga lastnik omrežja ni nikoli privolil prenašati. Obravnavajte to kot odločitev o uvedbi z imenovanim lastnikom, ne kot korak razhroščevanja ob 1 uri zjutraj.

Vrstni red dela, ki to zaključi

Potrdite, da odgovor AAAA prihaja od resolverja, ki ima območje, preberite stanje VpnService in netd za vmesnik tun, zajemite sled net-export, da vidite, ali je Chromium kandidata zavrgel, nato preizkusite pot tja in nazaj z ip -6 route get. Popravite plast, ki je res spodletela, in politiko razdelitve pustite pri miru. Če zasebna imena potrebujejo drugačne odgovore kot javna, je split tunneling namenjen prav temu.

Zapišite build telefona, različico brskalnika in resolver, ki ste ga povprašali. Ta tri dejstva spremenijo "IPv6 is broken" v nekaj, kar lahko naslednja oseba ponovi.