Android-emulator en host-VPN: DNS-snapshot en NAT útlein

Wannear’t de emulator in build-tsjinner net berikt dy’t de browser fan de host sûnder swierrichheden iepenet, is de nuttige fraach net oft de VPN wurket. It is hokker fan twa meganismen de gast mist. It firtuele apparaat rint syn eigen netwurkstack efter de NAT fan de emulator, en syn resolverlist is in kopy dy’t by it opstarten nommen is, dus in tunnel dy’t letter omheech komt feroaret it paad fan de host sûnder te feroarjen wat de gast freget. It begripen fan dy twa lagen ferklearret hast elke fariant fan dit probleem.

De gast is in aparte stack efter in fêste NAT

QEMU-netwurk yn brûkersmodus set de gast op 10.0.2.15, de gateway op 10.0.2.2 en de DNS-tsjinst op 10.0.2.3 oant 10.0.2.6. Utgeande ferkear fan de gast wurdt net trochjûn troch de kernel fan de host; it wurdt oerset yn sockets oan de hostkant, ien per ferbining fan de gast, en dy sockets geane út’e adresromte fan de host. Dêrom erft in ferbining fan de gast de rûtebeslissing fan de host op it momint dat se makke wurdt, en dêrom hat de gast gjin rûtetabel-ynskriuwing dy’t dyn tunnel neamt.

Hitselde meganisme jout de gast in nuttige útgong. 10.0.2.2 is in alias foar de loopback-interface fan de host, dus in tsjinst dy’t op 127.0.0.1 op ’e laptop harket is fan de gast ôf berikber op dat adres. Alles wat de klient allinnich op ’e loopback oanbiedt is sa berikber, en dat is de basis fan ’e proxy-opset dy’t hjirûnder beskreaun wurdt.

Wat de gast net kin is it netwurk fan de host besjen as wie it in nammeromte dêrop. Der is gjin brêge, gjin mienskiplike rûtetabel en gjin erfd resolver, allinnich de NAT-tsjinst dy’t syn pakketten oannimt en de snapshot dy’t de startprogramma naam doe’t it firtuele apparaat begûn.

DNS is in snapshot, gjin libjend byld

By it opstarten lêst de emulator de resolverlist fan de host en jout de gast oant fjouwer tsjinners, sichtber op de adressen 10.0.2.3 oant 10.0.2.6. As de tunnel op dat momint del wie, befettet de snapshot de publike resolver dy’t de laptop brûkte, en de gast bliuwt him fregen foar de rest fan syn libben. Publike nammen wurde oplost, ynterne nammen mislearje, en elk symptoom wiist nei de VPN wylst de wiere ferâldere wearde in resolverlist is dy’t minuten foar it omheech gean fan de tunnel fêstlein is.

Dat de oplossing troch folchoarder is gjin folkloare. Ferbyn earst de tunnel, start de emulator dêrnei opnij, en kies leaver in kâld opstarten as it werombringen fan in snapshot, want in fluch-opstart-ôfbylding kin weromkomme mei de resolver- en rûtetastân dy’t se earder bewarre hat. As do sjen wolst wat de gast no brûkt, freegje it apparaat en net de host:

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

De emulator akseptearret by it starten ek in eksplisite resolver, wat nuttich is as do krekt witst hokker tsjinner de gast brûke moat en gefaarlik as dy tsjinner publike is:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

In publike resolver hat gjin kopy fan in ynterne sône, dus ien fêstsette makket fan in folchoarderprobleem in permaninte mislearring. As it profyl privee DNS opkringt, lit de tunnel it leverje en kâld-start de gast ynstee fan in adres hurd te kodearjen.

Rûte folget de host op it momint fan ’e ferbining

Om’t ferbinings fan de gast sockets fan de host wurde, wurdt de rûtebeslissing nommen by it meitsjen fan de socket. Tunnel omheech foar it fersyk betsjut dat it fersyk troch de tunnel giet neffens de rûtes fan it profyl. In profyl mei in splitst tunnel dy’t allinnich keazen prefiksen draacht lit dyn privee subnet noflik bûten bliuwe, dus berikberens fan de host is in hypoteze oer de gast, gjin resultaat. Besteande ferbinings fan de gast hâlde it paad dêr’t se mei makke binne, dêrom reparearret in klient dy’t opnij ferbynt net altyd in fêstrûne download yn ’e emulator.

De ferifikaasje heart op ’e interface fan de host, net yn ’e statistiken fan de gast:

sudo tcpdump -ni tun0 'host 203.0.113.10'

As it fersyk fan de gast op ’e tunnelinterface ferskynt, wurket de rûte en is it probleem derboppe. As it op ’e fysike interface ferskynt, dekt it profyl dat prefiks net, en gjin oanpaste ynstelling oan ’e gastkant sil dat feroarje.

Wannear’t de klient allinnich in loopback-proxy oanbiedt

Guon kommersjele klienten meitsje hielendal gjin systeemtunnel. Se biede in HTTP- of SOCKS-harker op 127.0.0.1 oan en ferwachtsje dat applikaasjes dy brûke. De gast kin dy socket net direkt sjen, mar tsjin de emulator kin sein wurde dat er dy brûkt, itsij fia de útwreide kontrôles (Ynstellingen, dan Proxy, hânmjittige modus, host 127.0.0.1 en de poarte dy’t de klient printsjet), itsij by it starten:

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

Kopiearje de poarte út it finster fan de klient; in rieden poarte mislearret stil en liket op in brutsen tunnel. Tink deroan wat dit dekt: in HTTP-proxy-ynstelling wurdt respektearre troch proxy-bewuste applikaasjes, en rûge sockets negearje dy folslein. As de wurklêst in native binêre is dy’t syn eigen ferbinings iepenet, is it proxypaad net lykweardich oan in tunnel en moat de ferliking eksplisyt makke wurde.

Bewiis it resultaat fan binnen de gast

Skied de resolúsje fan de rûte mei twa tests yn deselde sesje. In namme dy’t mislearret wylst it numerike adres antwurdet is in DNS-snapshotprobleem, en de repaarsje is folchoarder of in eksplisite resolver. As beide mislearje wiist dat op rûte of belied, en de folgjende kontrôle is oft de app yn in wurkprofyl mei eigen netwurkbeheiningen rint.

Ta beslút, wit op hokker gast do testest. Hiel âlde emulator-ôfbyldings waarden levere sûnder de tun-stipe dy’t in VPN-klient oan ’e gastkant nedich hat, dus gjin profyl koe dêr ea wurkje; hjoeddeistige ôfbyldings befetsje dy. In klient dy’t mislearret op in hjoeddeistige ôfbylding is in klient- of profylprobleem, en it werbouwen fan de tunnel fan de host sil it resultaat net feroarje.