Android эмулятору жана хосттогу VPN: DNS snapshot жана NAT

Эмулятор хосттун браузеринде жакшы ачылып жаткан build-серверге жете албаганда, пайдалуу суроо VPN иштеп жатабы дегени эмес. Суроо guestке эки механизмдин кайсынысы жетишпейт дегени. Виртуалдык түзмөк өзүнүн тармак stackин эмулятордун NATынын артында жүргүзөт, ал эми анын resolver тизмеси boot учурунда алынган көчүрмө, ошондуктан кийин көтөрүлгөн туннель хосттун жолун өзгөртөт, бирок 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и forward кылбайт; ал хост тараптагы socketтерге айланат, ар бир guest байланышына бирден, жана бул socketтер хосттун дарек мейкиндигинен чыгат. Ошондуктан guest байланышы түзүлгөн учурда хосттун routing чечимин мураска алат, жана ошондуктан guestтин route таблицасында сиздин туннелди атаган жазуу жок.

Ушундай эле механизм 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 даректеринде ачылат. Эгер ошол учурда туннель төмөн болсо, snapshotта ноутбук колдонгон public resolver болот, жана guest өмүрүнүн акырына чейин андан сурай берет. Public аттар чечилет, ички аттар ийгиликсиз болот, жана бардык симптомдор VPNди көрсөтөт, бирок чыныгы эскирген маани — туннель көтөрүлүүдөн бир нече мүнөт мурун алынган resolver тизмеси.

Ошондуктан иретти оңдоо фольклор эмес. Адегенде туннелди туташтырыңыз, анан эмуляторду кайра баштаңыз, жана 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дун көчүрмөсү жок, ошондуктан бирөөнү бекитүү ирет маселесин туруктуу бузулууга айландырат. Эгер profile private DNS таратса, аны туннель берсин жана даректи катуу жазуунун ордуна guestти cold boot кылыңыз.

Routing байланыш учурунда хостко ээрчийт

Guest байланыштары хосттун socketтерине айлангандыктан, routing чечими socket түзүлгөндө кабыл алынат. Сурамга чейин көтөрүлгөн туннель сурамдын profile routeлоруна ылайык туннелден чыгарын билдирет. Тандалган prefixтерди гана ташыган split-tunnel profile сиздин private subnetти сыртта калтырат, ошондуктан хостко жетүү мүмкүнчүлүгү guest жөнүндө божомол, натыйжа эмес. Бар guest байланыштары түзүлгөн жолун сактайт, ошондуктан кайра туташкан client эмулятордогу токтоп калган жүктөөнү ар дайым оңдобойт.

Текшерүү хосттун интерфейсинде, guest статистикасында эмес:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Эгер guest сурамы туннелдин интерфейсинде көрүнсө, routing иштеп жатат жана маселе анын үстүндө. Эгер ал физикалык интерфейсте көрүнсө, profile ошол prefixти камтыбайт, жана guest тараптагы эч кандай кайра конфигурациялоо аны өзгөртпөйт.

Client loopback proxy гана сунуштаганда

Айрым коммерциялык clientтер system 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 үнсүз ийгиликсиз болуп, сынган туннелге окшошот. Бул эмнени камтый турганын эсиңизде тутуңуз: HTTP proxy жөндөөсүн proxyни тааныган колдонмолор сыйлайт, ал эми чийки socketтер аны таптакыр этибарга албайт. Эгер жумуш өз байланыштарын ачкан native binary болсо, proxy жолу туннелге барабар эмес жана салыштырууну ачык жүргүзүү керек.

Натыйжаны guestтин ичинен далилдеңиз

Бир сессияда эки тест менен resolutionды routingден бөлүңүз. Сандык дарек жооп берип, ат ийгиликсиз болсо — бул DNS snapshot маселеси, ал эми чечим ирет же ачык resolver. Экөө тең ийгиликсиз болсо routing же policyни көрсөтөт, жана кийинки текшерүү — колдонмо өзүнүн тармактык чектөөлөрү бар work profile ичинде иштеп жатабы.

Акырында, кайсы guestте текшерип жатканыңызды билиңиз. Абдан эски эмулятор образдары guest тараптагы VPN clientке керек tun колдоосуз чыгарылган, ошондуктан ал жерде эч бир profile иштей алган эмес; учурдагы образдарда ал бар. Учурдагы образда ийгиликсиз болгон client — client же profile маселеси, жана хосттун туннелин кайра куруу натыйжаны өзгөртпөйт.