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

Kada emulator ne može doći do poslužitelja za izgradnju koji preglednik na hostu otvara bez problema, korisno pitanje nije radi li VPN. Pitanje je koji od dvaju mehanizama gostu nedostaje. Virtualni uređaj pokreće vlastiti mrežni usloj iza NAT-a emulatora, i njegov popis razrješivača kopija je uzeta pri podizanju, pa tunel koji se podigne kasnije mijenja putanju hosta, ali ne mijenja ono što gost pita. Razumijevanje tih dvaju slojeva objašnjava gotovo svaku inačicu ovog problema.

Gost je odvojen usloj iza nepokretnog NAT-a

QEMU mreža u korisničkom načinu rada smješta gosta na 10.0.2.15, pristupnik na 10.0.2.2, a DNS uslugu na 10.0.2.3 do 10.0.2.6. Odlazni promet gosta ne prosljeđuje jezgra hosta; on se prevodi u utičnice na strani hosta, po jedna za svaku vezu gosta, i te utičnice izlaze iz adresnog prostora hosta. Zato veza gosta nasljeđuje odluku o usmjeravanju hosta u trenutku nastanka i zato gost nema nijedan zapis u tablici usmjeravanja koji imenuje vaš tunel.

Isti mehanizam daje gostu koristan izlaz. 10.0.2.2 alias je sučelja povratne petlje hosta, pa je usluga koja sluša na 127.0.0.1 na prijenosniku dostupna iz gosta na toj adresi. Sve što klijent izlaže samo na povratnoj petlji može se tako dosegnuti, i to je osnova posredničkog postava opisanog niže.

Ono što gost ne može jest promatrati mrežu hosta kao da je imenski prostor na njoj. Nema mosta, nema zajedničke tablice usmjeravanja i nema naslijeđenog razrješivača, samo NAT usluga koja prihvaća njegove pakete i snimka koju je pokretač napravio pri pokretanju virtualnog uređaja.

DNS je snimka, a ne živi prikaz

Pri pokretanju emulator čita popis razrješivača hosta i daje gostu do četiri poslužitelja, izložena na adresama 10.0.2.3 do 10.0.2.6. Ako je tunel tada bio isključen, snimka sadrži bilo koji javni razrješivač koji je prijenosnik rabio, a gost ga pita do kraja života. Javna imena se razrješavaju, unutarnja ne, i svaki simptom upućuje na VPN dok je stvarna zastarjela vrijednost popis razrješivača zabilježen minutama prije nego se tunel podigao.

Zato ispravak redoslijedom nije predaja. Prvo spojite tunel, zatim ponovno pokrenite emulator i dajte prednost hladnom podizanju pred vraćanjem snimke, jer slika brzog podizanja može se vratiti sa stanjem razrješivača i ruta koje je prije spremila. Ako trebate vidjeti što gost trenutačno rabi, pitajte uređaj, a ne host:

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

Emulator prihvaća i izričiti razrješivač pri pokretanju, što je korisno kada točno znate koji poslužitelj gost treba rabiti, a opasno kada je taj poslužitelj javni:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Javni razrješivač nema kopiju unutarnje zone, pa prikivanje jednoga pretvara problem redoslijeda u trajni neuspjeh. Ako profil gura privatni DNS, pustite tunel da ga osigura i hladno podignite gosta umjesto da adresu upišete kruto.

Usmjeravanje slijedi host u trenutku veze

Budući da veze gosta postaju utičnice hosta, odluka o usmjeravanju donosi se pri stvaranju utičnice. Tunel prije zahtjeva znači da zahtjev izlazi kroz tunel prema rutama profila. Profil s podijeljenim tunelom koji nosi samo odabrane prefikse rado će ostaviti vašu privatnu podmrežu vani, pa je dostupnost hosta pretpostavka o gostu, a ne rezultat. Postojeće veze gosta zadržavaju putanju s kojom su stvorene, zato klijent koji se ponovno spoji ne popravlja uvijek zaglavljeno preuzimanje unutar emulatora.

Provjera pripada sučelju hosta, a ne statistici gosta:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Ako se zahtjev gosta pojavi na sučelju tunela, usmjeravanje radi i problem je iznad njega. Ako se pojavi na fizičkom sučelju, profil ne pokriva taj prefiks i nikakvo preslagivanje na strani gosta to neće promijeniti.

Kada klijent nudi samo posrednik na povratnoj petlji

Neki komercijalni klijenti uopće ne stvaraju sistemski tunel. Izlažu HTTP ili SOCKS slušač na 127.0.0.1 i očekuju da ga aplikacije rabe. Gost ne vidi tu utičnicu izravno, ali emulatoru se može reći da je rabi, bilo kroz proširene kontrole (Postavke, zatim Posrednik, ručni način, 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 zataji i izgleda kao pokvaren tunel. Imajte na umu što ovo pokriva: postavku HTTP posrednika poštuju aplikacije svjesne posrednika, a sirove utičnice je posve zanemaruju. Ako je radni teret izvorna binarna datoteka koja otvara vlastite veze, put kroz posrednik nije jednak tunelu i usporedbu treba napraviti izričito.

Dokažite rezultat iz unutrašnjosti gosta

Odvojite razrješavanje od usmjeravanja dvama testovima u istoj sesiji. Ime koje zataji dok brojčana adresa odgovara problem je snimke DNS-a, a ispravak je redoslijed ili izričiti razrješivač. Ako zataje oba, to upućuje na usmjeravanje ili politiku, a sljedeća provjera je radi li aplikacija u radnom profilu s vlastitim mrežnim ograničenjima.

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