VPN-ul din Android funcționează pe IPv6, dar browserul tot alege IPv4

VPN-ul este pornit, interfața web privată răspunde pe IPv6 de pe un laptop, iar telefonul Android deschide în continuare aceeași pagină pe IPv4 sau refuză să o încarce complet. Înregistrarea AAAA există. Tunelul raportează o adresă IPv6. Nimic din client nu pare greșit. Rezultatul este decis de patru decizii separate: ce resolver a răspuns, ce a declarat VpnService către Android, ce familie de adrese era browserul dispus să încerce și dacă un pachet poate face drumul dus-întors. Parcurgeți-le în acea ordine în loc să adăugați o rută implicită și să sperați că simptomul se mută.

Pasul 1: demonstrați ce resolver a răspuns interogării AAAA

Android nu are o singură cale DNS. Un VPN poate împinge un server DNS pentru rețeaua sa, sistemul poate folosi Private DNS pentru numele de gazdă pe care le consideră eligibile, iar Chrome poate rula propriul resolver criptat de la chrome://settings/security. Pe un telefon unde tunelul împinge 10.61.0.1, dar Private DNS indică un furnizor public, numele din zona dumneavoastră privată nu este rezolvat de mașina care deține zona. Browserul primește un răspuns de la un resolver fără autoritate asupra acelui nume și îl tratează ca absent, iar textul erorii nu menționează niciodată DNS.

Întrebați direct resolverul tunelului înainte de a schimba orice altceva. Primele două comenzi arată ce servere DNS a atașat Android rețelei active și dacă Private DNS este în mod automat sau strict; a treia rulează din orice client din interiorul tunelului, nu de pe telefon.

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

Pasul 2: citiți ce a declarat de fapt VpnService

Partea Android este explicită, nu dedusă. Un VpnService.Builder adaugă adrese cu addAddress, rute cu addRoute, servere DNS cu addDnsServer și poate restricționa întregul tunel la o singură familie de adrese cu allowFamily. Un builder care a apelat allowFamily(AF_INET) și apoi a adăugat o rută IPv6 a spus sistemului două lucruri contradictorii, iar restricția de familie este cea pe care sistemul o păstrează. O rută care acoperă fd00:61::/64 împreună cu o adresă de interfață într-un alt prefix eșuează din același motiv: adresa există, dar nu este on-link pentru acea rută.

Citiți declarația în loc să aveți încredere în comutatorul din aplicație. dumpsys netd tipărește adresele și rutele atașate interfeței tun, iar LinkProperties pentru fiecare rețea din dumpsys connectivity arată lista DNS lângă familiile pe care rețeaua le revendică.

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"

Dacă interfața tun are o adresă IPv6, dar nicio rută nu se potrivește cu prefixul serviciului, livrarea IPv6 este deja stricată înainte ca un browser să intre în scenă. Este o eroare diferită de cea a unui browser care refuză să încerce și necesită o corecție diferită.

Pasul 3: browserul decide dacă încearcă deloc IPv6

Chromium nu folosește fiecare înregistrare AAAA pe care o primește. Resolverul său de gazde are verificări de accesibilitate IPv6 și filtrare a candidaților care pot elimina sau reduce prioritatea IPv6 atunci când rețeaua este judecată incapabilă să îl transporte, iar codul sursă al resolverului arată acea sondă împreună cu condițiile din jur. Logica depinde de versiune și de flaguri, și exact de aceea două telefoane pe același tunel se pot comporta diferit. Odată ce există candidați, Happy Eyeballs pune familiile să concureze pentru fiecare conexiune, așa că o cale IPv6 care răspunde lent poate pierde în fața IPv4 care răspunde repede.

Observați decizia în loc să o deduceți. O sesiune înregistrată prin chrome://net-export și redată în vizualizatorul netlog arată fiecare rezolvare și familia aleasă; chrome://net-internals/#dns arată rezultatele din cache. O rezolvare care returnează doar înregistrări A pentru un nume care are AAAA la resolverul dumneavoastră indică direct această etapă.

Pasul 4: verificați că un pachet poate face drumul dus-întors

Selectarea adresei nu este livrare. Android ține tabele de rutare și reguli de politică pentru fiecare rețea, care aleg o tabelă după fwmark, așa că o rută vizibilă în tabela principală nu este automat ruta pe care o folosește un socket. Citirea regulilor și cererea kernelului să rezolve o destinație pentru o adresă sursă separă cele două.

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

Ieșirea comenzii route get este cea care răspunde la întrebare. Dacă numește tun0 și pachetele mor în continuare, treceți la MTU-ul tunelului și la forwardingul IPv6 al gateway-ului în loc să vă întoarceți la telefon.

De ce adăugarea ::/0 de obicei înrăutățește situația

Adăugarea ::/0 schimbă pretenția tunelului de la un prefix la fiecare destinație IPv6. Pe telefon, asta poate satisface o sondă de accesibilitate, pentru că o adresă de test din afara prefixului dumneavoastră pare acum rutabilă. Nu creează capacitate IPv6 în amonte pe gateway, iar multe gateway-uri de acasă nu au deloc o legătură IPv6 în amonte funcțională. Rezultatul este o gaură neagră pentru IPv6 public: numele care înainte cădeau pe IPv4 acum atârnă, iar pagina privată poate părea mai bună doar pentru că sonda măsoară altceva.

Există și un cost de politică. Cu ::/0 în tunel, tot traficul IPv6 iese prin VPN, inclusiv traficul pe care proprietarul rețelei nu a fost niciodată de acord să îl transporte. Tratați asta ca o decizie de implementare cu un proprietar numit, nu ca un pas de depanare făcut la ora 1 noaptea.

Ordinea de lucru care încheie asta

Confirmați că răspunsul AAAA vine de la resolverul care deține zona, citiți starea VpnService și netd pentru interfața tun, capturați o urmă net-export pentru a vedea dacă Chromium a eliminat candidatul, apoi testați drumul dus-întors cu ip -6 route get. Reparați stratul care a eșuat de fapt și lăsați politica de divizare în pace. Dacă numele private au nevoie de răspunsuri diferite de cele publice, exact pentru asta există split tunneling.

Notați build-ul telefonului, versiunea browserului și resolverul pe care l-ați interogat. Aceste trei fapte transformă "IPv6 is broken" în ceva ce următoarea persoană poate reproduce.