Android VPN darbojas ar IPv6, bet pārlūks joprojām izvēlas IPv4

VPN ir ieslēgts, privātā tīmekļa saskarne atbild pa IPv6 no portatīvā datora, un Android tālrunis joprojām atver to pašu lapu pa IPv4 vai atsakās to ielādēt pavisam. AAAA ieraksts pastāv. Tunelis ziņo IPv6 adresi. Klientā nekas neizskatās nepareizi. Rezultātu nosaka četri atsevišķi lēmumi: kurš atrisinātājs atbildēja, ko VpnService deklarēja Android, kuru adrešu saimi pārlūks bija gatavs izmēģināt un vai pakete var veikt ceļu turp un atpakaļ. Izskatiet tos šajā secībā, nevis pievienojiet noklusējuma maršrutu un ceriet, ka simptoms pārvietosies.

1. solis: pierādiet, kurš atrisinātājs atbildēja uz AAAA vaicājumu

Android nav viena DNS ceļa. VPN var iespiest DNS serveri savam tīklam, sistēma var izmantot Private DNS tiem resursdatoru nosaukumiem, ko uzskata par atbilstošiem, un Chrome var darbināt savu šifrēto atrisinātāju no chrome://settings/security. Tālrunī, kur tunelis iespiež 10.61.0.1, bet Private DNS norāda uz publisku pakalpojumu sniedzēju, nosaukumu jūsu privātajā zonā neatrisina iekārta, kurai pieder zona. Pārlūks saņem atbildi no atrisinātāja bez pilnvarām uz šo nosaukumu un uzskata to par trūkstošu, un kļūdas tekstā DNS nekad netiek minēts.

Jautājiet tuneļa atrisinātājam tieši, pirms kaut ko citu maināt. Pirmās divas komandas parāda, kuras DNS serverus Android piesaistīja aktīvajam tīklam un vai Private DNS ir automātiskajā vai stingrajā režīmā; trešā tiek izpildīta no jebkura klienta tuneļa iekšienē, nevis no tālruņa.

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. solis: izlasiet, ko VpnService patiešām deklarēja

Android puse ir skaidra, nevis secināta. VpnService.Builder pievieno adreses ar addAddress, maršrutus ar addRoute, DNS serverus ar addDnsServer, un var ierobežot visu tuneli ar vienu adrešu saimi ar allowFamily. Veidotājs, kas izsauca allowFamily(AF_INET) un vēlāk pievienoja IPv6 maršrutu, sistēmai ir pateicis divas pretrunīgas lietas, un sistēma saglabā saimes ierobežojumu. Maršruts, kas aptver fd00:61::/64, kopā ar saskarnes adresi citā prefiksā, neizdodas līdzīga iemesla dēļ: adrese pastāv, bet tā nav on-link šim maršrutam.

Lasiet deklarāciju, nevis uzticieties lietotnes slēdzim. dumpsys netd izdrukā adreses un maršrutus, kas piesaistīti tun saskarnei, un LinkProperties pa tīkliem dumpsys connectivity iekšienē rāda DNS sarakstu blakus saimēm, ko tīkls apgalvo.

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"

Ja tun saskarnei ir IPv6 adrese, bet neviens maršruts neatbilst pakalpojuma prefiksam, IPv6 piegāde jau ir salauzta, pirms pārlūks vispār piedalās. Tā ir cita kļūda nekā pārlūks, kas atsakās mēģināt, un tai vajag citu labojumu.

3. solis: pārlūks izlemj, vai vispār mēģināt IPv6

Chromium neizmanto katru saņemto AAAA ierakstu. Tā resursdatoru atrisinātājam ir IPv6 sasniedzamības pārbaudes un kandidātu filtrēšana, kas var izmest IPv6 vai pazemināt tā prioritāti, ja tīkls tiek novērtēts kā nespējīgs to pārnest, un atrisinātāja pirmkods rāda šo pārbaudi kopā ar apkārtējiem nosacījumiem. Loģika ir atkarīga no versijas un karogiem, un tieši tāpēc divi tālruņi vienā tunelī var uzvesties atšķirīgi. Kad kandidāti ir, Happy Eyeballs liek saimēm sacensties katram savienojumam, tāpēc lēni atbildošs IPv6 ceļš joprojām var zaudēt ātri atbildošam IPv4.

Vērojiet lēmumu, nevis seciniet to. Sesija, kas ierakstīta ar chrome://net-export un atskaņota netlog skatītājā, rāda katru atrisinājumu un izvēlēto saimi; chrome://net-internals/#dns rāda kešatmiņā saglabātos rezultātus. Atrisinājums, kas nosaukumam ar AAAA jūsu pašu atrisinātājā atgriež tikai A ierakstus, tieši norāda uz šo posmu.

4. solis: pārbaudiet, vai pakete var veikt ceļu turp un atpakaļ

Adreses izvēle nav piegāde. Android uztur maršrutēšanas tabulas un politikas noteikumus pa tīkliem, kas tabulu izvēlas pēc fwmark, tāpēc galvenajā tabulā redzamais maršruts nav automātiski tas, ko izmanto ligzda. Noteikumu lasīšana un lūgšana kodolam atrisināt galamērķi avota adresei šos divus atdala.

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

Tieši route get izvade atbild uz jautājumu. Ja tā nosauc tun0 un paketes joprojām iet bojā, pārejiet uz tuneļa MTU un vārtejas IPv6 pāradresāciju, nevis atgriezieties pie tālruņa.

Kāpēc ::/0 pievienošana parasti visu pasliktina

::/0 pievienošana maina tuneļa prasību no viena prefiksa uz katru IPv6 galamērķi. Tālrunī tas var apmierināt sasniedzamības pārbaudi, jo testa adrese ārpus jūsu prefiksa tagad izskatās maršrutējama. Taču tas nerada IPv6 augšupstrāvas jaudu vārtejā, un daudzām mājas vārtejām vispār nav strādājošas IPv6 augšupējas saites. Rezultāts ir melna bedre publiskajam IPv6: nosaukumi, kas agrāk krita uz IPv4, tagad karājas, un privātā lapa var izskatīties labāk tikai tāpēc, ka pārbaude mēra ko citu.

Ir arī politikas izmaksas. Ja tunelī ir ::/0, viss IPv6 trafiks iziet caur VPN, tostarp trafiks, kuru tīkla īpašnieks nekad nav piekritis pārnest. Uztveriet to kā izvietošanas lēmumu ar nosauktu atbildīgo, nevis kā atkļūdošanas soli, ko veicat 1 naktī.

Darbu secība, kas to pabeidz

Apstipriniet, ka AAAA atbilde nāk no atrisinātāja, kuram pieder zona, izlasiet VpnService un netd stāvokli tun saskarnei, uzņemiet net-export pēdas, lai redzētu, vai Chromium izmeta kandidātu, un pēc tam pārbaudiet ceļu turp un atpakaļ ar ip -6 route get. Salabojiet to slāni, kas patiešām neizdevās, un atstājiet sadalīšanas politiku mierā. Ja privātiem nosaukumiem vajag citas atbildes nekā publiskiem, split tunneling ir tieši tam.

Pierakstiet tālruņa build, pārlūka versiju un atrisinātāju, kuram jautājāt. Šie trīs fakti pārvērš "IPv6 is broken" kaut kurā, ko nākamais cilvēks var atkārtot.