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 огт дурдагдахгүй.

Өөр юу ч өөрчлөхөөс өмнө туннелийн шийдэгчээс шууд асуугаарай. Эхний хоёр команд нь 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" гэдгийг дараагийн хүн давтаж чадах зүйл болгоно.