Android VPNak IPv6rekin egiten du lan, baina nabigatzaileak IPv4 aukeratzen du oraindik

VPNa martxan dago, web interfaze pribatuak IPv6 bidez erantzuten du eramangarri batetik, eta Android telefonak oraindik IPv4 bidez irekitzen du orri bera edo ez du batere kargatzen. AAAA erregistroa badago. Tunelak IPv6 helbidea ematen du. Bezeroan ez da ezer okerrik ematen. Lau erabaki berezik zehazten dute emaitza: zein resolverrek erantzun zuen, zer deklaratu zion VpnService-k Androideri, zein helbide-familia probatzeko prest zegoen nabigatzailea eta pakete batek joan-etorria egin dezakeen. Horiek ordena horretan landu, ibilbide lehenetsi bat gehitu eta sintomak mugituko direlako espero ordez.

1. urratsa: frogatu zein resolverrek erantzun zion AAAA kontsultari

Androidek ez du DNS bide bakarra. VPN batek DNS zerbitzari bat bultza dezake bere sarearentzat, sistemak Private DNS erabil dezake egokitzat jotzen dituen ostalari-izenetarako, eta Chrome-k bere resolver zifratua exekuta dezake chrome://settings/security helbidetik. Tunelak 10.61.0.1 bultzatzen duen baina Private DNS hornitzaile publiko batera eramaten duen telefono batean, zure zona pribatuko izena ez du zonaren jabe den makinak ebazten. Nabigatzaileak izen horretarako autoritaterik ez duen resolver batetik jasotzen du erantzuna eta falta den zerbait bezala tratatzen du, eta errorearen testuak ez du inoiz DNS aipatzen.

Galdetu zuzenean tunelaren resolverrari beste ezer aldatu aurretik. Lehen bi komandoek Androidek sare aktiboari zein DNS zerbitzari lotu dizkion eta Private DNS modu automatikoan edo zorrotzean dagoen erakusten dute; hirugarrena tunelaren barruan edozein bezerotatik exekutatzen da, ez telefonotik.

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. urratsa: irakurri VpnService-k benetan zer deklaratu zuen

Android aldea esplizitua da, ez inferitua. VpnService.Builder batek helbideak gehitzen ditu addAddress bidez, ibilbideak addRoute bidez, DNS zerbitzariak addDnsServer bidez, eta tunel osoa helbide-familia bakarrera mugatu dezake allowFamily bidez. allowFamily(AF_INET) deitu eta geroago IPv6 ibilbidea gehitu zuen eraikitzaile batek gauza kontraesankor bi esan dizkio sistemari, eta sistemak familia-murrizketa gordetzen du. fd00:61::/64 estaltzen duen ibilbide bat beste aurrizki bateko interfaze-helbide batekin konbinatzen denean antzeko arrazoiengatik huts egiten du: helbidea badago, baina ez dago on-link ibilbide horretarako.

Irakurri deklarazioa aplikazioko etengailuan fidatu ordez. dumpsys netd komandoak tun interfazeari lotutako helbideak eta ibilbideak inprimatzen ditu, eta sareko LinkProperties erreferentziak dumpsys connectivity barruan DNS zerrenda erakusten du sareak aldarrikatzen dituen familien ondoan.

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"

Tun interfazeak IPv6 helbidea badu baina zerbitzuaren aurrizkiarekin bat datorren ibilbiderik ez badago, IPv6 entrega jada hondatuta dago nabigatzailea sartu aurretik. Hau probatzeari uko egiten dion nabigatzailearen akats desberdina da, eta konponketa desberdina behar du.

3. urratsa: nabigatzaileak erabakitzen du ea IPv6 probatu behar duen

Chromiumek ez du jasotzen duen AAAA erregistro bakoitza erabiltzen. Bere ostalari-resolverrak IPv6 irisgarritasun-probak eta hautagai-iragazkia ditu, eta haiek IPv6 baztertu edo lehenetsi dezake sarea hura eramateko gai ez dela jotzen denean, eta resolverraren iturburu-kodeak proba hori erakusten du inguruko baldintzekin batera. Logika bertsioaren eta banderen araberakoa da, eta horrexegatik joka ditzakete bi telefonok modu desberdinean tunel berean. Hautagaiak daudenean, Happy Eyeballs-ek familien arteko lasterketa egiten du konexio bakoitzeko, beraz motel erantzuten duen IPv6 bidea azkar erantzuten duen IPv4aren aurka galdu daiteke oraindik.

Behakatu erabakia, ez inferitu. chrome://net-export bidez grabatutako eta netlog ikustailean erreproduzitutako saio batek ebazpen bakoitza eta aukeratutako familia erakusten ditu; chrome://net-internals/#dns komandoak cachean gordetako emaitzak erakusten ditu. Zure resolverrean AAAA duen izen baterako A erregistroak soilik itzultzen dituen ebazpenak etapa honetara zuzenean seinalatzen du.

4. urratsa: egiaztatu pakete batek joan-etorria egin dezakeela

Helbide-hautaketa ez da entrega. Androidek sareko bideratze-taulak eta politika-arauak gordetzen ditu, fwmark bidez taula bat aukeratzen dutenak, beraz taula nagusian ikusten den ibilbidea ez da automatikoki socket batek erabiltzen duen ibilbidea. Arauak irakurtzeak eta kernelari jatorri-helbide baterako helmuga ebazteko eskatzeak biak bereizten ditu.

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

route get ren irteera da galderari erantzuten diona. tun0 aipatzen badu eta paketeak oraindik hiltzen badira, joan tunelaren MTUra eta gatewayaren IPv6 aurreratzera, telefonora itzuli ordez.

Zergatik ohi okertzen duen ::/0 gehitzeak

::/0 gehitzeak tunelaren aldarrikapena aurrizki batetik IPv6 helmuga guztietara aldatzen du. Telefonoan horrek irisgarritasun-proba bat bete dezake, zure aurrizkitik kanpoko proba-helbide bat orain bideragarri ematen duelako. Ez du IPv6 gorako gaitasunik sortzen gatewayan, eta etxeko gateway askok ez dute batere IPv6 gorako esteka lan egiten duenik. Emaitza IPv6 publikoarentzako zulo beltza da: lehen IPv4ra erortzen ziren izenak orain zintzilik geratzen dira, eta orri pribatuak hobea eman dezake probak beste zerbait neurtzen duelako soilik.

Politika-kostua ere badago. Tunelak ::/0 duenean, IPv6 trafiko guztia VPN bidez irteten da, sarearen jabeak inoiz eramatea onartu ez zuen trafikoa barne. Trata ezazu jabe izendatua duen ezarpen-erabaki gisa, gaueko 1etan hartzen duzun arazketa-pauso gisa baino.

Hau amaitzen duen lan-ordena

Egiaztatu AAAA erantzuna zona duen resolverretik datorrela, irakurri VpnService eta netd egoera tun interfazerako, hartu net-export arrasto bat Chromiumek hautagaia baztertu zuen ikusteko, eta gero probatu joan-etorria ip -6 route get erabiliz. Benetan huts egin zuen geruza konpondu eta utzi banaketa-politika bakean. Izen pribatuek publikoek ez dituzten erantzunak behar badituzte, horretarako dago split tunneling.

Idatzi telefonaren builda, nabigatzailearen bertsioa eta kontsultatu zenuen resolverra. Hiru datu horiek "IPv6 is broken" hurrengo pertsonak erreproduzi dezakeen zerbait bihurtzen dute.