Android-VPN virkar með IPv6 en vafrinn velur samt IPv4

VPN-ið er í gangi, einkavefviðmótið svarar um IPv6 frá fartölvu, og Android-síminn opnar samt sömu síðu um IPv4 eða neitar að hlaða henni. AAAA-færslan er til. Göngin tilkynna IPv6-vistfang. Ekkert í biðlarunum virðist rangt. Fjórar aðskildar ákvarðanir ráða niðurstöðunni: hvaða leysir svaraði, hvað VpnService lýsti yfir við Android, hvaða vistfangafjölskyldu vafrinn var reiðubúinn að prófa, og hvort pakki kemst fram og til baka. Farðu í gegnum þær í þessari röð í stað þess að bæta við sjálfgefinni leið og vona að einkennið færist til.

Skref 1: sannaðu hvaða leysir svaraði AAAA-fyrirspurninni

Android hefur ekki eina DNS-leið. VPN getur ýtt DNS-þjóni fyrir netið sitt, kerfið getur notað Private DNS fyrir hýsitöflur sem það telur hæfar, og Chrome getur keyrt sinn eigin dulkóðaða leysi frá chrome://settings/security. Í síma þar sem göngin ýta 10.61.0.1 en Private DNS bendir á opinberan þjónustuaðila er nafnið inni í einkasvæðinu þínu ekki leyst af þeirri vél sem á svæðið. Vafrinn fær svar frá leysi án valds yfir því nafni og meðhöndlar það sem vantað, og villutextinn nefnir aldrei DNS.

Spurðu leysi gagnanna beint áður en þú breytir nokkru öðru. Fyrstu tvær skipanirnar sýna hvaða DNS-þjónum Android tengdi við virka netið og hvort Private DNS er í sjálfvirkum eða ströngum ham; sú þriðja keyrir frá hvaða biðlara sem er inni í göngunum, ekki frá símanum.

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

Skref 2: lestu hvað VpnService lýsti í raun yfir

Android-hliðin er skýr en ekki ályktuð. VpnService.Builder bætir við vistföngum með addAddress, leiðum með addRoute, DNS-þjónum með addDnsServer, og getur takmarkað allt göngin við eina vistfangafjölskyldu með allowFamily. Byggir sem kallaði á allowFamily(AF_INET) og bætti síðar við IPv6-leið hefur sagt kerfinu tvær mótsagnakenndar staðhæfingar, og fjölskyldutakmörkunin er það sem kerfið heldur. Leið sem nær yfir fd00:61::/64 ásamt viðmótsvistfangi í öðru forskeyti mistekst af svipaðri ástæðu: vistfangið er til, en það er ekki on-link fyrir þá leið.

Lestu yfirlýsinguna í stað þess að treysta rofanum í appinu. dumpsys netd prentar vistföngin og leiðirnar sem eru tengdar tun-viðmótinu, og LinkProperties fyrir hvert net inni í dumpsys connectivity sýnir DNS-listann við hlið þeirra fjölskyldna sem netið segist nota.

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"

Ef tun-viðmótið hefur IPv6-vistfang en engin leið passar við forskeyti þjónustunnar er afhending IPv6 þegar brotin áður en vafri kemur við sögu. Það er önnur villa en vafri sem neitar að prófa, og hún krefst annarrar lagfæringar.

Skref 3: vafrinn ákveður hvort hann prófi IPv6 yfirhöfuð

Chromium notar ekki hverja AAAA-færslu sem það fær. Hýsileysirinn ber IPv6-aðgengisathuganir og síun frambjóðenda sem getur sleppt IPv6 eða lækkað forgang þess þegar netið er metið ófært um að bera það, og frumkóði leysisins sýnir þá könnun ásamt skilyrðunum í kring. Rökfræðin fer eftir útgáfu og flöggum, og þess vegna geta tveir símar í sömu göngum hagað sér á mismunandi hátt. Þegar frambjóðendur eru til staðar lætur Happy Eyeballs fjölskyldurnar keppa fyrir hverja tengingu, svo IPv6-leið sem svarar hægt getur samt tapað fyrir IPv4 sem svarar hratt.

Fylgstu með ákvörðuninni í stað þess að álykta hana. Lotan sem skráð er í gegnum chrome://net-export og spiluð í netlog-skoðaranum sýnir hverja leysingu og valda fjölskyldu; chrome://net-internals/#dns sýnir niðurstöðurnar í skyndiminni. Leysing sem skilar aðeins A-færslum fyrir nafn sem hefur AAAA hjá þínum eigin leysi bendir beint á þetta stig.

Skref 4: sannprófaðu að pakki komist fram og til baka

Vistfangaval er ekki afhending. Android heldur leiðatöflum og stefnureglum fyrir hvert net sem velja töflu eftir fwmark, svo leið sem sést í aðaltöflunni er ekki sjálfkrafa sú leið sem sokkur notar. Að lesa reglurnar og biðja kjarnann að leysa áfangastað fyrir upprunavistfang aðskilur þessi tvö.

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

Það er úttak route get sem svarar spurningunni. Ef það nefnir tun0 og pakkar deyja ennþá skaltu fara í MTU gagnanna og IPv6-framsendingu gáttarinnar í stað þess að snúa aftur til símans.

Hvers vegna að bæta við ::/0 gerir venjulega illa verra

Að bæta við ::/0 breytir kröfu gagnanna úr einu forskeyti í hvern IPv6-áfangastað. Í símanum getur það fullnægt aðgengiskönnun, því prófunarvistfang utan forskeytisins þíns virðist nú leiðanlegt. Það skapar ekki IPv6-afkastagetu uppstreymis í gáttinni, og margar heimagáttir hafa alls enga virka IPv6-uppstreymistengingu. Niðurstaðan er svarthol fyrir opinbert IPv6: nöfn sem áður féllu aftur á IPv4 hanga nú, og einkasíðan gæti virst betri eingöngu vegna þess að könnunin mælir eitthvað annað.

Það er líka stefnukostnaður. Með ::/0 í göngunum fer allur IPv6-umferð út um VPN-ið, þar á meðal umferð sem eigandi netsins samþykkti aldrei að bera. Líttu á það sem uppsetningarákvörðun með nafngreindum eiganda, ekki sem villuleitarþrep sem þú tekur klukkan 1 að nóttu.

Vinnuröðin sem lýkur þessu

Staðfestu að AAAA-svarið komi frá leysinum sem á svæðið, lestu stöðu VpnService og netd fyrir tun-viðmótið, taktu net-export-sneið til að sjá hvort Chromium sleppti frambjóðandanum, og prófaðu síðan ferðina fram og til baka með ip -6 route get. Lagfærðu það lag sem raunverulega brást og lát skiptistefnuna í friði. Ef einkanöfn þurfa önnur svör en opinber nöfn er split tunneling einmitt til þess.

Skráðu byggingu símans, útgáfu vafrans og leysinn sem þú spurðir. Þessar þrjár staðreyndir gera "IPv6 is broken" að einhverju sem næsta manneskja getur endurtekið.