VPN je aktivan, privatno web sučelje odgovara preko IPv6 sa prenosnog računara, a Android telefon i dalje otvara istu stranicu preko IPv4 ili je uopšte 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, šta je VpnService deklarisao Androidu, koju je familiju adresa pregledač bio spreman da isproba i može li paket da napravi put tamo i nazad. Obradite ih tim redom umesto da dodate podrazumevanu rutu i nadate se da će se simptom pomeriti.

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

Android nema jedinstven put za DNS. VPN može da progura DNS server za svoju mrežu, sistem može da koristi Private DNS za imena hostova koja smatra kvalifikovanim, a Chrome može da pokreće sopstveni šifrovani resolver sa chrome://settings/security. Na telefonu na kome tunel progura 10.61.0.1, ali Private DNS pokazuje na javnog davaoca, ime unutar vaše privatne zone ne razrešava mašina koja poseduje zonu. Pregledač dobija odgovor od resolvera bez ovlašćenja za to ime i tretira ga kao da nedostaje, a tekst greške nikada ne pominje DNS.

Pitajte resolver tunela direktno pre nego što promenite bilo šta drugo. Prve dve naredbe pokazuju koje je DNS servere Android pridružio aktivnoj mreži i da li je Private DNS u automatskom ili strogom režimu; treća se izvršava sa bilo kog klijenta unutar tunela, ne sa 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 šta je VpnService zapravo deklarisao

Android strana je izričita, a ne izvedena. VpnService.Builder dodaje adrese pomoću addAddress, rute pomoću addRoute, DNS servere pomoću addDnsServer i može da ograniči ceo tunel na jednu familiju adresa pomoću allowFamily. Graditelj koji je pozvao allowFamily(AF_INET) i kasnije dodao IPv6 rutu rekao je sistemu dve protivrečne stvari, a sistem zadržava ograničenje familije. Ruta koja pokriva fd00:61::/64 u kombinaciji sa adresom interfejsa u drugom prefiksu ne uspeva iz sličnog razloga: adresa postoji, ali nije on-link za tu rutu.

Čitajte deklaraciju umesto da verujete prekidaču u aplikaciji. dumpsys netd ispisuje adrese i rute pridružene interfejsu tun, a LinkProperties po mreži unutar dumpsys connectivity pokazuje DNS listu uz familije 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 interfejs tun ima IPv6 adresu, ali nijedna ruta ne odgovara prefiksu usluge, dostava IPv6 je već pokvarena pre nego što se pregledač uključi. To je drugačija greška od pregledača koji odbija da pokuša i traži drugačiju popravku.

Korak 3: pregledač odlučuje hoće li uopšte pokušati IPv6

Chromium ne koristi svaki AAAA zapis koji primi. Njegov resolver hostova nosi provere dostupnosti IPv6 i filtriranje kandidata koji mogu da odbace ili snize prioritet IPv6 kada se mreža proceni nesposobnom da ga nosi, a izvorni kod resolvera pokazuje tu proveru zajedno sa uslovima oko nje. Logika zavisi od verzije i zastavica, i upravo zato se dva telefona na istom tunelu mogu ponašati različito. Kad kandidati postoje, Happy Eyeballs vodi trku familija po svakoj vezi, pa IPv6 put koji odgovara sporo ipak može izgubiti od IPv4 koji odgovara brzo.

Posmatrajte odluku umesto da je izvodite. Sesija snimljena kroz chrome://net-export i reprodukovana u pregledaču netlog pokazuje svako razrešavanje i izabranu familiju; chrome://net-internals/#dns pokazuje keširane rezultate. Razrešavanje koje vraća samo A zapise za ime koje ima AAAA na vašem resolveru direktno ukazuje na ovu fazu.

Korak 4: proverite može li paket da napravi put tamo i nazad

Izbor adrese nije dostava. Android drži tabele usmeravanja i pravila politike po mreži koji biraju tabelu po fwmark, pa ruta vidljiva u glavnoj tabeli nije automatski ruta koju koristi socket. Čitanje pravila i traženje da jezgro razreš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, pređite na MTU tunela i IPv6 prosleđivanje na pristupniku, umesto nazad na telefon.

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

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

Postoji i cena za politiku. Sa ::/0 u tunelu sav IPv6 saobraćaj izlazi kroz VPN, uključujući saobraćaj koji vlasnik mreže nikada nije pristao da nosi. Tretirajte to kao odluku o uvođenju sa imenovanim vlasnikom, a ne kao korak otklanjanja grešaka koji preduzimate u 1 sat ujutru.

Redosled rada kojim se ovo završava

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

Zabeležite build telefona, verziju pregledača i resolver koji ste ispitivali. Te tri činjenice pretvaraju "IPv6 is broken" u nešto što sledeća osoba može da reprodukuje.

Povezani članci