Androidi VPN töötab IPv6-ga, aga brauser valib ikka IPv4

VPN on üleval, privaatne veebiliides vastab sülearvutist IPv6 kaudu, ja Android-telefon avab sama lehe ikka IPv4 kaudu või keeldub seda üldse laadimast. AAAA-kirje on olemas. Tunnel teatab IPv6-aadressi. Kliendis ei paista miski valesti olevat. Tulemuse määravad neli eraldi otsust: milline resolver vastas, mida VpnService Androidile deklareeris, millist aadressiperekonda oli brauser valmis proovima ja kas pakett suudab teekonna sinna ja tagasi teha. Tehke need selles järjekorras, selle asemel et lisada vaikimisi marsruut ja loota, et sümptom liigub.

1. samm: tõestage, milline resolver vastas AAAA-päringule

Androidil ei ole ühte DNS-teed. VPN võib oma võrgu jaoks DNS-serveri peale suruda, süsteem võib kasutada Private DNS-i hostinimede jaoks, mida ta peab sobivaks, ja Chrome võib käivitada oma krüpteeritud resolveri aadressilt chrome://settings/security. Telefonis, kus tunnel surub peale 10.61.0.1, aga Private DNS osutab avalikule teenusepakkujale, ei lahenda teie privaatse tsooni nime masin, mis tsooni omab. Brauser saab vastuse resolverilt, kellel puudub selle nime üle volitus, ja käsitleb seda puuduvana, ning veatekst ei maini DNS-i kunagi.

Küsige tunneli resolverilt otse, enne kui midagi muud muudate. Kaks esimest käsku näitavad, millised DNS-serverid Android aktiivse võrguga sidus ja kas Private DNS on automaatses või ranges režiimis; kolmas käivitub tunneli sees mis tahes kliendist, mitte telefonist.

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. samm: lugege, mida VpnService tegelikult deklareeris

Androidi pool on selgesõnaline, mitte tuletatud. VpnService.Builder lisab aadresse addAddress-ga, marsruute addRoute-ga, DNS-servereid addDnsServer-ga ja saab kogu tunneli piirata ühe aadressiperekonnaga allowFamily abil. Ehitaja, mis kutsus allowFamily(AF_INET) ja lisas hiljem IPv6-marsruudi, on süsteemile öelnud kahte vastuolulist asja, ja perekonna piirang on see, mille süsteem alles jätab. Marsruut, mis katab fd00:61::/64, koos teises prefiksis oleva liidese aadressiga ebaõnnestub sarnasel põhjusel: aadress on olemas, aga see ei ole selle marsruudi jaoks on-link.

Lugege deklaratsiooni, selle asemel et usaldada rakenduse lülitit. dumpsys netd trükib tun-liidesega seotud aadressid ja marsruudid, ning võrgupõhine LinkProperties käsus dumpsys connectivity näitab DNS-loendit nende perekondade kõrval, mida võrk väidab.

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"

Kui tun-liidesel on IPv6-aadress, aga ükski marsruut ei vasta teenuse prefiksile, on IPv6 kohaletoimetamine juba katki enne, kui brauser mängu tuleb. See on teistsugune viga kui brauser, mis keeldub proovimast, ja see vajab teistsugust parandust.

3. samm: brauser otsustab, kas IPv6-d üldse proovida

Chromium ei kasuta iga saadud AAAA-kirjet. Selle hostiresolver kannab IPv6 kättesaadavuse kontrolle ja kandidaatide filtreerimist, mis võivad IPv6 välja jätta või selle tähtsust vähendada, kui võrk hinnatakse selle kandmiseks võimetuks, ja resolveri lähtekood näitab seda kontrolli koos seda ümbritsevate tingimustega. Loogika sõltub versioonist ja lippudest, ja just seetõttu võivad kaks telefoni samas tunnelis käituda erinevalt. Kui kandidaadid on olemas, paneb Happy Eyeballs perekonnad iga ühenduse puhul võidu jooksma, nii et aeglaselt vastav IPv6-tee võib ikkagi kiiresti vastavale IPv4-le kaotada.

Jälgige otsust, selle asemel et seda tuletada. chrome://net-export kaudu salvestatud ja netlog-vaaturis taasesitatud sessioon näitab iga lahendust ja valitud perekonda; chrome://net-internals/#dns näitab vahemällu salvestatud tulemusi. Lahendus, mis tagastab ainult A-kirjeid nimele, millel on AAAA teie enda resolveris, osutab otse sellele etapile.

4. samm: kontrollige, kas pakett suudab teekonna sinna ja tagasi teha

Aadressi valik ei ole kohaletoimetamine. Android hoiab võrgupõhiseid marsruutimistabeleid ja poliitikareegleid, mis valivad tabeli fwmarki järgi, nii et põhitabelis nähtav marsruut ei ole automaatselt see marsruut, mida sokk kasutab. Reeglite lugemine ja kerneli palumine lähteaadressi jaoks sihtkoht lahendada eristab need kaks.

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

Just route get väljund vastab küsimusele. Kui see nimetab tun0 ja paketid surevad endiselt, liikuge tunneli MTU ja lüüsi IPv6-edastamise juurde, mitte tagasi telefoni juurde.

Miks ::/0 lisamine tavaliselt asja hullemaks teeb

::/0 lisamine muudab tunneli nõude ühest prefiksist igaks IPv6-sihtkohaks. Telefonis võib see kättesaadavuskontrolli rahuldada, sest teie prefiksist väljaspool olev testaadress näib nüüd marsruuditavana. See ei loo lüüs IPv6 ülesvoolu mahtu, ja paljudel koduruuteritel ei ole üldse töötavat IPv6 ülesvooluühendust. Tulemuseks on must auk avaliku IPv6 jaoks: nimed, mis varem langesid tagasi IPv4-le, jäävad nüüd rippuma, ja privaatne leht võib parem paista ainult sellepärast, et kontroll mõõdab midagi muud.

Ka poliitiline hind on olemas. Kui tunnelis on ::/0, väljub kogu IPv6-liiklus VPN-i kaudu, sealhulgas liiklus, mida võrgu omanik ei ole kunagi nõustunud kandma. Käsitlege seda juurutamisotsusena, millel on nimetatud omanik, mitte silumissammuna, mille teete kell 1 öösel.

Tööjärjekord, mis selle lõpetab

Kinnitage, et AAAA-vastus tuleb resolverilt, kes tsooni omab, lugege tun-liidese VpnService'i ja netd olekut, salvestage net-export jälg, et näha, kas Chromium jättis kandidaadi välja, ja seejärel testige teekonda sinna ja tagasi käsuga ip -6 route get. Parandage kiht, mis tegelikult ebaõnnestus, ja jätke jagamispoliitika puutumata. Kui privaatsed nimed vajavad avalikest erinevaid vastuseid, on split tunneling just selle jaoks.

Märkige üles telefoni build, brauseri versioon ja resolver, millelt küsisite. Need kolm fakti muudavad lause "IPv6 is broken" millekski, mida järgmine inimene saab korrata.