Android эмулятор ба хост VPN: DNS snapshot ба NAT-ын тайлбар

Эмулятор хост компьютерийн хөтчөөр хэвийн нээгддэг build серверт хүрч чадахгүй байх үед хэрэгтэй асуулт нь VPN ажиллаж байгаа эсэх биш. Гэсэн хоёр механизмын аль нь guest-д дутагдаж байна вэ гэдэг асуулт юм. Виртуал төхөөрөмж эмуляторын NAT-ын ард өөрийн сүлжээний stack-ийг ажиллуулдаг ба түүний resolver жагсаалт нь boot хийх үед авсан хуулбар тул дараа нь өргөгдсөн tunnel хост компьютерийн замыг өөрчилдөг ч guest-ийн асуудаг зүйлийг өөрчилдөггүй. Энэ хоёр давхаргыг ойлгох нь энэ асуудлын бараг бүх хувилбарыг тайлбарладаг.

Guest бол тогтмол NAT-ын ард байгаа тусдаа stack

QEMU-гийн user-mode сүлжээ guest-ийг 10.0.2.15 дээр, gateway-г 10.0.2.2 дээр, DNS үйлчилгээг 10.0.2.3-аас 10.0.2.6 хүртэл байрлуулна. Guest-ийн гадагш гарч буй трафикийг хост компьютерийн kernel дамжуулдаггүй; тэр нь хост талын socket болж хувирдаг, guest-ийн холболт бүрд нэг, тэдгээр socket нь хост компьютерийн хаягийн орон зайгаас гардаг. Тиймээс guest-ийн холболт үүсэх мөчид хост компьютерийн routing шийдвэрийг өвлөдөг, тиймээс guest-ийн route хүснэгтэд таны tunnel-ийг нэрлэсэн бичлэг байхгүй.

Мөн механизм guest-д хэрэгтэй гарц өгдөг. 10.0.2.2 нь хост компьютерийн loopback интерфэйсийн alias тул зөөврийн компьютер дээрх 127.0.0.1 дээр сонсож байгаа үйлчилгээнд guest-ээс тэр хаягаар хүрэх боломжтой. Client зөвхөн loopback дээр ил гаргасан бүхэнд энэ замаар хүрч болох бөгөөд энэ нь доор тайлбарласан proxy тохиргооны үндэс юм.

Guest хийж чадахгүй зүйл бол хост компьютерийн сүлжээг өөрийн namespace мэт ажиглах явдал юм. Bridge байхгүй, хуваалцсан route хүснэгт байхгүй, өвлөгдсөн resolver байхгүй; зөвхөн түүний packet-уудыг хүлээн авдаг NAT үйлчилгээ болон виртуал төхөөрөмж эхлэх үед launcher-ийн авсан snapshot л байна.

DNS бол snapshot, амьд харагдац биш

Эхлэх үед эмулятор хост компьютерийн resolver жагсаалтыг уншиж guest-д дөрөв хүртэл сервер өгдөг, тэдгээр нь 10.0.2.3-аас 10.0.2.6 хаягуудад ил гардаг. Тухайн үед tunnel доош байсан бол snapshot-д зөөврийн компьютер ашигласан аль нэг public resolver байх бөгөөд guest насан туршдаа түүнээс асууж байна. Public нэрс шийдэгддэг, дотоод нэрс бүтэлгүйтдэг, бүх шинж тэмдэг VPN-ийг заадаг боловч жинхэнэ хуучирсан утга нь tunnel өргөгдөхөөс хэдэн минутын өмнө авсан resolver жагсаалт юм.

Тиймээс дарааллыг засах нь домог биш. Эхлээд tunnel-ийг холбоод дараа нь эмуляторыг дахин эхлүүлээрэй, мөн snapshot сэргээхээс илүү cold boot-ыг сонгоорой, учир нь quick-boot образ өмнө хадгалсан resolver болон route-ийн төлөвтэйгөөр буцаж ирж болно. Guest одоо юу ашиглаж байгааг харах бол хост компьютерээс биш, төхөөрөмжөөс асуугаарай:

adb shell dumpsys connectivity | grep -i -A2 dns
adb shell ping -c 1 build.internal.example

Эмулятор эхлэх үед тодорхой resolver-ийг ч хүлээн авдаг, энэ нь guest аль серверийг ашиглах ёстойг яг мэдэж байхад хэрэгтэй, харин тэр сервер public бол аюултай:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Public resolver-д дотоод zone-ийн хуулбар байхгүй тул нэгийг нь бэхлэх нь дарааллын асуудлыг байнгын бүтэлгүйтэл болгоно. Профайл private DNS түлхэж байвал tunnel-ийг нь нийлүүлээрэй, хаягийг хатуу бичихийн оронд guest-ийг cold boot хийнэ үү.

Routing холболтын үед хост компьютерийг дагадаг

Guest-ийн холболтууд хост компьютерийн socket болдог тул routing шийдвэрийг socket үүсэх үед гаргадаг. Хүсэлтээс өмнө tunnel өргөгдсөн байх нь хүсэлт профайлын route-уудад захирагдаж tunnel-ээр гарна гэсэн үг. Зөвхөн сонгосон prefix-үүдийг зөөдөг split-tunnel профайл таны private subnet-ийг гадна үлдээх тул хост компьютерт хүрэх боломж нь guest-ийн тухай таамаг болохоос үр дүн биш. Одоо байгаа guest холболтууд үүссэн замаа хадгалдаг, тиймээс дахин холбогддог client эмулятор дотор гацсан таталтыг үргэлж засдаггүй.

Шалгалт нь хост компьютерийн интерфэйс дээр, guest-ийн статистик дотор биш:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Guest-ийн хүсэлт tunnel-ийн интерфэйс дээр гарч ирвэл routing ажиллаж байгаа бөгөөд асуудал түүний дээр байна. Хэрэв физик интерфэйс дээр гарч ирвэл профайл тэр prefix-ийг хамардаггүй бөгөөд guest талын ямар ч дахин тохиргоо үүнийг өөрчлөхгүй.

Client зөвхөн loopback proxy санал болгох үед

Зарим арилжааны client нь системийн tunnel огт үүсгэдэггүй. Тэд 127.0.0.1 дээр HTTP эсвэл SOCKS listener ил гаргаж, апп-ууд түүнийг ашиглана гэж хүлээдэг. Guest тэр socket-ийг шууд харж чадахгүй ч эмуляторт ашиглахыг зааж болно, эсвэл extended controls-оор (Settings, дараа нь Proxy, manual mode, host 127.0.0.1 болон client-ийн хэвлэсэн port) эсвэл эхлэх үед:

emulator -avd Pixel_API_34 -http-proxy http://127.0.0.1:8080

Port-ыг client-ийн цонхноос хуулбарлаарай; таамагласан port чимээгүй бүтэлгүйтэж эвдэрсэн tunnel мэт харагдана. Энэ юуг хамардагийг санаарай: HTTP proxy тохиргоог proxy мэддэг апп-ууд хүндэтгэдэг, харин түүхий socket-ууд үүнийг бүрэн үл тоомсорлодог. Ачаалал нь өөрийн холболтыг нээдэг native binary бол proxy-ийн зам tunnel-тэй тэнцүү биш бөгөөд харьцуулалтыг тодорхой хийх ёстой.

Үр дүнг guest-ийн дотроос батлаарай

Нэг session дотор хоёр тестээр resolution-ыг routing-оос тусгаарлаарай. Тоон хаяг хариулж байхад нэр бүтэлгүйтвэл энэ нь DNS snapshot-ийн асуудал бөгөөд шийдэл нь дараалал эсвэл тодорхой resolver юм. Хоёулаа бүтэлгүйтвэл routing эсвэл policy-г заана, дараагийн шалгалт нь апп өөрийн сүлжээний хязгаарлалттай work profile дотор ажиллаж байгаа эсэх юм.

Эцэст нь, аль guest дээр туршиж байгаагаа мэдээрэй. Маш хуучин эмуляторын образнууд guest талын VPN client-д хэрэгтэй tun дэмжлэггүйгээр гарсан тул тэнд ямар ч профайл ажиллаж чадаагүй; одоогийн образнууд үүнийг агуулдаг. Одоогийн образ дээр бүтэлгүйтэж буй client нь client эсвэл профайлын асуудал бөгөөд хост компьютерийн tunnel-ийг дахин барих нь үр дүнг өөрчлөхгүй.