Android emulyatori va xost VPN: DNS snapshot va NAT

Emulyator xostning brauzerida bemalol ochiladigan build serveriga yetib bora olmasa, foydali savol VPN ishlayaptimi degani emas. Savol mehmonga ikki mexanizmdan qaysi biri yetishmayotgani. Virtual qurilma o'z tarmoq stekini emulyator NAT ortida ishga tushiradi va uning resolver ro'yxati boot paytida olingan nusxa, shu sababli keyinroq ko'tarilgan tunnel xost yo'lini o'zgartiradi, lekin mehmon so'rayotgan narsani o'zgartirmaydi. Bu ikki qatlamni tushunish bu muammoning deyarli barcha ko'rinishlarini izohlaydi.

Mehmon qat'iy NAT ortidagi alohida stek

QEMU ning user-mode tarmog'i mehmonni 10.0.2.15 ga, shlyuzni 10.0.2.2 ga va DNS xizmatini 10.0.2.3 dan 10.0.2.6 gacha joylashtiradi. Mehmonning chiquvchi trafigi xost yadrosi tomonidan uzatilmaydi; u xost tomonidagi soketlarga aylanadi, har bir mehmon ulanishi uchun bittadan, va bu soketlar xostning manzil fazosidan chiqadi. Shu sababli mehmon ulanishi yaratilgan lahzada xostning marshrutlash qarorini meros oladi va shu sababli mehmonning route jadvalida sizning tunnelingizni nomlaydigan yozuv yo'q.

Xuddi shu mexanizm mehmonga foydali chiqish yo'lini beradi. 10.0.2.2 xostning loopback interfeysining taxallusi, shuning uchun noutbukda 127.0.0.1 da tinglayotgan xizmatga mehmondan shu manzilda yetib borish mumkin. Mijoz faqat loopbackda ochib beradigan hamma narsaga shu yo'l bilan yetish mumkin va bu quyida tasvirlangan proksi sozlamasining asosi.

Mehmon qila olmaydigan narsa xost tarmog'ini o'zining namespace'i kabi kuzatish. Ko'prik yo'q, umumiy route jadvali yo'q va meros qolgan resolver yo'q; faqat uning paketlarini qabul qiladigan NAT xizmati va virtual qurilma ishga tushganda launcher olgan snapshot bor.

DNS — snapshot, jonli ko'rinish emas

Ishga tushishda emulyator xostning resolver ro'yxatini o'qiydi va mehmonga to'rtagacha server beradi, ular 10.0.2.3 dan 10.0.2.6 gacha manzillarda ochiladi. Agar o'sha paytda tunnel pastda bo'lsa, snapshotda noutbuk ishlatgan ommaviy resolver bo'ladi va mehmon butun umri davomida undan so'raydi. Ommaviy nomlar hal bo'ladi, ichki nomlar muvaffaqiyatsiz bo'ladi va barcha alomatlar VPNga ishora qiladi, holbuki haqiqiy eskirgan qiymat tunnel ko'tarilishidan bir necha daqiqa oldin olingan resolver ro'yxatidir.

Shuning uchun tartibni tuzatish folklor emas. Avval tunnelni ulang, keyin emulyatorni qayta ishga tushiring va snapshotni tiklashdan ko'ra sovuq bootni afzal ko'ring, chunki tez boot obrazi avval saqlangan resolver va route holati bilan qaytishi mumkin. Mehmon hozir nima ishlatayotganini ko'rish kerak bo'lsa, xostdan emas, qurilmadan so'rang:

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

Emulyator ishga tushishda aniq resolverni ham qabul qiladi, bu mehmon qaysi serverni ishlatishi kerakligini aniq bilsangiz foydali va o'sha server ommaviy bo'lsa xavfli:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Ommaviy resolverda ichki zona nusxasi yo'q, shuning uchun bittasini mahkamlash tartib muammosini doimiy nosozlikka aylantiradi. Agar profil shaxsiy DNSni itarib yuborsa, tunnel uni ta'minlasin va manzilni qattiq kodlash o'rniga mehmonni sovuq boot qiling.

Marshrutlash ulanish vaqtida xostga ergashadi

Mehmon ulanishlari xost soketlariga aylangani uchun marshrutlash qarori soket yaratilganda qabul qilinadi. So'rovdan oldin ko'tarilgan tunnel so'rov profiling marshrutlariga bo'ysunib tunneldan chiqishini bildiradi. Faqat tanlangan prefikslarni tashuvchi split-tunnel profili shaxsiy subnettingizni bemalol tashqarida qoldiradi, shuning uchun xostga yetish imkoniyati mehmon haqidagi faraz, natija emas. Mavjud mehmon ulanishlari yaratilgan yo'lni saqlaydi, shu sababli qayta ulanadigan mijoz emulyatorda qotib qolgan yuklab olishni har doim ham tuzatmaydi.

Tekshirish xost interfeysida, mehmon statistikasida emas:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Agar mehmon so'rovi tunnel interfeysida ko'rinsa, marshrutlash ishlayapti va muammo uning ustida. Agar u jismoniy interfeysda ko'rinsa, profil bu prefiksni qamrab olmaydi va mehmon tomonidagi hech qanday qayta sozlash buni o'zgartirmaydi.

Mijoz faqat loopback proksi taklif qilganda

Ba'zi tijoriy mijozlar tizim tunnelini umuman yaratmaydi. Ular 127.0.0.1 da HTTP yoki SOCKS tinglovchisini ochib, ilovalar undan foydalanadi deb kutadilar. Mehmon bu soketni bevosita ko'rmaydi, lekin emulyatorga undan foydalanishni aytish mumkin, yo kengaytirilgan boshqaruvlar orqali (Settings, keyin Proxy, qo'lda rejim, xost 127.0.0.1 va mijoz chop etgan port) yo ishga tushishda:

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

Portni mijoz oynasidan nusxalang; taxmin qilingan port jimgina muvaffaqiyatsiz bo'ladi va buzilgan tunnelga o'xshaydi. Bu nima bilan qoplanishini yodda tuting: HTTP proksi sozlamasini proksini biladigan ilovalar hurmat qiladi, xom soketlar esa uni butunlay e'tiborsiz qoldiradi. Agar ish yuki o'z ulanishlarini ochadigan native binary bo'lsa, proksi yo'li tunnelga teng emas va taqqoslashni aniq amalga oshirish kerak.

Natijani mehmon ichidan isbotlang

Bir sessiyada ikkita test bilan hal qilishni marshrutlashdan ajrating. Raqamli manzil javob berayotganda nom muvaffaqiyatsiz bo'lsa, bu DNS snapshot muammosi va yechim tartib yoki aniq resolver. Ikkalasi ham muvaffaqiyatsiz bo'lsa, bu marshrutlash yoki siyosatga ishora qiladi va keyingi tekshiruv ilova o'z tarmoq cheklovlari bo'lgan ish profilida ishlayaptimi.

Nihoyat, qaysi mehmonda sinov o'tkazayotganingizni biling. Juda eski emulyator obrazlari mehmon tomonidagi VPN mijozi uchun zarur bo'lgan tun qo'llab-quvvatlashisiz chiqarilgan, shuning uchun u yerda hech qanday profil ishlay olmagan; hozirgi obrazlarda u bor. Hozirgi obrazda muvaffaqiyatsiz bo'lgan mijoz uchun bu holat mijoz yoki profil muammosidir, xost tunnelini qayta qurish esa natijani o'zgartirmaydi.