Android-VPN funkcias per IPv6, sed la retumilo ankoraŭ elektas IPv4

La VPN funkcias, la privata retinterfaco respondas per IPv6 de tekkomputilo, kaj la Android-telefono ankoraŭ malfermas la saman paĝon per IPv4 aŭ tute rifuzas ŝargi ĝin. La AAAA-rikordo ekzistas. La tunelo raportas IPv6-adreson. Nenio en la kliento ŝajnas malĝusta. Kvar apartaj decidoj difinas la rezulton: kiu solvilo respondis, kion VpnService deklaris al Android, kiun adresan familion la retumilo pretis provi, kaj ĉu paketo povas fari la vojaĝon tien kaj reen. Laboru laŭ tiu ordo anstataŭ aldoni implican vojon kaj esperi, ke la simptomo moviĝos.

Paŝo 1: pruvu, kiu solvilo respondis la AAAA-demandon

Android ne havas ununuran DNS-vojon. VPN povas puŝi DNS-servilon por sia reto, la sistemo povas uzi Private DNS por gastnomoj, kiujn ĝi juĝas taŭgaj, kaj Chrome povas funkciigi sian propran ĉifritan solvilon de chrome://settings/security. Sur telefono, kie la tunelo puŝas 10.61.0.1 sed Private DNS montras al publika provizanto, la nomo en via privata zono ne estas solvata de la maŝino, kiu posedas la zonon. La retumilo ricevas respondon de solvilo sen aŭtoritato pri tiu nomo kaj traktas ĝin kiel mankantan, kaj la erarteksto neniam mencias DNS.

Demandu rekte la solvilon de la tunelo antaŭ ol ŝanĝi ion alian. La unuaj du komandoj montras, kiujn DNS-servilojn Android ligis al la aktiva reto kaj ĉu Private DNS estas en aŭtomata aŭ strikta reĝimo; la tria ruliĝas de iu ajn kliento ene de la tunelo, ne de la telefono.

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

Paŝo 2: legu, kion VpnService efektive deklaris

La Android-flanko estas eksplicita, ne deduktita. VpnService.Builder aldonas adresojn per addAddress, vojojn per addRoute, DNS-servilojn per addDnsServer, kaj povas limigi la tutan tunelon al unu adresa familio per allowFamily. Konstruanto, kiu vokis allowFamily(AF_INET) kaj poste aldonis IPv6-vojon, diris al la sistemo du kontraŭajn aferojn, kaj la familia limigo estas tio, kion la sistemo retenas. Vojo kovranta fd00:61::/64 kune kun interfaca adreso en alia prefikso malsukcesas pro simila kialo: la adreso ekzistas, sed ĝi ne estas on-link por tiu vojo.

Legu la deklaron anstataŭ fidi la ŝaltilon en la aplikaĵo. dumpsys netd presas la adresojn kaj vojojn ligitajn al la tun-interfaco, kaj la laŭreta LinkProperties en dumpsys connectivity montras la DNS-liston apud la familioj, kiujn la reto asertas.

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"

Se la tun-interfaco havas IPv6-adreson sed neniu vojo kongruas kun la prefikso de la servo, IPv6-liverado jam rompiĝis antaŭ ol retumilo enmiksiĝas. Tio estas alia cimo ol retumilo, kiu rifuzas provi, kaj ĝi bezonas alian riparon.

Paŝo 3: la retumilo decidas, ĉu entute provi IPv6

Chromium ne uzas ĉiun AAAA-rikordon, kiun ĝi ricevas. Ĝia gastnom-solvilo portas IPv6-atingeblec-kontrolojn kaj kandidatfiltradon, kiuj povas forigi aŭ malaltigi IPv6, kiam la reto estas juĝata nekapabla porti ĝin, kaj la fontkodo de la solvilo montras tiun kontrolon kune kun la kondiĉoj ĉirkaŭ ĝi. La logiko dependas de versio kaj flagoj, kaj ĝuste tial du telefonoj en la sama tunelo povas konduti malsame. Post kiam kandidatoj ekzistas, Happy Eyeballs igas la familiojn konkuri por ĉiu konekto, do IPv6-vojo, kiu respondas malrapide, ankoraŭ povas perdi kontraŭ IPv4, kiu respondas rapide.

Observu la decidon anstataŭ dedukti ĝin. Sesio registrita per chrome://net-export kaj reludita en la netlog-rigardilo montras ĉiun solvon kaj la elektitan familion; chrome://net-internals/#dns montras la kaŝmemorigitajn rezultojn. Solvo, kiu redonas nur A-rikordojn por nomo, kiu havas AAAA ĉe via propra solvilo, montras rekte al ĉi tiu etapo.

Paŝo 4: kontrolu, ke paketo povas fari la vojaĝon tien kaj reen

Adresa elekto ne estas liverado. Android tenas laŭretajn enkursigajn tabelojn kaj politikajn regulojn, kiuj elektas tabelon laŭ fwmark, do vojo videbla en la ĉefa tabelo ne aŭtomate estas la vojo, kiun uzas poŝo. Legi la regulojn kaj peti la kernon solvi celon por fonta adreso apartigas la du.

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

La eligo de route get estas tiu, kiu respondas la demandon. Se ĝi nomas tun0 kaj pakaĵoj ankoraŭ mortas, iru al la MTU de la tunelo kaj al la IPv6-plusendado de la enirejo anstataŭ reen al la telefono.

Kial aldoni ::/0 kutime plimalbonigas ĝin

Aldoni ::/0 ŝanĝas la postulon de la tunelo de unu prefikso al ĉiu IPv6-celo. Sur la telefono tio povas kontentigi atingeblec-kontrolon, ĉar testa adreso ekster via prefikso nun ŝajnas enkursigebla. Ĝi ne kreas IPv6-alflu-kapaciton ĉe la enirejo, kaj multaj hejmaj enirejoj tute ne havas funkciantan IPv6-alfluon. La rezulto estas nigra truo por publika IPv6: nomoj, kiuj antaŭe refalis al IPv4, nun pendas, kaj la privata paĝo eble aspektas pli bone nur ĉar la kontrolo mezuras ion alian.

Estas ankaŭ politika kosto. Kun ::/0 en la tunelo, la tuta IPv6-trafiko eliras tra la VPN, inkluzive de trafiko, kiun la retposedanto neniam konsentis porti. Traktu tion kiel enkondukan decidon kun nomita posedanto, ne kiel sencimigan paŝon, kiun vi faras je la 1-a nokte.

La laborordo, kiu finas ĉi tion

Konfirmu, ke la AAAA-respondo venas de la solvilo, kiu tenas la zonon, legu la staton de VpnService kaj netd por la tun-interfaco, kaptu net-export-spuron por vidi, ĉu Chromium forĵetis la kandidaton, poste testu la vojaĝon tien kaj reen per ip -6 route get. Riparu la tavolon, kiu efektive malsukcesis, kaj lasu la disigan politikon trankvila. Se privataj nomoj bezonas aliajn respondojn ol publikaj, ĝuste por tio ekzistas split tunneling.

Notu la konstruaĵon de la telefono, la version de la retumilo kaj la solvilon, kiun vi demandis. Tiuj tri faktoj transformas "IPv6 is broken" en ion, kion la sekva persono povas reprodukti.