Android emulator at VPN ng host: snapshot ng DNS at NAT

Kapag hindi maabot ng emulator ang isang build server na bukas nang maayos sa browser sa host, ang kapaki-pakinabang na tanong ay hindi kung gumagana ang VPN. Ang tanong ay alin sa dalawang mekanismo ang kulang sa guest. Ang virtual na aparato ay nagpapatakbo ng sarili nitong network stack sa likod ng NAT ng emulator, at ang listahan ng resolver nito ay kopyang kinuha noong boot, kaya ang tunnel na aakyat pagkatapos ay nagbabago ng landas ng host nang hindi binabago ang itinatanong ng guest. Ang pag-unawa sa dalawang antas na ito ay nagpapaliwanag sa halos lahat ng uri ng problemang ito.

Ang guest ay hiwalay na stack sa likod ng fixed na NAT

Inilalagay ng user-mode networking ng QEMU ang guest sa 10.0.2.15 na may gateway sa 10.0.2.2, at ang serbisyo ng DNS sa 10.0.2.3 hanggang 10.0.2.6. Ang palabas na trapiko ng guest ay hindi ipinapasa ng kernel ng host; isinasalin ito sa mga socket sa panig ng host, isa para sa bawat koneksyon ng guest, at ang mga socket na iyon ay lumalabas mula sa address space ng host. Kaya naman ang koneksyon ng guest ay nagmamana ng desisyon sa routing ng host sa sandaling malikha ito, at kaya naman walang entry sa route table ng guest na nagngangalan sa iyong tunnel.

Ang parehong mekanismo ay nagbibigay sa guest ng kapaki-pakinabang na labasan. Ang 10.0.2.2 ay alias ng loopback interface ng host, kaya ang serbisyong nakikinig sa 127.0.0.1 sa laptop ay maabot mula sa guest sa address na iyon. Anumang inilalantad ng kliyente sa loopback lamang ay maabot sa ganitong paraan, at ito ang batayan ng proxy setup na inilalarawan sa ibaba.

Ang hindi kayang gawin ng guest ay obserbahan ang network ng host na parang namespace nito. Walang bridge, walang pinagsasaluhang route table at walang minanang resolver; mayroon lamang ang serbisyo ng NAT na tumatanggap ng mga packet nito at ang snapshot na kinuha ng launcher noong nagsimula ang virtual na aparato.

Ang DNS ay snapshot, hindi live na tanawin

Sa pagsisimula, binabasa ng emulator ang listahan ng resolver ng host at binibigyan ang guest ng hanggang apat na server, na inilalantad sa mga address na 10.0.2.3 hanggang 10.0.2.6. Kung nakababa ang tunnel sa sandaling iyon, ang snapshot ay naglalaman ng pampublikong resolver na ginamit ng laptop, at patuloy itong tinatanong ng guest sa buong buhay nito. Nalutas ang mga pampublikong pangalan, nabibigo ang mga panloob na pangalan, at lahat ng sintomas ay tumuturo sa VPN samantalang ang tunay na lumang halaga ay isang listahan ng resolver na nakuha ilang minuto bago umakyat ang tunnel.

Kaya ang pagwawasto ng pagkakasunod-sunod ay hindi kuwentong bayan. Ikonekta muna ang tunnel, pagkatapos i-restart ang emulator, at piliin ang cold boot kaysa sa pag-restore ng snapshot, dahil ang quick-boot na imahe ay maaaring bumalik kasama ang na-save nang estado ng resolver at ruta. Kung kailangan mong makita ang ginagamit ng guest ngayon, tanungin ang aparato, hindi ang host:

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

Tumatanggap din ang emulator ng tahasang resolver sa paglulunsad, na kapaki-pakinabang kapag alam mo nang eksakto kung aling server ang dapat gamitin ng guest at mapanganib kapag pampubliko ang server na iyon:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Walang kopya ng panloob na zone ang pampublikong resolver, kaya ang pag-pin ng isa ay ginagawang permanenteng pagkabigo ang isang problema sa pagkakasunod-sunod. Kung itinatulak ng profile ang pribadong DNS, hayaan ang tunnel ang magbigay nito at i-cold boot ang guest sa halip na i-hard-code ang address.

Sumusunod ang routing sa host sa oras ng koneksyon

Dahil nagiging socket ng host ang mga koneksyon ng guest, ang desisyon sa routing ay ginagawa kapag nalikha ang socket. Ang tunnel na nakaakyat bago ang kahilingan ay nangangahulugang lumalabas ang kahilingan sa tunnel, alinsunod sa mga ruta ng profile. Ang split-tunnel na profile na nagdadala lamang ng mga piling prefix ay kusang mag-iiwan sa iyong pribadong subnet sa labas, kaya ang maabot ng host ay isang haka-haka tungkol sa guest, hindi resulta. Ang mga umiiral na koneksyon ng guest ay pinapanatili ang landas na ginamit nang malikha, kaya ang kliyenteng muling kumokonekta ay hindi laging nag-aayos ng stuck na download sa loob ng emulator.

Ang beripikasyon ay nasa interface ng host, hindi sa estadistika ng guest:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Kung lumilitaw ang kahilingan ng guest sa interface ng tunnel, gumagana ang routing at ang problema ay nasa itaas nito. Kung lumilitaw ito sa pisikal na interface, hindi sakop ng profile ang prefix na iyon, at walang muling pagkukumpigura sa panig ng guest ang makakabago nito.

Kapag loopback proxy lamang ang iniaalok ng kliyente

Ang ilang komersyal na kliyente ay hindi gumagawa ng system tunnel. Naglalantad sila ng HTTP o SOCKS listener sa 127.0.0.1 at inaasahang gagamitin ito ng mga aplikasyon. Hindi direktang nakikita ng guest ang socket na iyon, ngunit maaaring sabihan ang emulator na gamitin ito, sa pamamagitan ng extended controls (Settings, pagkatapos Proxy, manual mode, host 127.0.0.1 at ang port na ipinapakita ng kliyente) o sa paglulunsad:

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

Kopyahin ang port mula sa window ng kliyente; ang hinulaang port ay tahimik na nabibigo at mukhang sirang tunnel. Tandaan ang sakop nito: ang setting ng HTTP proxy ay iginagalang ng mga aplikasyong may kamalayan sa proxy, at ganap na binabalewala ito ng mga hilaw na socket. Kung ang trabaho ay native binary na nagbubukas ng sarili nitong koneksyon, ang daan ng proxy ay hindi katumbas ng tunnel at ang paghahambing ay dapat gawin nang tahasan.

Patunayan ang resulta mula sa loob ng guest

Paghiwalayin ang paglutas ng pangalan sa routing gamit ang dalawang pagsubok sa parehong sesyon. Ang pangalang nabibigo habang sumasagot ang numerikong address ay problema sa snapshot ng DNS, at ang solusyon ay pagkakasunod-sunod o tahasang resolver. Kung parehong nabibigo, tumuturo ito sa routing o patakaran, at ang susunod na pagsusuri ay kung tumatakbo ang app sa loob ng work profile na may sariling mga paghihigpit sa network.

Panghuli, alamin kung aling guest ang sinusubukan mo. Ang napakalumang emulator image ay inilabas na walang tun support na kailangan ng VPN client sa panig ng guest, kaya walang profile ang maaaring gumana doon; mayroon na ito sa mga kasalukuyang image. Ang kliyenteng nabibigo sa kasalukuyang image ay problema ng kliyente o profile, at ang muling pagbuo ng tunnel ng host ay hindi magbabago ng resulta.