Android-emulado kaj hosta VPN: DNS-snapskoto kaj klarigo de NAT

Kiam la emulilo ne atingas konstru-servilon, kiun la retumilo de la hosto malfermas senprobleme, la utila demando ne estas ĉu la VPN funkcias. Ĝi estas kiun el du mekanismoj mankas al la gasto. La virtuala aparato funkciigas sian propran retan staplon malantaŭ la NAT de la emulilo, kaj ĝia solvila listo estas kopio prenita ĉe lanĉo, do tunelo kiu leviĝis poste ŝanĝas la vojon de la hosto sen ŝanĝi tion, kion la gasto demandas. Kompreni tiujn du tavolojn klarigas preskaŭ ĉiun varianton de ĉi tiu problemo.

La gasto estas aparta staplo malantaŭ fiksa NAT

QEMU-retado en uzant-reĝimo metas la gaston ĉe 10.0.2.15, la pordegon ĉe 10.0.2.2 kaj la DNS-servon ĉe 10.0.2.3 ĝis 10.0.2.6. Eliranta trafiko de la gasto ne estas plusendata de la kerno de la hosto; ĝi estas tradukata en ingojn ĉe la hosta flanko, unu por ĉiu konekto de la gasto, kaj tiuj ingoj eliras el la adresspaco de la hosto. Tial konekto de la gasto heredas la enkursigadan decidon de la hosto en la momento de sia kreiĝo, kaj tial la gasto havas neniun enkursigadan tabelan eron, kiu nomas vian tunelon.

La sama mekanismo donas al la gasto utilan eliron. 10.0.2.2 estas kaŝnomo por la bukla interfaco de la hosto, do servo aŭskultanta ĉe 127.0.0.1 sur la tekkomputilo estas atingebla el la gasto ĉe tiu adreso. Ĉio, kion la kliento elmontras nur sur la buklo, estas atingebla tiel, kaj tio estas la bazo de la prokura aranĝo priskribita sube.

Kion la gasto ne povas fari estas observi la reton de la hosto kvazaŭ ĝi estus nomspaco sur ĝi. Mankas ponto, mankas komuna enkursigada tabelo kaj mankas heredita solvilo; estas nur la NAT-servo, kiu akceptas ĝiajn pakaĵojn, kaj la snapskoto, kiun la lanĉilo prenis kiam la virtuala aparato ekfunkciis.

DNS estas snapskoto, ne viva vido

Ĉe lanĉo la emulilo legas la solvilan liston de la hosto kaj donas al la gasto ĝis kvar servilojn, elmontritajn ĉe la adresoj 10.0.2.3 ĝis 10.0.2.6. Se la tunelo estis mallevita en tiu momento, la snapskoto enhavas iun ajn publikan solvilon, kiun la tekkomputilo uzis, kaj la gasto daŭre demandas ĝin por la resto de sia vivo. Publikaj nomoj solviĝas, internaj malsukcesas, kaj ĉiu simptomo montras al la VPN dum la reala kaduka valoro estas solvila listo kaptita minutojn antaŭ ol la tunelo leviĝis.

Tial la ordo-riparo ne estas folkloro. Konektu unue la tunelon, poste restartigu la emulilon, kaj preferu malvarman lanĉon al restaŭro de snapskoto, ĉar rapida lanĉa bildo povas reveni kun la solvila kaj enkursigada stato, kiun ĝi antaŭe konservis. Se vi volas vidi, kion la gasto nun uzas, demandu la aparaton anstataŭ la hoston:

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

La emulilo akceptas ankaŭ eksplicitan solvilon ĉe lanĉo, kio utilas kiam vi scias precize, kiun servilon la gasto uzu, kaj danĝeras kiam tiu servilo estas publika:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Publika solvilo ne havas kopion de interna zono, do fiksi unu transformas ordan problemon en permanentan malsukceson. Se la profilo puŝas privatan DNS, lasu la tunelon provizi ĝin kaj malvarme lanĉu la gaston anstataŭ malmoligi adreson.

Enkursigado sekvas la hoston ĉe la konekta tempo

Ĉar konektoj de la gasto fariĝas ingoj de la hosto, la enkursigada decido estas farata kiam la ingo kreiĝas. Tunelo levita antaŭ la peto signifas, ke la peto eliras tra la tunelo laŭ la itineroj de la profilo. Disigita tunela profilo, kiu portas nur elektitajn prefiksojn, volonte lasos vian privatan subreton ekstere, do atingeblo de la hosto estas hipotezo pri la gasto, ne rezulto. Ekzistantaj konektoj de la gasto konservas la vojon, kun kiu ili kreiĝis, kaj tial kliento, kiu rekonektas, ne ĉiam riparas blokitan elŝuton ene de la emulilo.

La kontrolo apartenas al la interfaco de la hosto, ne al la statistiko de la gasto:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Se la peto de la gasto aperas sur la tunela interfaco, la enkursigado funkcias kaj la problemo estas super ĝi. Se ĝi aperas sur la fizika interfaco, la profilo ne kovras tiun prefikson, kaj neniu reagordado ĉe la gasto ŝanĝos tion.

Kiam la kliento proponas nur buklan prokurilon

Kelkaj komercaj klientoj tute ne kreas sisteman tunelon. Ili elmontras HTTP- aŭ SOCKS-aŭskultanton ĉe 127.0.0.1 kaj atendas, ke aplikaĵoj uzu ĝin. La gasto ne povas vidi tiun ingon rekte, sed oni povas ordoni al la emulilo uzi ĝin, ĉu per la etenditaj regiloj (Agordoj, poste Prokurilo, permana reĝimo, hosto 127.0.0.1 kaj la pordo presita de la kliento) ĉu ĉe lanĉo:

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

Kopiu la pordon el la klienta fenestro; divenita pordo malsukcesas silente kaj aspektas kiel rompita tunelo. Memoru, kion tio kovras: HTTP-prokuran agordon respektas prokur-konsciaj aplikaĵoj, kaj krudaj ingoj tute ignoras ĝin. Se la laborŝarĝo estas denaska binara dosiero, kiu malfermas siajn proprajn konektojn, la prokura vojo ne estas ekvivalenta al tunelo kaj la komparo devas esti farita eksplice.

Pruvu la rezulton el interne de la gasto

Apartigu solvon de enkursigado per du testoj en la sama seanco. Nomo, kiu malsukcesas dum la numera adreso respondas, estas DNS-snapskota problemo, kaj la riparo estas ordo aŭ eksplicita solvilo. Malsukceso de ambaŭ montras enkursigadon aŭ politikon, kaj la sekva kontrolo estas ĉu la aplikaĵo funkcias en labora profilo kun propraj retaj limigoj.

Fine, sciu, sur kiu gasto vi testas. Tre malnovaj emulilaj bildoj estis senditaj sen la tun-subteno, kiun bezonas VPN-kliento ĉe la gasto, do neniu profilo povus iam funkcii tie; nunaj bildoj inkludas ĝin. Kliento, kiu malsukcesas sur nuna bildo, estas klienta aŭ profila problemo, kaj rekonstrui la tunelon de la hosto ne ŝanĝos la rezulton.