Android-Emulator an Host-VPN: DNS-Snapshot an NAT erkläert

Wann den Emulator e Build-Server net erreecht, deen den Host-Browser awer gutt opmécht, ass déi nëtzlech Fro net, ob d'VPN funktionéiert. D'Fro ass, wéi vun den zwou Mechanismen dem Guest feelt. Dat virtuellt Gerät bedreift säin eegene Netzwierk-Stack hannert dem Emulator-NAT, an seng Resolver-Lëscht ass eng Kopie, déi beim Boot geholl gëtt, dofir ännert en Tunnel, deen duerno opkënnt, de Wee vum Host, awer net dat, wat de Guest freet. Dës zwou Schichten ze verstoen erkläert bal all Variant vun dësem Problem.

De Guest ass en eegene Stack hannert engem fixen NAT

QEMU seng User-Mode-Netzwierk setzt de Guest op 10.0.2.15 mat engem Gateway op 10.0.2.2, an den DNS-Service op 10.0.2.3 bis 10.0.2.6. Ausgehend Traffic vum Guest gëtt net vum Host-Kernel weidergereicht; en gëtt a Sockets op der Hostsäit iwwersat, een pro Guest-Verbindung, an déi Sockets verloossen den Adressraum vum Host. Dofir ierft eng Guest-Verbindung d'Routing-Entscheedung vum Host am Moment wou se entsteet, an dofir huet de Guest keen Entrée an der Route-Tabell, deen däin Tunnel nennt.

Deen selwechte Mechanismus gëtt dem Guest eng nëtzlech Ausgangsdier. 10.0.2.2 ass en Alias fir dem Host seng Loopback-Interface, dofir ass e Service, deen um Laptop op 127.0.0.1 lauschtert, vum Guest iwwer déi Adress erreechbar. Alles, wat de Client nëmmen um Loopback exponéiert, ass esou erreechbar, an dat ass d'Basis fir d'Proxy-Ariichtung, déi ënnen beschriwwe gëtt.

Wat de Guest net kann, ass d'Netzwierk vum Host ze observéieren, wéi wann et säin Namespace wier. Et gëtt keng Bridge, keng gedeelt Route-Tabell an keen ierflichte Resolver, just den NAT-Service, deen seng Pakete unhëlt, an de Snapshot, deen de Launcher beim Start vum virtuelle Gerät geholl huet.

DNS ass en Snapshot, keng live Vue

Beim Start liest den Emulator d'Resolver-Lëscht vum Host an gëtt dem Guest bis zu véier Serveren, déi op den Adressen 10.0.2.3 bis 10.0.2.6 exponéiert sinn. Wann den Tunnel deem Moment ënnen war, enthält den Snapshot dee public Resolver, deen de Laptop benotzt huet, an de Guest freet en säi ganzt Liewe laang weider. Public Nimm ginn opgeléist, intern Nimm schloen fehl, an all Symptom weist op d'VPN, woubäi de richteg al Wäert eng Resolver-Lëscht ass, déi e puer Minutten ier den Tunnel opkënnt festgehale gouf.

D'Korrektur vun der Rei ass also keng Folklore. Verbann d'éischt den Tunnel, start dann den Emulator nei, a bezéi e Cold Boot virun enger Snapshot-Restauratioun, well e Quick-Boot-Image mat dem Resolver- an Route-Zoustand zréckkomme kann, deen et virdrun gespäichert huet. Wann een gesi wëllt, wat de Guest grad benotzt, freet een d'Gerät an net den Host:

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

Den Emulator akzeptéiert beim Start och en explizite Resolver, wat nëtzlech ass, wann een genee weess, wéi ee Server de Guest benotze soll, a geféierlech, wann dee Server public ass:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

En public Resolver huet keng Kopie vun enger interner Zone, dofir mécht een ze pinnen aus engem Rei-Problem en dauerhafte Feeler. Wann de Profil privaten DNS dréckt, loos den Tunnel en ginn an maach e Cold Boot vum Guest, amplaz eng Adress haart ze kodéieren.

Routing follegt dem Host beim Verbindungsopbau

Well Guest-Verbindungen zu Host-Sockets ginn, gëtt d'Routing-Entscheedung getraff, wann de Socket entsteet. Tunnel u virun der Ufro heescht, d'Ufro geet duerch den Tunnel eraus, ënnerlecht de Route vum Profil. En Split-Tunnel-Profil, deen nëmmen ausgewielt Prefixer dréit, léisst däi private Subnet gären dobaussen, dofir ass d'Erreechbarkeet vum Host eng Hypothese iwwer de Guest, keen Resultat. Bestehend Guest-Verbindungen halen de Wee, mat deem se erstallt goufen, dofir fixéiert en Client, deen sech nei verbënnt, net ëmmer en Download, deen am Emulator hänkt.

D'Iwwerpréiwung gehéiert op d'Interface vum Host, net an d'Statistik vum Guest:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Wann d'Ufro vum Guest op der Tunnel-Interface erschéngt, funktionéiert Routing a läit d'Problem driwwer. Erschéngt se op der physescher Interface, deckt de Profil dee Prefix net, an deng Rekonfiguratioun op der Guestsäit ännert dat net.

Wann de Client nëmmen e Loopback-Proxy ubitt

E puer kommerziell Clienten erstellen iwwerhaapt keen System-Tunnel. Si exponéieren en HTTP- oder SOCKS-Listener op 127.0.0.1 an erwaarden, datt d'Applikatiounen en benotzen. De Guest gesäit dee Socket net direkt, awer den Emulator kann ugewisen ginn, en ze benotzen, entweder iwwer d'extended controls (Settings, dann Proxy, manuellen Modus, Host 127.0.0.1 an de Port, deen de Client uweist) oder beim Start:

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

Kopéier de Port aus dem Client-Fenster; e geratene Port schléit stëll fehl a gesäit aus wéi en ugeléckten Tunnel. Denk drun, wat dat deckt: eng HTTP-Proxy-Astellung gëtt vun Applikatiounen, déi Proxy kennen, respektéiert, a rohe Sockets ignoréieren se komplett. Wann d'Belaaschtung eng native Binary ass, déi hir eege Verbindungen opmécht, ass de Proxy-Wee net gläichwäerteg mat engem Tunnel an de Verglach muss explizit gemaach ginn.

Beweis d'Resultat aus dem Guest eraus

Trenn Resolutioun vum Routing mat zwou Tester an der selwechter Sitzung. En Numm, deen ausfällt, wärend d'numeresch Adress äntwert, ass e DNS-Snapshot-Problem, an d'Léisung ass d'Rei oder en explizite Resolver. Falen allebéid, weist dat op Routing oder Politik, an déi nächst Kontroll ass, ob d'App an engem Work Profile mat sengen eegene Netzwierkrestriktioune leeft.

Als lescht: wëss, op wéi engem Guest s de testen. Ganz al Emulator-Images koumen ouni d'tun-Ënnerstëtzung, déi e VPN-Client op der Guestsäit brauch, dofir konnt do keen Profil jee funktionéieren; aktuell Images hunn se. En Client, deen op engem aktuelle Bild ausfällt, ass e Client- oder Profilproblem, an den Host-Tunnel nei ze bauen ännert d'Resultat net.