Android emulator i VPN na hostu: DNS snapshot i NAT

Kada emulator ne može da dosegne build server koji pretraživač na hostu otvara bez problema, korisno pitanje nije da li VPN radi. Pitanje je koji od dva mehanizma nedostaje gostu. Virtuelni uređaj pokreće sopstveni mrežni stek iza NAT-a emulatora, a njegova lista resolvera je kopija napravljena pri boot-u, pa tunel koji se podigne kasnije menja putanju hosta, ali ne menja ono što gost pita. Razumevanje ova dva sloja objašnjava skoro svaku varijantu ovog problema.

Gost je odvojeni stek iza fiksnog NAT-a

QEMU mreža u korisničkom režimu postavlja gosta na 10.0.2.15 sa gateway-om na 10.0.2.2, a DNS servis na 10.0.2.3 do 10.0.2.6. Izlazni saobraćaj gosta ne prosleđuje kernel hosta; on se prevodi u socket-e na strani hosta, po jedan za svaku vezu gosta, i ti socket-i izlaze iz adresnog prostora hosta. Zato veza gosta nasleđuje routing odluku hosta u trenutku kada nastaje, i zato gost nema unos u route tabeli koji imenuje vaš tunel.

Isti mehanizam daje gostu koristan izlaz. 10.0.2.2 je alias za loopback interfejs hosta, pa je servis koji sluša na 127.0.0.1 na laptopu dostupan iz gosta na toj adresi. Sve što klijent izlaže samo na loopback-u može se dosegnuti tim putem, i to je osnova proxy postavke opisane niže.

Ono što gost ne može jeste da posmatra mrežu hosta kao da je njen namespace. Nema bridge-a, nema deljene route tabele i nema nasleđenog resolvera; postoji samo NAT servis koji prihvata njegove pakete i snapshot koji je launcher napravio kada je virtuelni uređaj pokrenut.

DNS je snapshot, a ne živi prikaz

Pri pokretanju emulator čita listu resolvera hosta i daje gostu do četiri servera, izložena na adresama 10.0.2.3 do 10.0.2.6. Ako je tunel u tom trenutku bio spušten, snapshot sadrži onaj javni resolver koji je laptop koristio, i gost ga pita celog života. Javna imena se rešavaju, interna imena padaju, i svi simptomi pokazuju na VPN, dok je stvarna zastarela vrednost lista resolvera zabeležena nekoliko minuta pre nego što se tunel podigao.

Zato ispravka redosleda nije folklor. Prvo povežite tunel, zatim ponovo pokrenite emulator, i dajte prednost hladnom boot-u umesto vraćanja snapshot-a, jer quick-boot slika može da se vrati sa ranije sačuvanim stanjem resolvera i ruta. Ako treba da vidite šta gost trenutno koristi, pitajte uređaj, a ne host:

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

Emulator prihvata i eksplicitni resolver pri pokretanju, što je korisno kada tačno znate koji server gost treba da koristi, a opasno kada je taj server javni:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Javni resolver nema kopiju interne zone, pa prikivanje jednog pretvara problem redosleda u trajni neuspeh. Ako profil gura privatni DNS, pustite tunel da ga obezbedi i hladno bootujte gosta umesto da hardkodujete adresu.

Routing prati host u trenutku veze

Pošto veze gosta postaju socket-i hosta, routing odluka se donosi kada se socket stvori. Tunel podignut pre zahteva znači da zahtev izlazi kroz tunel, u skladu sa rutama profila. Split-tunnel profil koji nosi samo izabrane prefikse rado će ostaviti vašu privatnu podmrežu napolju, pa je dostupnost hosta hipoteza o gostu, a ne rezultat. Postojeće veze gosta zadržavaju putanju sa kojom su stvorene, zato klijent koji se ponovo povezuje ne popravlja uvek zaglavljeno preuzimanje u emulatoru.

Provera pripada interfejsu hosta, a ne statistici gosta:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Ako se zahtev gosta pojavi na interfejsu tunela, routing radi i problem je iznad njega. Ako se pojavi na fizičkom interfejsu, profil ne pokriva taj prefiks, i nikakvo rekonfigurisanje na strani gosta to neće promeniti.

Kada klijent nudi samo loopback proxy

Neki komercijalni klijenti uopšte ne prave sistemski tunel. Izlažu HTTP ili SOCKS listener na 127.0.0.1 i očekuju da ga aplikacije koriste. Gost ne vidi taj socket direktno, ali emulatoru se može reći da ga koristi, bilo kroz proširene kontrole (Settings, zatim Proxy, ručni režim, host 127.0.0.1 i port koji klijent ispiše) bilo pri pokretanju:

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

Kopirajte port iz prozora klijenta; pogođeni port tiho pada i izgleda kao pokvaren tunel. Imajte na umu šta ovo pokriva: podešavanje HTTP proxy-ja poštuju aplikacije koje znaju za proxy, a sirovi socket-i ga potpuno ignorišu. Ako je radni teret native binary koji otvara sopstvene veze, proxy put nije ekvivalentan tunelu i poređenje mora da se uradi eksplicitno.

Dokažite rezultat iz unutrašnjosti gosta

Razdvojite rešavanje imena od routinga sa dva testa u istoj sesiji. Ime koje pada dok numerička adresa odgovara je problem DNS snapshot-a, a rešenje je redosled ili eksplicitni resolver. Ako oba padnu, to ukazuje na routing ili politiku, i sledeća provera je da li aplikacija radi u radnom profilu sa sopstvenim mrežnim ograničenjima.

Na kraju, znajte na kom gostu testirate. Veoma stare slike emulatora su isporučivane bez tun podrške koja je potrebna VPN klijentu na strani gosta, pa nijedan profil tamo nije mogao da radi; aktuelne slike je imaju. Klijent koji pada na aktuelnoj slici je problem klijenta ili profila, i ponovno pravljenje tunela hosta neće promeniti ishod.