Android VPN radi s IPv6, no preglednik i dalje odabire IPv4

VPN je aktivan, privatno web sučelje odgovara preko IPv6 s prijenosnog računala, a Android telefon i dalje otvara istu stranicu preko IPv4 ili ju uopće odbija učitati. AAAA zapis postoji. Tunel prijavljuje IPv6 adresu. Ništa u klijentu ne izgleda pogrešno. Ishod određuju četiri odvojene odluke: koji je resolver odgovorio, što je VpnService deklarirao Androidu, koju je obitelj adresa preglednik bio spreman isprobati i može li paket napraviti put tamo i natrag. Obradite ih tim slijedom umjesto da dodate zadanu rutu i nadate se da će se simptom pomaknuti.

Korak 1: dokažite koji je resolver odgovorio na AAAA upit

Android nema jedinstven put za DNS. VPN može progurati DNS poslužitelj za svoju mrežu, sustav može koristiti Private DNS za imena hostova koja smatra kvalificiranima, a Chrome može pokretati vlastiti šifrirani resolver s chrome://settings/security. Na telefonu na kojem tunel progura 10.61.0.1, ali Private DNS pokazuje na javnog davatelja, ime unutar vaše privatne zone ne razrješava stroj koji posjeduje zonu. Preglednik dobiva odgovor od resolvera bez ovlasti za to ime i tretira ga kao da nedostaje, a tekst pogreške nikad ne spominje DNS.

Pitajte resolver tunela izravno prije nego što promijenite bilo što drugo. Prve dvije naredbe pokazuju koje je DNS poslužitelje Android pridružio aktivnoj mreži i je li Private DNS u automatskom ili strogom načinu rada; treća se izvršava s bilo kojeg klijenta unutar tunela, a 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: pročitajte što je VpnService doista deklarirao

Android strana je izričita, a ne izvedena. VpnService.Builder dodaje adrese pomoću addAddress, rute pomoću addRoute, DNS poslužitelje pomoću addDnsServer i može ograničiti cijeli tunel na jednu obitelj adresa pomoću allowFamily. Graditelj koji je pozvao allowFamily(AF_INET) i poslije dodao IPv6 rutu rekao je sustavu dvije proturječne stvari, a sustav zadržava ograničenje obitelji. Ruta koja pokriva fd00:61::/64 u kombinaciji s adresom sučelja u drugom prefiksu ne uspijeva iz sličnog razloga: adresa postoji, ali nije on-link za tu rutu.

Čitajte deklaraciju umjesto da vjerujete prekidaču u aplikaciji. dumpsys netd ispisuje adrese i rute pridružene sučelju tun, a LinkProperties po mreži unutar dumpsys connectivity pokazuje DNS popis uz obitelji koje mreža tvrdi.

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"

Ako sučelje tun ima IPv6 adresu, ali nijedna ruta ne odgovara prefiksu usluge, dostava IPv6 već je pokvarena prije nego što se preglednik uključi. To je drugačija greška od preglednika koji odbija pokušati i traži drugačiji popravak.

Korak 3: preglednik odlučuje hoće li uopće pokušati s IPv6

Chromium ne koristi svaki AAAA zapis koji primi. Njegov resolver hostova nosi provjere dostupnosti IPv6 i filtriranje kandidata koji mogu odbaciti ili sniziti prioritet IPv6 kada se mreža procijeni nesposobnom da ga nosi, a izvorni kod resolvera pokazuje tu provjeru zajedno s uvjetima oko nje. Logika ovisi o verziji i zastavicama, što je upravo razlog zašto se dva telefona na istom tunelu mogu ponašati različito. Kad kandidati postoje, Happy Eyeballs vodi utrku obitelji za svaku vezu, pa IPv6 put koji odgovara sporo ipak može izgubiti od IPv4 koji odgovara brzo.

Promatrajte odluku umjesto da je izvedete. Sesija snimljena kroz chrome://net-export i reproducirana u pregledniku netlog pokazuje svako razrješavanje i odabranu obitelj; chrome://net-internals/#dns pokazuje predmemorirane rezultate. Razrješavanje koje vraća samo A zapise za ime koje ima AAAA na vašem resolveru izravno ukazuje na ovu fazu.

Korak 4: provjerite može li paket napraviti put tamo i natrag

Odabir adrese nije dostava. Android drži tablice usmjeravanja i pravila politike po mreži koji odabiru tablicu po fwmark, pa ruta vidljiva u glavnoj tablici nije automatski ruta koju koristi socket. Čitanje pravila i traženje da jezgra razriješi odredište za izvornu adresu razdvaja to dvoje.

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

Izlaz naredbe route get je onaj koji odgovara na pitanje. Ako imenuje tun0, a paketi i dalje ginu, prijeđite na MTU tunela i IPv6 prosljeđivanje na pristupniku, umjesto natrag na telefon.

Zašto dodavanje ::/0 obično pogoršava stvar

Dodavanje ::/0 mijenja tvrdnju tunela s jednog prefiksa na svako IPv6 odredište. Na telefonu to može zadovoljiti provjeru dostupnosti jer testna adresa izvan vašeg prefiksa sada izgleda usmjerivo. To ne stvara IPv6 uzvodni kapacitet na pristupniku, a mnogi kućni pristupnici uopće nemaju radni IPv6 uzlazni link. Rezultat je crna rupa za javni IPv6: imena koja su se prije vraćala na IPv4 sada vise, a privatna stranica može izgledati bolje samo zato što provjera mjeri nešto drugo.

Postoji i cijena za politiku. S ::/0 u tunelu sav IPv6 promet izlazi kroz VPN, uključujući promet koji vlasnik mreže nikada nije pristao nositi. Tretirajte to kao odluku o uvođenju s imenovanim vlasnikom, a ne kao korak otklanjanja pogrešaka koji poduzimate u 1 sat ujutro.

Redoslijed rada kojim ovo završava

Potvrdite da AAAA odgovor dolazi od resolvera koji drži zonu, pročitajte stanje VpnService i netd za sučelje tun, snimite net-export trag da vidite je li Chromium odbacio kandidata, zatim testirajte put tamo i natrag s ip -6 route get. Popravite sloj koji je stvarno zakazao i ostavite politiku razdvajanja na miru. Ako privatna imena trebaju drugačije odgovore od javnih, za to i služi split tunneling.

Zabilježite build telefona, verziju preglednika i resolver koji ste ispitivali. Te tri činjenice pretvaraju "IPv6 is broken" u nešto što sljedeća osoba može reproducirati.