La VPN d'Android funciona amb IPv6, però el navegador encara tria IPv4

La VPN està activa, la interfície web privada respon per IPv6 des d'un portàtil, i el telèfon Android encara obre la mateixa pàgina per IPv4 o es nega a carregar-la. El registre AAAA existeix. El túnel informa d'una adreça IPv6. Res del client no sembla incorrecte. Quatre decisions separades determinen el resultat: quin resolutor ha respost, què ha declarat VpnService a Android, quina família d'adreces el navegador estava disposat a provar i si un paquet pot fer el viatge d'anada i tornada. Treballeu-les en aquest ordre en lloc d'afegir una ruta per defecte i esperar que el símptoma es mogui.

Pas 1: demostreu quin resolutor ha respost la consulta AAAA

Android no té un únic camí DNS. Una VPN pot empènyer un servidor DNS per a la seva xarxa, el sistema pot utilitzar Private DNS per als noms d'amfitrió que considera qualificats, i Chrome pot executar el seu propi resolutor xifrat des de chrome://settings/security. En un telèfon on el túnel empeny 10.61.0.1 però Private DNS apunta a un proveïdor públic, el nom dins de la vostra zona privada no el resol la màquina que posseeix la zona. El navegador obté una resposta d'un resolutor sense autoritat sobre aquell nom i la tracta com a absent, i el text de l'error no esmenta mai DNS.

Pregunteu directament al resolutor del túnel abans de canviar res més. Les dues primeres ordres mostren quins servidors DNS ha adjuntat Android a la xarxa activa i si Private DNS és en mode automàtic o estricte; la tercera s'executa des de qualsevol client dins del túnel, no des del telèfon.

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

Pas 2: llegiu què ha declarat realment VpnService

El costat Android és explícit, no inferit. Un VpnService.Builder afegeix adreces amb addAddress, rutes amb addRoute, servidors DNS amb addDnsServer, i pot restringir tot el túnel a una família d'adreces amb allowFamily. Un constructor que ha cridat allowFamily(AF_INET) i després ha afegit una ruta IPv6 ha dit al sistema dues coses contradictòries, i la restricció de família és el que el sistema conserva. Una ruta que cobreix fd00:61::/64 combinada amb una adreça d'interfície en un altre prefix falla per una raó semblant: l'adreça existeix, però no és on-link per a aquella ruta.

Llegiu la declaració en lloc de confiar en l'interruptor de l'aplicació. dumpsys netd imprimeix les adreces i rutes adjuntes a la interfície tun, i el LinkProperties per xarxa dins de dumpsys connectivity mostra la llista DNS al costat de les famílies que la xarxa declara.

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"

Si la interfície tun té una adreça IPv6 però cap ruta coincideix amb el prefix del servei, el lliurament d'IPv6 ja està trencat abans que hi intervingui cap navegador. És un error diferent del d'un navegador que es nega a provar, i necessita una correcció diferent.

Pas 3: el navegador decideix si provar IPv6

Chromium no utilitza tots els registres AAAA que rep. El seu resolutor d'amfitrions porta comprovacions d'abastabilitat d'IPv6 i filtratge de candidats que poden descartar o rebaixar la prioritat d'IPv6 quan es jutja que la xarxa no el pot transportar, i el codi font del resolutor mostra aquesta sonda juntament amb les condicions que l'envolten. La lògica depèn de la versió i dels indicadors, i és exactament per això que dos telèfons al mateix túnel es poden comportar de manera diferent. Un cop hi ha candidats, Happy Eyeballs fa competir les famílies per cada connexió, així que un camí IPv6 que respon lentament encara pot perdre contra IPv4 que respon ràpidament.

Observeu la decisió en lloc d'inferir-la. Una sessió enregistrada amb chrome://net-export i reproduïda al visor de netlog mostra cada resolució i la família triada; chrome://net-internals/#dns mostra els resultats en memòria cau. Una resolució que només retorna registres A per a un nom que té AAAA al vostre propi resolutor apunta directament a aquesta etapa.

Pas 4: verifiqueu que un paquet pot fer el viatge d'anada i tornada

La selecció d'adreces no és lliurament. Android manté taules d'encaminament i regles de política per xarxa que trien una taula per fwmark, així que una ruta visible a la taula principal no és automàticament la ruta que utilitza un sòcol. Llegir les regles i demanar al nucli que resolgui una destinació per a una adreça d'origen separa les dues coses.

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

La sortida de route get és la que respon la pregunta. Si anomena tun0 i els paquets encara moren, passeu a l'MTU del túnel i a l'encaminament IPv6 de la passarel·la en lloc de tornar al telèfon.

Per què afegir ::/0 normalment ho empitjora

Afegir ::/0 canvia la reivindicació del túnel d'un prefix a totes les destinacions IPv6. Al telèfon, això pot satisfer una sonda d'abastabilitat, perquè una adreça de prova fora del vostre prefix ara sembla encaminable. No crea capacitat IPv6 aigües amunt a la passarel·la, i moltes passarel·les domèstiques no tenen cap enllaç ascendent IPv6 que funcioni. El resultat és un forat negre per a IPv6 públic: noms que abans queien a IPv4 ara es pengen, i la pàgina privada pot semblar millor només perquè la sonda mesura una altra cosa.

També hi ha un cost de política. Amb ::/0 al túnel, tot el trànsit IPv6 surt per la VPN, inclòs el trànsit que el propietari de la xarxa mai no va acceptar transportar. Tracteu-ho com una decisió de desplegament amb un propietari anomenat, no com un pas de depuració que feu a la 1 de la matinada.

L'ordre de treball que acaba amb això

Confirmeu que la resposta AAAA ve del resolutor que posseeix la zona, llegiu l'estat de VpnService i netd per a la interfície tun, captureu una traça net-export per veure si Chromium ha descartat el candidat, i després proveu el viatge d'anada i tornada amb ip -6 route get. Corregiu la capa que realment ha fallat i deixeu la política de divisió tranquil·la. Si els noms privats necessiten respostes diferents dels públics, per a això serveix el split tunneling.

Anoteu la compilació del telèfon, la versió del navegador i el resolutor que heu consultat. Aquests tres fets converteixen "IPv6 is broken" en una cosa que la propera persona pot reproduir.