Android VPN IPv6 සමඟ ක්‍රියා කරයි, නමුත් බ්‍රවුසරය තවමත් IPv4 තෝරයි

VPN ක්‍රියාත්මකයි, පුද්ගලික වෙබ් UI ලැප්ටොප් එකකින් 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 කිසිදා සඳහන් නොවේ.

වෙනත් කිසිවක් වෙනස් කිරීමට පෙර උමංගේ විසඳන්නාගෙන් කෙලින්ම අසන්න. පළමු විධාන දෙක පෙන්වන්නේ Android ක්‍රියාකාරී ජාලයට සම්බන්ධ කළ DNS සේවාදායක මොනවාද සහ 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 මගින් මාර්ග, addDnsServer මගින් DNS සේවාදායක එකතු කරයි, සහ allowFamily මගින් මුළු උමං එකම ලිපින පවුලකට සීමා කළ හැක. allowFamily(AF_INET) අමතා පසුව IPv6 මාර්ගයක් එකතු කළ ගොඩනන්නා පද්ධතියට පරස්පර දේවල් දෙකක් කීවේය, පද්ධතිය රඳවා ගන්නේ පවුල් සීමාවයි. fd00:61::/64 ආවරණය කරන මාර්ගයක් වෙනත් උපසර්ගයක අතුරුමුහුණත් ලිපිනයක් සමඟ එක් වූ විට එම හේතුව නිසාම අසාර්ථක වේ: ලිපිනය පවතී, නමුත් එම මාර්ගයට එය on-link නොවේ.

යෙදුමේ ටොගලය විශ්වාස කරනවා වෙනුවට ප්‍රකාශය කියවන්න. dumpsys netd tun අතුරුමුහුණතට සම්බන්ධ ලිපින සහ මාර්ග මුද්‍රණය කරයි, dumpsys connectivity තුළ ජාලය අනුව LinkProperties ජාලය ප්‍රකාශ කරන පවුල් අසල 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 හැඹිලිගත ප්‍රතිඵල පෙන්වයි. ඔබේම විසඳන්නා තුළ AAAA ඇති නාමයකට A වාර්තා පමණක් ලබා දෙන විසඳුමක් කෙලින්ම මෙම අදියරට යොමු කරයි.

පියවර 4: පැකට්ටුවකට යාම-ඒම කළ හැකිදැයි තහවුරු කරන්න

ලිපිනය තේරීම බෙදාහැරීම නොවේ. Android ජාලය අනුව ගමන් මාර්ග වගු සහ fwmark මගින් වගුවක් තෝරන ප්‍රතිපත්ති නීති රඳවා ගනී, එබැවින් ප්‍රධාන වගුවේ පෙනෙන මාර්ගය සොකට් එකක් භාවිත කරන මාර්ගය යැයි අනුමාන කළ නොහැක. නීති කියවීම සහ මූල ලිපිනයක් සඳහා ගමනාන්තය විසඳීමට කර්නලයට කීම මේ දෙක වෙන් කරයි.

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 පිළිතුර කලාපය හිමි විසඳන්නාගෙන් පැමිණෙන බව තහවුරු කරන්න, tun අතුරුමුහුණත සඳහා VpnService සහ netd තත්ත්වය කියවන්න, Chromium අපේක්ෂකයා ඉවත් කළේදැයි බැලීමට net-export ලකුණක් ගන්න, පසුව ip -6 route get සමඟ යාම-ඒම පරීක්ෂා කරන්න. සැබවින්ම අසාර්ථක වූ ස්තරය නිවැරදි කර බෙදුම් ප්‍රතිපත්තිය එලෙසම තබන්න. පුද්ගලික නාමවලට පොදු නාමවලට වඩා වෙනස් පිළිතුරු අවශ්‍ය නම් split tunneling ඒ සඳහාය.

දුරකථනයේ build, බ්‍රවුසර අනුවාදය සහ ඔබ විමසූ විසඳන්නා සටහන් කරන්න. එම කරුණු තුන "IPv6 is broken" ඊළඟ පුද්ගලයාට නැවත නිපදවිය හැකි දෙයක් බවට පත් කරයි.