Android-emulátor és gazdagép-VPN: DNS-pillanatkép és a NAT magyarázata

Amikor az emulátor nem ér el egy build-kiszolgálót, amelyet a gazdagép böngészője gond nélkül megnyit, a hasznos kérdés nem az, hogy működik-e a VPN. Hanem az, hogy a két mechanizmus közül melyik hiányzik a vendégnek. A virtuális eszköz saját hálózati vermet futtat az emulátor NAT-ja mögött, és a feloldóinak listája a rendszerindításkor készült másolat, ezért a később feljövő bújtatás megváltoztatja a gazdagép útvonalát anélkül, hogy megváltoztatná azt, amit a vendég kérdez. E két réteg megértése szinte minden változatot megmagyaráz.

A vendég különálló verem egy rögzített NAT mögött

A QEMU felhasználói módú hálózata a vendéget 10.0.2.15-re, az átjárót 10.0.2.2-re, a DNS-szolgáltatást pedig 10.0.2.3-tól 10.0.2.6-ig teszi. A vendég kimenő forgalmát nem továbbítja a gazdagép kernje; a gazdagép oldalán lévő foglalatokká alakul, egy a vendég minden kapcsolatához, és azok a foglalatok a gazdagép címtartományából lépnek ki. Ezért a vendég kapcsolata létrejöttekor örökli a gazdagép útválasztási döntését, és ezért nincs a vendég útvonaltáblájában olyan bejegyzés, amely megnevezné a bújtatást.

Ugyanez a mechanizmus hasznos kijáratot ad a vendégnek. A 10.0.2.2 a gazdagép visszacsatolási interfészének álneve, ezért a laptopon 127.0.0.1-en figyelő szolgáltatás a vendégből azon a címen elérhető. Minden, amit a kliens csak a visszacsatoláson tesz elérhetővé, így elérhető, és ez a később leírt proxy-elrendezés alapja.

Amit a vendég nem tud, az a gazdagép hálózatának megfigyelése úgy, mintha az egy névtér lenne rajta. Nincs híd, nincs közös útvonaltábla és nincs örökölt feloldó, csak a NAT-szolgáltatás, amely a csomagjait fogadja, és a pillanatkép, amelyet az indító a virtuális eszköz indításakor készített.

A DNS pillanatkép, nem élő nézet

Indításkor az emulátor beolvassa a gazdagép feloldólistáját, és legfeljebb négy kiszolgálót ad a vendégnek, amelyek a 10.0.2.3–10.0.2.6 címeken jelennek meg. Ha a bújtatás akkor le volt állva, a pillanatkép tartalmazza bármely nyilvános feloldót, amelyet a laptop használt, és a vendég élete végéig azt kérdezi. A nyilvános nevek feloldódnak, a belsők meghiúsulnak, és minden tünet a VPN-re mutat, miközben a valódi elavult érték egy percekkel a bújtatás feljövetele előtt rögzített feloldólista.

A sorrendi javítás tehát nem folklór. Először csatlakoztassa a bújtatást, aztán indítsa újra az emulátort, és részesítse előnyben a hideg indítást a pillanatkép visszaállítása helyett, mert a gyorsindítású lemezkép visszatérhet a korábban mentett feloldó- és útvonalállapottal. Ha látni szeretné, mit használ most a vendég, a gazdagéptől ne, az eszköztől kérdezze:

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

Az emulátor indításkor kifejezett feloldót is elfogad, ami hasznos, ha pontosan tudja, melyik kiszolgálót kell a vendégnek használnia, és veszélyes, ha az a kiszolgáló nyilvános:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

A nyilvános feloldónak nincs másolata belső zónáról, ezért egy rögzítése a sorrendi problémát tartós meghibásodássá változtatja. Ha a profil privát DNS-t kényszerít, hagyja, hogy a bújtatás biztosítsa, és indítsa hidegen a vendéget ahelyett, hogy címet kódolna be.

Az útválasztás a kapcsolat idején követi a gazdagépet

Mivel a vendég kapcsolatai a gazdagép foglalataivá válnak, az útválasztási döntés a foglalat létrehozásakor születik. A kérés előtt feljövő bújtatás azt jelenti, hogy a kérés a profil útvonalai szerint a bújtatáson keresztül lép ki. A csak kiválasztott előtagokat vivő osztott bújtatású profil készséggel kívül hagyja a privát alhálózatát, ezért a gazdagép elérhetősége a vendégre vonatkozó feltevés, nem eredmény. A meglévő vendégkapcsolatok megtartják a létrehozásukkori útvonalat, ezért az újracsatlakozó kliens nem mindig javítja ki az emulátorban beragadt letöltést.

Az ellenőrzés a gazdagép interfészére tartozik, nem a vendég statisztikáiba:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Ha a vendég kérése a bújtatás interfészén jelenik meg, az útválasztás működik, és a probléma felette van. Ha a fizikai interfészen jelenik meg, a profil nem fedi azt az előtagot, és a vendég oldalán semmilyen átkonfigurálás nem változtat ezen.

Amikor a kliens csak visszacsatolási proxyt kínál

Egyes kereskedelmi kliensek egyáltalán nem hoznak létre rendszerbújtatást. HTTP- vagy SOCKS-figyelőt tesznek elérhetővé a 127.0.0.1-en, és elvárják, hogy az alkalmazások használják. A vendég nem látja közvetlenül azt a foglalatot, de az emulátornak meg lehet mondani, hogy használja, akár a bővített vezérlőkön (Beállítások, majd Proxy, kézi mód, gazdagép 127.0.0.1 és a kliens által kiírt port), akár indításkor:

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

Másolja ki a portot a kliens ablakából; a tippelt port csendben meghiúsul, és törött bújtatásnak látszik. Tartsa szem előtt, mire terjed ki: a HTTP-proxy beállítását a proxy-tudatos alkalmazások betartják, a nyers foglalatok pedig teljesen figyelmen kívül hagyják. Ha a terhelés saját kapcsolatokat nyitó natív bináris, a proxy út nem egyenértékű a bújtatással, és az összehasonlítást kifejezetten el kell végezni.

Bizonyítsa az eredményt a vendég belsejéből

Válassza szét a feloldást az útválasztástól két teszttel ugyanabban a munkamenetben. A név, amely meghiúsul, miközben a numerikus cím válaszol, DNS-pillanatkép-probléma, és a javítás a sorrend vagy egy kifejezett feloldó. Ha mindkettő meghiúsul, az útválasztásra vagy házirendre utal, és a következő ellenőrzés az, hogy az alkalmazás saját hálózati korlátozásokkal rendelkező munkaprofilban fut-e.

Végül tudja, melyik vendégen tesztel. A nagyon régi emulátorképek a vendég oldali VPN-kliens által igényelt tun-támogatás nélkül jelentek meg, ezért ott egyetlen profil sem működhetett; a jelenlegi képek tartalmazzák. A jelenlegi képen meghiúsuló kliens kliens- vagy profilprobléma, és a gazdagép bújtatásának újjáépítése nem változtat az eredményen.