Android emulator i VPN na hostu: DNS snimak i objašnjenje NAT-a

Kada emulator ne može doći do build servera koji host pretraživač otvara bez problema, korisno pitanje nije radi li VPN. Nego koji od dva mehanizma gostu nedostaje. Virtuelni uređaj pokreće vlastiti mrežni stek iza NAT-a emulatora, i njegova lista resolvera je kopija uzeta pri podizanju, pa tunel koji se podigne kasnije mijenja putanju hosta, ali ne mijenja ono što gost pita. Razumijevanje ta dva sloja objašnjava gotovo svaku varijantu ovog problema.

Gost je odvojen stek iza fiksnog NAT-a

QEMU mreža u korisničkom režimu stavlja gosta na 10.0.2.15, gateway na 10.0.2.2, a DNS servis na 10.0.2.3 do 10.0.2.6. Odlazni saobraćaj gosta ne prosljeđuje kernel hosta; on se prevodi u sockete na strani hosta, po jedan za svaku vezu gosta, i ti sockete izlaze iz adresnog prostora hosta. Zato veza gosta nasljeđuje odluku o rutiranju hosta u trenutku nastanka i zato gost nema unos u tablici rutiranja 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 loopbacku može se tako dosegnuti, i to je osnova proxy postavke opisane niže.

Ono što gost ne može jest posmatrati mrežu hosta kao da je imenski prostor na njoj. Nema mosta, nema zajedničke tablice rutiranja i nema naslijeđenog resolvera, samo NAT servis koji prihvata njegove pakete i snimak koji je pokretač napravio pri startu virtuelnog uređaja.

DNS je snimak, a ne živi prikaz

Pri startu 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 tada bio isključen, snimak sadrži bilo koji javni resolver koji je laptop koristio, a gost ga pita do kraja života. Javna imena se razrješavaju, interna ne, i svaki simptom pokazuje na VPN dok je stvarna zastarjela vrijednost lista resolvera zabilježena minutama prije nego što se tunel podigao.

Zato popravka redoslijedom nije folklor. Prvo povežite tunel, zatim restartujte emulator i dajte prednost hladnom podizanju nad vraćanjem snimka, jer slika brzog podizanja može se vratiti sa stanjem resolvera i ruta koje je ranije sačuvala. Ako trebate vidjeti š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 koristiti, 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 redoslijeda u trajni neuspjeh. Ako profil gura privatni DNS, pustite tunel da ga osigura i hladno podignite gosta umjesto da hardkodirate adresu.

Rutiranje slijedi host u trenutku veze

Pošto veze gosta postaju sockete hosta, odluka o rutiranju donosi se pri stvaranju socketa. Tunel prije zahtjeva znači da zahtjev izlazi kroz tunel prema rutama profila. Profil sa podijeljenim tunelom koji nosi samo odabrane prefikse rado će ostaviti vašu privatnu podmrežu vani, pa je dostupnost hosta hipoteza o gostu, a ne rezultat. Postojeće veze gosta zadržavaju putanju s kojom su stvorene, zato klijent koji se ponovo poveže ne popravlja uvijek zaglavljeno preuzimanje u emulatoru.

Provjera pripada interfejsu hosta, a ne statistici gosta:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Ako se zahtjev gosta pojavi na tunel interfejsu, rutiranje 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 promijeniti.

Kada klijent nudi samo loopback proxy

Neki komercijalni klijenti uopšte ne stvaraju sistemski tunel. Izlažu HTTP ili SOCKS slušač na 127.0.0.1 i očekuju da ga aplikacije koriste. Gost ne može vidjeti taj socket direktno, ali emulatoru se može reći da ga koristi, bilo kroz proširene kontrole (Postavke, 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đen port tiho ne uspijeva i izgleda kao pokvaren tunel. Imajte na umu šta ovo pokriva: HTTP proxy postavku poštuju aplikacije svjesne proxyja, a sirovi sockete je potpuno ignorišu. Ako je radni teret izvorni binarni fajl koji otvara vlastite veze, proxy put nije ekvivalentan tunelu i poređenje treba napraviti eksplicitno.

Dokažite rezultat iz unutrašnjosti gosta

Odvojite razrješavanje od rutiranja s dva testa u istoj sesiji. Ime koje ne uspijeva dok numerička adresa odgovara je problem snimka DNS-a, a popravka je redoslijed ili eksplicitni resolver. Ako oba ne uspijevaju, to pokazuje na rutiranje ili politiku, a sljedeća provjera je radi li aplikacija u radnom profilu sa vlastitim mrežnim ograničenjima.

Na kraju, znajte na kojem gostu testirate. Vrlo stare slike emulatora isporučene su bez tun podrške koja je potrebna VPN klijentu na strani gosta, pa nijedan profil tamo nije mogao raditi; aktuelne slike je uključuju. Klijent koji ne uspijeva na aktuelnoj slici je problem klijenta ili profila, i ponovna izgradnja tunela hosta neće promijeniti ishod.