Android emuliatorius ir hosto VPN: DNS momentinė kopija bei NAT

Kai emuliatorius negali pasiekti kūrimo serverio, kurį hosto naršyklė atidaro be problemų, naudingas klausimas yra ne tai, ar VPN veikia. Klausimas — kurio iš dviejų mechanizmų trūksta svečiui. Virtualus įrenginys savo tinklo dėklą paleidžia už emuliatoriaus NAT, o jo resolverių sąrašas yra įkrovimo metu padaryta kopija, tad vėliau pakilęs tunelis keičia hosto kelią, bet nekeičia to, ko klausia svečias. Šių dviejų sluoksnių supratimas paaiškina beveik visas šios problemos atmainas.

Svečias yra atskiras dėklas už fiksuoto NAT

QEMU user-mode tinklas padeda svečią adresu 10.0.2.15, šliuzą 10.0.2.2 ir DNS paslaugą nuo 10.0.2.3 iki 10.0.2.6. Išeinantis svečio srautas nėra persiunčiamas hosto branduolio; jis paverčiamas hosto pusės lizdais, po vieną kiekvienam svečio ryšiui, ir tie lizdai išeina iš hosto adresų erdvės. Todėl svečio ryšys paveldi hosto maršrutizavimo sprendimą tuo metu, kai sukuriamas, ir todėl svečio maršrutų lentelėje nėra įrašo, įvardijančio jūsų tunelį.

Tas pats mechanizmas svečiui duoda naudingą išėjimą. 10.0.2.2 yra hosto loopback sąsajos aliasas, tad paslauga, klausanti 127.0.0.1 nešiojamajame kompiuteryje, pasiekiama iš svečio tuo adresu. Viskas, ką klientas atskleidžia tik loopback sąsajoje, pasiekiama šiuo keliu, ir tai yra toliau aprašyto proxy sprendimo pagrindas.

Ko svečias negali, tai stebėti hosto tinklą taip, lyg jis būtų jo namespace. Nėra bridge, nėra bendros maršrutų lentelės ir nėra paveldėto resolverio; yra tik NAT paslauga, priimanti jo paketus, ir momentinė kopija, kurią paleidiklis padarė paleidus virtualų įrenginį.

DNS yra momentinė kopija, o ne gyvas vaizdas

Paleidimo metu emuliatorius nuskaito hosto resolverių sąrašą ir duoda svečiui iki keturių serverių, atskleistų adresais nuo 10.0.2.3 iki 10.0.2.6. Jei tuo metu tunelis buvo nuleistas, kopijoje yra tas viešas resolveris, kurį naudojo nešiojamasis kompiuteris, ir svečias jo klausinėja visą savo gyvenimą. Vieši vardai išsprendžiami, vidiniai vardai nepavyksta, ir visi simptomai rodo į VPN, nors tikroji pasenusi reikšmė yra resolverių sąrašas, užfiksuotas kelias minutes prieš tuneliui pakylant.

Taigi tvarkos pataisymas nėra folkloras. Pirmiausia prijunkite tunelį, tada iš naujo paleiskite emuliatorių, ir rinkitės šaltą įkrovimą, o ne momentinės kopijos atkūrimą, nes quick-boot atvaizdas gali grįžti su anksčiau išsaugota resolverio ir maršrutų būsena. Jei reikia pamatyti, ką svečias naudoja dabar, klauskite įrenginio, o ne hosto:

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

Emuliatorius taip pat priima aiškų resolverį paleidimo metu, kas naudinga, kai tiksliai žinote, kurį serverį svečias turi naudoti, ir pavojinga, kai tas serveris yra viešas:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Viešas resolveris neturi vidinės zonos kopijos, tad vieno priskyrimas tvarkos problemą paverčia nuolatine klaida. Jei profilis perduoda privatų DNS, leiskite tuneliui jį tiekti ir šaltai įkelkite svečią, o ne koduokite adresą.

Maršrutizavimas seka hostą ryšio metu

Kadangi svečio ryšiai tampa hosto lizdais, maršrutizavimo sprendimas priimamas kuriant lizdą. Tunelis pakilęs prieš užklausą reiškia, kad užklausa išeina per tunelį, laikydamasi profilio maršrutų. Split-tunnel profilis, pernešantis tik pasirinktus prefiksus, mielai paliks jūsų privatų potinklį lauke, tad hosto pasiekiamumas yra hipotezė apie svečią, o ne rezultatas. Esami svečio ryšiai išlaiko kelią, su kuriuo buvo sukurti, todėl iš naujo prisijungiantis klientas ne visada sutvarko emuliatoriuje įstrigusį atsisiuntimą.

Tikrinimas priklauso hosto sąsajai, o ne svečio statistikai:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Jei svečio užklausa pasirodo tunelio sąsajoje, maršrutizavimas veikia ir problema yra aukščiau. Jei ji pasirodo fizinėje sąsajoje, profilis neapima to prefikso, ir jokia svečio pusės perkonfigūravimas to nepakeis.

Kai klientas siūlo tik loopback proxy

Kai kurie komerciniai klientai visiškai nesukuria sistemos tunelio. Jie atskleidžia HTTP arba SOCKS klausytuvą 127.0.0.1 ir tikisi, kad programos jį naudos. Svečias nemato to lizdo tiesiogiai, bet emuliatoriui galima nurodyti jį naudoti, per išplėstinius valdiklius (Settings, tada Proxy, rankinis režimas, host 127.0.0.1 ir kliento rodomas prievadas) arba paleidimo metu:

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

Nukopijuokite prievadą iš kliento lango; atspėtas prievadas tyliai nepavyksta ir atrodo kaip sulūžęs tunelis. Turėkite omenyje, ką tai apima: HTTP proxy nustatymą gerbia proxy suvokiančios programos, o neapdoroti lizdai jo visiškai nepaiso. Jei darbo krūvis yra savo ryšius atidarantis native binary, proxy kelias nėra lygiavertis tuneliui ir palyginimas turi būti daromas aiškiai.

Įrodykite rezultatą svečio viduje

Atskirkite sprendimą nuo maršrutizavimo dviem testais toje pačioje sesijoje. Vardas, kuris nepavyksta, nors skaitmeninis adresas atsako, yra DNS momentinės kopijos problema, o sprendimas — tvarka arba aiškus resolveris. Jei nepavyksta abu, tai rodo į maršrutizavimą arba politiką, ir kitas patikrinimas yra ar programa veikia darbo profilyje su savo tinklo apribojimais.

Galiausiai žinokite, kuriame svečias testuojate. Labai seni emuliatoriaus atvaizdai buvo išleisti be tun palaikymo, kurio reikia svečio pusės VPN klientui, tad joks profilis ten niekada negalėjo veikti; dabartiniai atvaizdai jį turi. Klientas, nepavykstantis dabartiniame atvaizde, yra kliento arba profilio problema, ir hosto tunelio perstatymas rezultato nepakeis.