Androidov emulator in VPN na gostitelju: posnetek DNS in NAT

Ko emulator ne doseže strežnika za gradnjo, ki ga brskalnik na gostitelju odpre brez težav, koristno vprašanje ni, ali VPN deluje. Vprašanje je, kateri od dveh mehanizmov gostu manjka. Navidezna naprava poganja svoj omrežni sklad za NAT emulatorja, in njen seznam razreševalnikov je kopija, narejena ob zagonu, zato tunel, ki se dvigne pozneje, spremeni pot gostitelja, ne spremeni pa tega, kar gost sprašuje. Razumevanje teh dveh plasti pojasni skoraj vsako različico te težave.

Gost je ločen sklad za fiksnim NAT

Omrežje QEMU v uporabniškem načinu postavi gosta na 10.0.2.15 s prehodom na 10.0.2.2 in storitvijo DNS na 10.0.2.3 do 10.0.2.6. Odhodni promet gosta jedro gostitelja ne posreduje; pretvori se v vtičnice na strani gostitelja, eno za vsako povezavo gosta, in te vtičnice izhajajo iz naslovnega prostora gostitelja. Zato povezava gosta podeduje odločitev usmerjanja gostitelja v trenutku nastanka, in zato gost v tabeli poti nima vnosa, ki bi imenoval vaš tunel.

Isti mehanizem gostu ponudi koristen izhod. 10.0.2.2 je vzdevek vmesnika loopback gostitelja, zato je storitev, ki posluša na 127.0.0.1 na prenosniku, iz gosta dosegljiva na tem naslovu. Vse, kar odjemalec izpostavi samo na loopbacku, je tako dosegljivo, in to je osnova spodaj opisane nastavitve proxyja.

Česar gost ne more, je opazovati omrežje gostitelja, kot da bi bilo njegov namespace. Ni mostu, ni skupne tabele poti in ni podedovanega razreševalnika; obstaja samo storitev NAT, ki sprejema njegove pakete, in posnetek, ki ga je zagonski program naredil ob zagonu navidezne naprave.

DNS je posnetek, ne živi pogled

Ob zagonu emulator prebere seznam razreševalnikov gostitelja in gostu da do štiri strežnike, izpostavljene na naslovih 10.0.2.3 do 10.0.2.6. Če je bil tunel v tistem trenutku spuščen, posnetek vsebuje tisti javni razreševalnik, ki ga je uporabljal prenosnik, in gost ga sprašuje vse življenje. Javna imena se razrešijo, notranja imena odpovedo, in vsi simptomi kažejo na VPN, medtem ko je resnična zastarela vrednost seznam razreševalnikov, ujet nekaj minut preden se je tunel dvignil.

Popravek vrstnega reda torej ni folklora. Najprej povežite tunel, nato znova zaženite emulator, in dajte prednost hladnemu zagonu pred obnovitvijo posnetka, ker se lahko slika quick-boot vrne s prej shranjenim stanjem razreševalnikov in poti. Če želite videti, kaj gost uporablja zdaj, vprašajte napravo in ne gostitelja:

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

Emulator ob zagonu sprejme tudi izrecni razreševalnik, kar je koristno, ko natančno veste, kateri strežnik naj gost uporablja, in nevarno, ko je ta strežnik javen:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Javni razreševalnik nima kopije notranje cone, zato pripenjanje enega spremeni težavo vrstnega reda v trajno okvaro. Če profil potiska zasebni DNS, pustite tunelu, da ga zagotovi, in hladno zaženite gosta, namesto da naslov trdo zapišete.

Usmerjanje sledi gostitelju ob času povezave

Ker povezave gosta postanejo vtičnice gostitelja, se odločitev o usmerjanju sprejme ob nastanku vtičnice. Tunel dvignjen pred zahtevo pomeni, da zahteva odide skozi tunel, v skladu s potmi profila. Profil split-tunnel, ki prenaša le izbrane predpone, bo z veseljem pustil vašo zasebno podomrežje zunaj, zato je dosegljivost gostitelja hipoteza o gostu, ne rezultat. Obstoječe povezave gosta obdržijo pot, s katero so nastale, zato odjemalec, ki se znova poveže, ne popravi vedno zataknjene prenose v emulatorju.

Preverjanje sodi na vmesnik gostitelja, ne v statistiko gosta:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Če se zahteva gosta pojavi na vmesniku tunela, usmerjanje deluje in težava je nad njim. Če se pojavi na fizičnem vmesniku, profil te predpone ne pokriva, in nobena ponovna nastavitev na strani gosta tega ne bo spremenila.

Ko odjemalec ponuja samo loopback proxy

Nekateri komercialni odjemalci sploh ne ustvarijo sistemskega tunela. Izpostavijo poslušalnik HTTP ali SOCKS na 127.0.0.1 in pričakujejo, da ga bodo aplikacije uporabljale. Gost te vtičnice ne vidi neposredno, vendar lahko emulatoru rečemo, naj jo uporabi, bodisi prek razširjenih kontrolnikov (Settings, nato Proxy, ročni način, gostitelj 127.0.0.1 in vrata, ki jih izpiše odjemalec) bodisi ob zagonu:

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

Kopirajte vrata iz okna odjemalca; ugibana vrata tiho odpovedo in izgledajo kot pokvarjen tunel. Ne pozabite, kaj to pokriva: nastavitev proxyja HTTP upoštevajo aplikacije, ki poznajo proxy, surove vtičnice pa jo popolnoma ignorirajo. Če je delovna obremenitev izvorna binarna datoteka, ki odpira svoje povezave, pot prek proxyja ni enakovredna tunelu in primerjavo je treba narediti izrecno.

Dokažite rezultat od znotraj gosta

Ločite razreševanje od usmerjanja z dvema preizkusoma v isti seji. Ime, ki odpove, medtem ko številčni naslov odgovarja, je težava posnetka DNS, rešitev pa je vrstni red ali izrecni razreševalnik. Če odpove oboje, kaže na usmerjanje ali politiko, in naslednje preverjanje je, ali aplikacija teče v delovnem profilu z lastnimi omrežnimi omejitvami.

Nazadnje vedite, na katerem gostu preizkušate. Zelo stare slike emulatorja so bile dobavljene brez podpore tun, ki jo potrebuje odjemalec VPN na strani gosta, zato tam noben profil ni mogel delovati; trenutne slike jo imajo. Odjemalec, ki odpove na trenutni sliki, je težava odjemalca ali profila, in ponovna izgradnja tunela gostitelja izida ne bo spremenila.