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-ով՝ երթուղիներ, 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 պատասխանը գալիս է այն լուծիչից, որը տիրապետում է գոտուն, կարդացեք VpnService-ի և netd-ի վիճակը tun ինտերֆեյսի համար, վերցրեք net-export հետք՝ տեսնելու, թե արդյոք Chromium-ը դեն նետեց թեկնածուին, ապա ստուգեք ետ ու առաջ ճանապարհը ip -6 route get-ով։ Ուղղեք այն շերտը, որն իսկապես ձախողվեց, և թողեք բաժանման քաղաքականությունը հանգիստ։ Եթե մասնավոր անուններին պետք են տարբեր պատասխաններ, քան հանրայիններին, հենց դրա համար է split tunneling-ը։

Գրանցեք հեռախոսի build-ը, զննարկիչի տարբերակը և այն լուծիչը, որին հարցրել եք։ Այս երեք փաստերը "IPv6 is broken" արտահայտությունը դարձնում են մի բան, որը հաջորդ մարդը կարող է վերարտադրել։