Android VPN ради са IPv6, али прегледач и даље бира IPv4

VPN је активан, приватно веб сучеље одговара преко IPv6 са преносног рачунара, а Android телефон и даље отвара исту страницу преко IPv4 или је уопште одбија учитати. AAAA запис постоји. Тунел пријављује IPv6 адресу. Ништа у клијенту не изгледа погрешно. Исход одређују четири одвојене одлуке: који је резолвер одговорио, шта је VpnService декларисао Android-у, коју је фамилију адреса прегледач био спреман да испроба и може ли пакет да направи пут тамо и назад. Обрадите их тим редом уместо да додате подразумевану руту и надате се да ће се симптом померити.

Корак 1: докажите који је резолвер одговорио на AAAA упит

Android нема јединствен пут за DNS. VPN може да прогура DNS сервер за своју мрежу, систем може да користи Private DNS за имена хостова која сматра квалификованим, а Chrome може да покреће сопствени шифровани резолвер са chrome://settings/security. На телефону на коме тунел прогура 10.61.0.1, али Private DNS показује на јавног даваоца, име унутар ваше приватне зоне не разрешава машина која поседује зону. Прегледач добија одговор од резолвера без овлашћења за то име и третира га као да недостаје, а текст грешке никада не помиње DNS.

Питајте резолвер тунела директно пре него што промените било шта друго. Прве две наредбе показују које је DNS сервере Android придружио активној мрежи и да ли је Private DNS у аутоматском или строгом режиму; трећа се извршава са било ког клијента унутар тунела, не са телефона.

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: прочитајте шта је VpnService заправо декларисао

Android страна је изричита, а не изведена. VpnService.Builder додаје адресе помоћу addAddress, руте помоћу addRoute, DNS сервере помоћу addDnsServer и може да ограничи цео тунел на једну фамилију адреса помоћу allowFamily. Градитељ који је позвао allowFamily(AF_INET) и касније додао IPv6 руту рекао је систему две противречне ствари, а систем задржава ограничење фамилије. Рута која покрива fd00:61::/64 у комбинацији са адресом интерфејса у другом префиксу не успева из сличног разлога: адреса постоји, али није on-link за ту руту.

Читајте декларацију уместо да верујете прекидачу у апликацији. dumpsys netd исписује адресе и руте придружене интерфејсу tun, а LinkProperties по мрежи унутар dumpsys connectivity показује DNS листу уз фамилије које мрежа тврди.

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 има IPv6 адресу, али ниједна рута не одговара префиксу услуге, достава IPv6 је већ покварена пре него што се прегледач укључи. То је другачија грешка од прегледача који одбија да покуша и тражи другачију поправку.

Корак 3: прегледач одлучује хоће ли уопште покушати IPv6

Chromium не користи сваки AAAA запис који прими. Његов резолвер хостова носи провере доступности IPv6 и филтрирање кандидата који могу да одбаце или снизе приоритет IPv6 када се мрежа процени неспособном да га носи, а изворни код резолвера показује ту проверу заједно са условима око ње. Логика зависи од верзије и заставица, и управо зато се два телефона на истом тунелу могу понашати различито. Кад кандидати постоје, Happy Eyeballs води трку фамилија по свакој вези, па IPv6 пут који одговара споро ипак може изгубити од IPv4 који одговара брзо.

Посматрајте одлуку уместо да је изводите. Сесија снимљена кроз chrome://net-export и репродукована у прегледачу netlog показује свако разрешавање и изабрану фамилију; chrome://net-internals/#dns показује кеширане резултате. Разрешавање које враћа само A записе за име које има AAAA на вашем резолверу директно указује на ову фазу.

Корак 4: проверите може ли пакет да направи пут тамо и назад

Избор адресе није достава. Android држи табеле усмеравања и правила политике по мрежи који бирају табелу по fwmark, па рута видљива у главној табели није аутоматски рута коју користи socket. Читање правила и тражење да језгро разреши одредиште за изворну адресу раздваја то двоје.

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

Излаз наредбе route get је онај који одговара на питање. Ако именује tun0, а пакети и даље гину, пређите на MTU тунела и IPv6 прослеђивање на приступнику, уместо назад на телефон.

Зашто додавање ::/0 обично погоршава ствар

Додавање ::/0 мења тврдњу тунела са једног префикса на свако IPv6 одредиште. На телефону то може да задовољи проверу доступности јер тестна адреса изван вашег префикса сада изгледа усмериво. То не ствара IPv6 узводни капацитет на приступнику, а многи кућни приступници уопште немају радни IPv6 улазни линк. Резултат је црна рупа за јавни IPv6: имена која су се раније враћала на IPv4 сада висе, а приватна страница може изгледати боље само зато што провера мери нешто друго.

Постоји и цена за политику. Са ::/0 у тунелу сав IPv6 саобраћај излази кроз VPN, укључујући саобраћај који власник мреже никада није пристао да носи. Третирајте то као одлуку о увођењу са именованим власником, а не као корак отклањања грешака који предузимате у 1 сат ујутру.

Редослед рада којим се ово завршава

Потврдите да AAAA одговор долази од резолвера који држи зону, прочитајте стање VpnService и netd за интерфејс tun, снимите net-export траг да видите да ли је Chromium одбацио кандидата, затим тестирајте пут тамо и назад са ip -6 route get. Поправите слој који је стварно заказао и оставите политику раздвајања на миру. Ако приватна имена траже другачије одговоре од јавних, за то и служи split tunneling.

Забележите build телефона, верзију прегледача и резолвер који сте испитивали. Те три чињенице претварају "IPv6 is broken" у нешто што следећа особа може да репродукује.