Android emuladorea eta hostaren VPN: DNS snapshot-a eta NAT azalpena

Emuladoreak hostaren nabigatzaileak arazorik gabe irekitzen duen build zerbitzari batera iristen ez denean, galdera erabilgarria ez da VPN-a funtzionatzen ari den ala ez. Gonbidatuari bi mekanismotatik zein falta zaion da. Gailu birtualak bere sare pilaketa propioa exekutatzen du emuladorearen NAT atzean, eta bere ebazle zerrenda abiaraztean hartutako kopia bat da, beraz geroago igotako tunel batek hostaren bidea aldatzen du, baina ez gonbidatuak galdetzen duena. Bi geruza horiek ulertzeak arazo honen ia aldaera guztiak azaltzen ditu.

Gonbidatua NAT finko baten atzean dagoen pilaketa bereizia da

QEMU-ren erabiltzaile moduko sareak gonbidatua 10.0.2.15ean jartzen du, atebidea 10.0.2.2an eta DNS zerbitzua 10.0.2.3tik 10.0.2.6ra. Hostaren kernelak ez du gonbidatuaren irteera trafikoa birbidaltzen; hostaren alboko socketetara itzultzen da, gonbidatuaren konexio bakoitzeko bat, eta socket horiek hostaren helbide espaziotik irteten dira. Horregatik gonbidatuaren konexio batek hostaren bideratze erabakia heredatzen du sortzen den unean, eta horregatik gonbidatuak ez du zure tunela izendatzen duen bideratze taulako sarrerarik.

Mekanismo berak irteera erabilgarria ematen dio gonbidatuari. 10.0.2.2 hostaren loopback interfazearen aliasa da, beraz ordenagailu eramangarrian 127.0.0.1n entzuten duen zerbitzu bat gonbidatutik helbide horretan iristeko modukoa da. Bezeroak loopbackean soilik erakusten duen guztia horrela iristen da, eta hori da beherago deskribatutako proxy antolamenduaren oinarria.

Gonbidatuak egin ezin duena hostaren sarea bere gaineko izen espazio bat balitz bezala behatzea da. Ez dago zubirik, ez bideratze taula partekaturik eta ez ebazle heredaturik; NAT zerbitzua baino ez, bere paketeak onartzen dituena, eta abiarazleak gailu birtuala hastean hartutako snapshot-a.

DNS snapshot bat da, ez zuzeneko ikuspegi bat

Abiaraztean emuladoreak hostaren ebazle zerrenda irakurtzen du eta gonbidatuari lau zerbitzariraino ematen dizkio, 10.0.2.3tik 10.0.2.6ra bitarteko helbideetan agerian jarrita. Une horretan tunela behera bazegoen, snapshotak eramangailuak erabilitako edozein ebazle publiko dauka, eta gonbidatuak bizitza osoan zehar galdetzen dio. Izen publikoak ebazten dira, barnekoak huts egiten du, eta sintoma guztiek VPN-a seinalatzen dute, benetako balio zaharkitua tunela igo baino minutu batzuk lehenago harrapatutako ebazle zerrenda bat den bitartean.

Beraz ordenaren bidezko konponketa ez da folklore. Konektatu tunela lehenengo, berrabiarazi emuladorea gero, eta hobetsi abiarazte hotza snapshot bat leheneratu beharrean, abiarazte azkarreko irudi batek lehenago gordetako ebazle eta bideratze egoerarekin itzul baitaiteke. Gonbidatuak orain zer erabiltzen duen ikusi behar baduzu, galdetu gailuari, ez hostari:

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

Emuladoreak ebazle esplizitua ere onartzen du abiaraztean, hau erabilgarria da gonbidatuak zein zerbitzari erabili behar duen zehazki dakizunean, eta arriskutsua zerbitzari hori publikoa denean:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Ebazle publiko batek ez du barneko zonalde baten kopiarik, beraz bat finkatzeak ordena arazoa huts egite iraunkor bihurtzen du. Profilak DNS pribatua bultzatzen badu, utzi tunelari hura hornitzen eta abiarazi gonbidatua hotz, helbidea gogor kodetu beharrean.

Bideratzeak hosta jarraitzen du konexioaren unean

Gonbidatuaren konexioak hostaren socket bihurtzen direnez, bideratze erabakia sortzean hartzen da. Tunela eskaera baino lehen igota egoteak esan nahi du eskaera tunelaren bidez irteten dela profilaren ibilbideen arabera. Prefixu hautatuak soilik daramatzan tunel zatituaren profil batek zure azpisare pribatua kanpoan utziko du, beraz hostaren irisgarritasuna gonbidatuari buruzko hipotesia da, ez emaitza. Dauden gonbidatu konexioek sortu ziren bidea gordetzen dute, horregatik berriz konektatzen den bezero batek ez du beti konpontzen emuladorearen barruan trabatutako deskarga bat.

Egiaztapena hostaren interfazean dago, ez gonbidatuaren estatistiketan:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Gonbidatuaren eskaera tunelaren interfazean agertzen bada, bideratzea funtzionatzen ari da eta arazoa horren gainetik dago. Interfaze fisikoan agertzen bada, profilak ez du prefixu hori estaltzen, eta gonbidatuaren aldeko berkonfigurazioak ez du hori aldatuko.

Bezeroak loopback proxy bat soilik eskaintzen duenean

Komertzial bezero batzuek ez dute sistemako tunelik sortzen. HTTP edo SOCKS entzule bat jartzen dute 127.0.0.1n eta aplikazioek erabiliko dutela espero dute. Gonbidatuak ezin du socket hori zuzenean ikusi, baina emuladoreari hura erabiltzeko agindu dakioke, bai kontrol hedatuen bidez (Ezarpenak, gero Proxy, modu eskuzkoa, hosta 127.0.0.1 eta bezeroak inprimatzen duen portua), bai abiaraztean:

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

Kopiatu portua bezeroaren leihotik; asmatutako portu batek isilean huts egiten du eta tunel hautsia dirudi. Gogoan izan zer estaltzen duen: HTTP proxy ezarpena proxyaz jabetzen diren aplikazioek errespetatzen dute, eta socket gordinek erabat ignoratzen dute. Karga-lana bere konexioak irekitzen dituen binario natiboa bada, proxy bidea ez da tunel baten baliokidea eta konparazioa esplizituki egin behar da.

Froga ezazu emaitza gonbidatuaren barrutik

Bereizi ebazpena bideratzetik bi probarekin saio berean. Izen batek huts egiten badu helbide numerikoak erantzuten duen bitartean, DNS snapshot arazoa da, eta konponbidea ordena edo ebazle esplizitua da. Biek huts egiten badute, bideratzea edo politika seinalatzen du, eta hurrengo egiaztapena aplikazioa bere sare murrizketak dituen lan profil batean exekutatzen den ala ez da.

Azkenik, jakin zein gonbidatutan probatzen ari zaren. Emuladorearen irudi oso zaharrak tun euskarri gabe banatu ziren, gonbidatuaren aldeko VPN bezero batek behar duena, beraz profil batek ere ezin zuen han funtzionatu; egungo irudiek badaukate. Egungo irudi batean huts egiten duen bezeroa bezero edo profil arazoa da, eta hostaren tunela berreraikitzeak ez du emaitza aldatuko.