Az Android VPN működik IPv6-tal, a böngésző mégis IPv4-et választ

A VPN fut, a privát webes felület IPv6-on válaszol egy laptopról, az Android-os telefon viszont ugyanazt az oldalt továbbra is IPv4-en nyitja meg, vagy egyáltalán nem hajlandó betölteni. Az AAAA-rekord létezik. Az alagút IPv6-címet jelent. A kliensben semmi sem tűnik hibásnak. Négy külön döntés határozza meg az eredményt: melyik feloldó válaszolt, mit nyilatkozott a VpnService az Androidnak, melyik címcsaládot volt hajlandó kipróbálni a böngésző, és hogy egy csomag meg tudja-e tenni az oda-vissza utat. Ebben a sorrendben haladjon végig rajtuk, ahelyett hogy hozzáadna egy alapértelmezett útvonalat, és abban reménykedne, hogy a tünet odébb áll.

1. lépés: bizonyítsa, melyik feloldó válaszolt az AAAA-kérdésre

Az Androidnak nincs egyetlen DNS-útvonala. Egy VPN DNS-kiszolgálót tolhat a hálózatára, a rendszer Private DNS-t használhat azokhoz a gazdanevekhez, amelyeket erre alkalmasnak ítél, a Chrome pedig a saját titkosított feloldóját futtathatja a chrome://settings/security címről. Olyan telefonon, ahol az alagút 10.61.0.1-et tol, de a Private DNS egy nyilvános szolgáltatóra mutat, a privát zónájában lévő nevet nem az a gép oldja fel, amely a zónát birtokolja. A böngésző olyan feloldótól kap választ, amelynek nincs jogosultsága arra a névre, és hiányzóként kezeli, a hibaüzenet pedig soha nem említi a DNS-t.

Kérdezze meg közvetlenül az alagút feloldóját, mielőtt bármi mást módosítana. Az első két parancs megmutatja, mely DNS-kiszolgálókat csatolt az Android az aktív hálózathoz, és hogy a Private DNS automatikus vagy szigorú módban van-e; a harmadik az alagúton belüli bármely kliensről fut, nem a telefonról.

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

2. lépés: olvassa el, mit nyilatkozott valójában a VpnService

Az Android oldala kifejezett, nem kikövetkeztetett. A VpnService.Builder a addAddress segítségével ad címeket, a addRoute segítségével útvonalakat, a addDnsServer segítségével DNS-kiszolgálókat, és a allowFamily segítségével az egész alagutat egyetlen címcsaládra korlátozhatja. Az a builder, amely meghívta a allowFamily(AF_INET)-et, majd később hozzáadott egy IPv6-útvonalat, két ellentmondó dolgot mondott a rendszernek, és a rendszer a családkorlátozást tartja meg. Az fd00:61::/64-et lefedő útvonal egy másik előtagba eső interfészcímmel kombinálva hasonló okból bukik el: a cím létezik, de nem on-link az adott útvonalhoz.

Olvassa a nyilatkozatot, ne az alkalmazás kapcsolójában bízzon. A dumpsys netd kiírja a tun interfészhez csatolt címeket és útvonalakat, a dumpsys connectivity-en belüli, hálózatonkénti LinkProperties pedig a DNS-listát mutatja a hálózat által állított családok mellett.

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"

Ha a tun interfész rendelkezik IPv6-címmel, de egyetlen útvonal sem illeszkedik a szolgáltatás előtagjára, az IPv6 kézbesítése már akkor elromlott, mielőtt böngésző kerülne a képbe. Ez más hiba, mint amikor egy böngésző nem hajlandó próbálkozni, és más javítást igényel.

3. lépés: a böngésző dönti el, egyáltalán megpróbálja-e az IPv6-ot

A Chromium nem használ fel minden beérkező AAAA-rekordot. A gazdafeloldója IPv6-elérhetőségi vizsgálatokat és jelöltszűrést hordoz, amelyek eldobhatják vagy hátrasorolhatják az IPv6-ot, ha a hálózatot arra alkalmatlannak ítéli, és a feloldó forráskódja megmutatja ezt a próbát a körülötte lévő feltételekkel együtt. A logika verzió- és kapcsolófüggő, és éppen ezért viselkedhet két telefon ugyanazon az alagúton másként. Amint vannak jelöltek, a Happy Eyeballs kapcsolatonként versenyezteti a családokat, így egy lassan válaszoló IPv6-útvonal még mindig veszíthet a gyorsan válaszoló IPv4-gyel szemben.

Figyelje meg a döntést, ne következtessen rá. A chrome://net-export segítségével rögzített, majd a netlog-megjelenítőben visszajátszott munkamenet megmutatja az egyes feloldásokat és a választott családot; a chrome://net-internals/#dns a gyorsítótárazott eredményeket mutatja. Az a feloldás, amely csak A-rekordokat ad vissza egy olyan névre, amelynek a saját feloldóján AAAA van, egyenesen erre a szakaszra mutat.

4. lépés: ellenőrizze, hogy egy csomag meg tudja-e tenni az oda-vissza utat

A címválasztás nem kézbesítés. Az Android hálózatonkénti útválasztási táblákat és házirend-szabályokat tart, amelyek fwmark alapján választanak táblát, így a fő táblában látható útvonal nem automatikusan az az útvonal, amelyet egy socket használ. A szabályok olvasása és a kernel megkérése, hogy oldjon fel egy célállomást egy forráscímhez, szétválasztja a kettőt.

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

A route get kimenete az, amely megválaszolja a kérdést. Ha tun0-t nevez meg, és a csomagok továbbra is elhalnak, lépjen tovább az alagút MTU-jára és az átjáró IPv6-továbbítására, ne a telefonra térjen vissza.

Miért rontja el a ::/0 hozzáadása általában a helyzetet

A ::/0 hozzáadása az alagút igényét egyetlen előtagról minden IPv6-célra módosítja. A telefonon ez kielégíthet egy elérhetőségi próbát, mert az előtagján kívüli tesztcím most útvonalazhatónak látszik. Ez nem hoz létre IPv6-os felfelé irányuló kapacitást az átjárón, és sok otthoni átjárónak egyáltalán nincs működő IPv6-os feltöltő kapcsolata. Az eredmény fekete lyuk a nyilvános IPv6 számára: a korábban IPv4-re visszaeső nevek most megakadnak, a privát oldal pedig csak azért tűnhet jobbnak, mert a próba valami mást mér.

Házirend-költsége is van. Ha az alagútban ott van a ::/0, minden IPv6-forgalom a VPN-en keresztül hagyja el a hálózatot, beleértve azt a forgalmat is, amelynek továbbításához a hálózat tulajdonosa soha nem járult hozzá. Tekintse ezt megnevezett tulajdonossal járó telepítési döntésnek, nem pedig hajnali 1-kor meghozott hibakeresési lépésnek.

A munkasorrend, amely lezárja ezt

Erősítse meg, hogy az AAAA-válasz attól a feloldótól jön, amely a zónát birtokolja, olvassa ki a VpnService és a netd állapotát a tun interfészhez, készítsen net-export nyomot, hogy lássa, eldobta-e a Chromium a jelöltet, majd tesztelje az oda-vissza utat a ip -6 route get segítségével. Azt a réteget javítsa, amely valóban elbukott, és hagyja békén az osztott házirendet. Ha a privát nevekhez más válaszok kellenek, mint a nyilvánosakhoz, a split tunneling éppen erre való.

Jegyezze fel a telefon buildjét, a böngésző verzióját és a feloldót, amelyet megkérdezett. Ez a három tény teszi az "IPv6 is broken" mondatot olyanná, amelyet a következő ember reprodukálni tud.