Emulator ya Android na VPN ya mwenyeji: picha ya DNS na NAT

Wakati emulator haiwezi kufikia seva ya build ambayo kivinjari kwenye mwenyeji huifungua bila shida, swali lenye manufaa si kama VPN inafanya kazi. Swali ni ipi kati ya mbinu mbili ambayo mgeni hana. Kifaa pepe kinaendesha stack yake ya mtandao nyuma ya NAT ya emulator, na orodha yake ya resolver ni nakala iliyochukuliwa wakati wa boot, kwa hiyo handaki inayokuja baadaye hubadilisha njia ya mwenyeji bila kubadilisha kile mgeni anachouliza. Kuelewa tabaka hizi mbili hufafanua karibu kila aina ya tatizo hili.

Mgeni ni stack tofauti nyuma ya NAT isiyobadilika

Mtandao wa QEMU wa hali ya mtumiaji huweka mgeni kwenye 10.0.2.15 na lango kwenye 10.0.2.2, na huduma ya DNS kwenye 10.0.2.3 hadi 10.0.2.6. Trafiki inayotoka kwa mgeni haipitishwi na kernel ya mwenyeji; inatafsiriwa kuwa soketi upande wa mwenyeji, moja kwa kila muunganisho wa mgeni, na soketi hizo hutoka katika nafasi ya anwani ya mwenyeji. Ndiyo sababu muunganisho wa mgeni hurithi uamuzi wa uelekezaji wa mwenyeji wakati unaundwa, na ndiyo sababu mgeni hana kiingilio kwenye jedwali la njia kinachotaja handaki yako.

Mbinu hiyo hiyo humpa mgeni njia ya kutokea yenye manufaa. 10.0.2.2 ni jina lingine la kiolesura cha loopback cha mwenyeji, kwa hiyo huduma inayosikiliza kwenye 127.0.0.1 kwenye kompyuta mpito inafikiwa kutoka kwa mgeni kwenye anwani hiyo. Kila kitu ambacho mteja hufichua tu kwenye loopback kinafikiwa kwa njia hiyo, na hii ndiyo msingi wa mpangilio wa proksi ulioelezwa hapa chini.

Kile mgeni hawezi kufanya ni kutazama mtandao wa mwenyeji kana kwamba ni namespace yake. Hakuna daraja, hakuna jedwali la njia linaloshirikiwa na hakuna resolver iliyorithiwa; kuna huduma ya NAT inayokubali pakiti zake na picha ambayo kizinduzi kilichukua wakati kifaa pepe kilipoanza.

DNS ni picha, si mwonekano hai

Wakati wa kuanza emulator husoma orodha ya resolver ya mwenyeji na kumpa mgeni hadi seva nne, zilizofichuliwa kwenye anwani 10.0.2.3 hadi 10.0.2.6. Ikiwa handaki ilikuwa imezimwa wakati huo, picha ina resolver ya umma ambayo kompyuta mpito ilitumia, na mgeni huendelea kuiuliza maisha yake yote. Majina ya umma hutatuliwa, majina ya ndani hushindwa, na dalili zote zinaelekeza kwa VPN ilhali thamani halisi iliyopitwa na wakati ni orodha ya resolver iliyonaswa dakika chache kabla handaki haijainuka.

Kwa hiyo marekebisho ya mpangilio si hadithi. Unganisha handaki kwanza, kisha uanzishe emulator upya, na upendelee kuanza baridi badala ya kurejesha picha, kwa sababu taswira ya kuanza haraka inaweza kurudi na hali ya resolver na njia iliyohifadhiwa awali. Ikiwa unahitaji kuona kile mgeni anatumia sasa, uliza kifaa, si mwenyeji:

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

Emulator pia hukubali resolver iliyo wazi wakati wa kuzindua, ambayo ni muhimu unapojua hasa ni seva ipi mgeni anapaswa kutumia na ni hatari wakati seva hiyo ni ya umma:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Resolver ya umma haina nakala ya eneo la ndani, kwa hiyo kubandika moja hugeuza tatizo la mpangilio kuwa hitilafu ya kudumu. Ikiwa profaili inasukuma DNS ya faragha, acha handaki iitoa na uanzishe mgeni baridi badala ya kuandika anwani kwa mkono.

Uelekezaji hufuata mwenyeji wakati wa muunganisho

Kwa kuwa muunganisho wa mgeni huwa soketi za mwenyeji, uamuzi wa uelekezaji hufanywa wakati soketi inaundwa. Handaki iliyoinuka kabla ya ombi humaanisha kwamba ombi hutoka kupitia handaki, kwa kuzingatia njia za profaili. Profaili ya split-tunnel inayobeba tu viambishi vilivyochaguliwa itaacha subnet yako ya faragha nje kwa raha, kwa hiyo ufikivu wa mwenyeji ni dhana kuhusu mgeni, si matokeo. Muunganisho uliopo wa mgeni hubaki na njia iliyoundwa nayo, ndiyo sababu mteja anayeunganisha upya huwa hawarekebishi upakuaji uliokwama ndani ya emulator.

Uthibitishaji unamilikiwa na kiolesura cha mwenyeji, si takwimu za mgeni:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Ikiwa ombi la mgeni linaonekana kwenye kiolesura cha handaki, uelekezaji unafanya kazi na tatizo liko juu yake. Ikiwa linaonekana kwenye kiolesura cha kimwili, profaili haifuniki kiambishi hicho, na hakuna usanidi upya upande wa mgeni utakaobadilisha hilo.

Wakati mteja hutoa proksi ya loopback pekee

Baadhi ya wateja wa kibiashara hawaundi handaki ya mfumo kabisa. Wanafichua kisikilizaji cha HTTP au SOCKS kwenye 127.0.0.1 na wanatarajia programu zitumie. Mgeni hawezi kuona soketi hiyo moja kwa moja, lakini emulator inaweza kuambiwa iitumie, ama kupitia vidhibiti vilivyopanuliwa (Settings, kisha Proxy, hali ya mkono, mwenyeji 127.0.0.1 na bandari inayochapishwa na mteja) au wakati wa kuzindua:

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

Nakili bandari kutoka dirisha la mteja; bandari iliyokisiwa hushindwa kwa kimya na inaonekana kama handaki iliyovunjika. Kumbuka kinachofunikwa na hili: mpangilio wa proksi ya HTTP huheshimiwa na programu zinazojua proksi, na soketi mbichi huipuuza kabisa. Ikiwa kazi ni native binary inayofungua muunganisho wake yenyewe, njia ya proksi si sawa na handaki na ulinganisho lazima ufanywe kwa uwazi.

Thibitisha matokeo kutoka ndani ya mgeni

Tenganisha utatuzi na uelekezaji kwa majaribio mawili katika kikao kimoja. Jina linaloshindwa ilhali anwani ya nambari inajibu ni tatizo la picha ya DNS, na suluhisho ni mpangilio au resolver iliyo wazi. Ikiwa zote mbili zinashindwa hiyo inaonyesha uelekezaji au sera, na ukaguzi unaofuata ni kama programu inaendesha ndani ya profaili ya kazi yenye vikwazo vyake vya mtandao.

Hatimaye, fahamu ni mgeni gani unaojaribu. Taswira za zamani sana za emulator zilitolewa bila msaada wa tun unaohitajika na mteja wa VPN upande wa mgeni, kwa hiyo hakuna profaili iliyoweza kufanya kazi hapo; taswira za sasa zinao. Mteja anayeshindwa kwenye taswira ya sasa ni tatizo la mteja au la profaili, na kujenga upya handaki ya mwenyeji hakutabadilisha matokeo.