Android-emulator en gasheer-VPN: DNS-momentopname en NAT verduidelik

Wanneer die emulator nie by ’n boubediener kan uitkom wat die gasheerbrowser sonder probleme oopmaak nie, is die nuttige vraag nie of die VPN werk nie. Dit is watter van twee meganismes die gas ontbreek. Die virtuele toestel het sy eie netwerkstapel agter die emulator se NAT, en sy oplosserlys is ’n kopie wat tydens die opstart geneem is, so ’n tonnel wat daarna opgekom het, verander die gasheer se pad sonder om te verander wat die gas vra. Om daardie twee lae te verstaan, verklaar byna elke variant van hierdie probleem.

Die gas is ’n aparte stapel agter ’n vaste NAT

QEMU se netwerk in gebruiker-modus plaas die gas by 10.0.2.15 met ’n poort by 10.0.2.2, en die DNS-diens by 10.0.2.3 tot 10.0.2.6. Uitgaande verkeer van die gas word nie deur die gasheer se kernel aangestuur nie; dit word in gasheerbystande omgeskakel, een per gasverbinding, en daardie bystande vertrek uit die gasheer se adresruimte. Daarom erf ’n gasverbinding die gasheer se roetebesluit op die oomblik dat dit geskep word, en daarom het die gas geen roetetabelinskrywing wat jou tonnel noem nie.

Dieselfde meganisme gee die gas ’n nuttige uitweg. 10.0.2.2 is ’n alias vir die gasheer se loopback-koppelvlak, so ’n diens wat op 127.0.0.1 op die skootrekenaar luister, is vanaf die gas by daardie adres bereikbaar. Enigiets wat die kliënt net op loopback blootstel, kan so bereik word, en dit is die grondslag van die instaanbediener-reëling wat verder hieronder beskryf word.

Wat die gas nie kan doen nie, is om die gasheernetwerk waar te neem asof dit ’n naamruimte daarop is. Daar is geen brug, geen gedeelde roetetabel en geen geërfde oplosser nie, net die NAT-diens wat sy pakkette aanvaar en die momentopname wat die lanseerder geneem het toe die virtuele toestel begin het.

DNS is ’n momentopname, nie ’n lewende aansig nie

By die opstart lees die emulator die gasheer se oplosserlys en gee die gas tot vier bedieners, blootgestel by die 10.0.2.3 tot 10.0.2.6-adresse. As die tonnel op daardie oomblik af was, bevat die momentopname enige openbare oplosser wat die skootrekenaar gebruik het, en die gas bly dit vra vir die res van sy lewe. Openbare name los op, interne name misluk, en elke simptoom wys na die VPN terwyl die werklike verouderde waarde ’n oplosserlys is wat minute voordat die tonnel opgekom het, vasgelê is.

Die oplossing deur ordening is dus nie bygeloof nie. Verbind eers die tonnel, herbegin dan die emulator, en verkies ’n koue opstart bo die herstel van ’n momentopname, want ’n vinnige-opstart-beeld kan terugkeer met die oplosser- en roetetoestand wat dit vroeër gestoor het. As jy wil sien wat die gas tans gebruik, vra die toestel eerder as die gasheer:

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

Die emulator aanvaar ook ’n eksplisiete oplosser by die lanseering, wat nuttig is wanneer jy presies weet watter bediener die gas moet gebruik en gevaarlik wanneer daardie bediener openbaar is:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

’n Openbare oplosser het geen kopie van ’n interne sone nie, so om een vas te pen maak ’n ordeningsprobleem ’n permanente mislukking. As die profiel private DNS stoot, laat die tonnel dit verskaf en begin die gas koud eerder as om ’n adres hard te kodeer.

Roetering volg die gasheer by verbindingstyd

Omdat gasverbindings gasheerbystande word, word die roetebesluit geneem wanneer die bystand geskep word. Tonnel op voor die versoek beteken die versoek vertrek deur die tonnel, onderhewig aan die profielroetes. ’n Split-tonnel-profiel wat net geselekteerde voorvoegsels dra, sal jou private subnet gerus buite laat, so bereikbaarheid van die gasheer is ’n hipotese oor die gas, nie ’n resultaat nie. Bestaande gasverbindings behou die pad waarmee hulle geskep is, en daarom maak ’n kliënt wat weer verbind nie altyd ’n vasgehaakte aflaai in die emulator reg nie.

Verifikasie hoort op die gasheer se koppelvlak, nie in die gas se statistieke nie:

sudo tcpdump -ni tun0 'host 203.0.113.10'

As die gas se versoek op die tonnel-koppelvlak verskyn, werk roetering en is die probleem daarbokant. As dit op die fisiese koppelvlak verskyn, dek die profiel nie daardie voorvoegsel nie, en geen hoeveelheid herkonfigurasie aan die gas se kant sal dit verander nie.

Wanneer die kliënt net ’n loopback-instaanbediener bied

Sommige kommersiële kliënte skep glad nie ’n stelseltonnel nie. Hulle stel ’n HTTP- of SOCKS-luisteraar op 127.0.0.1 bloot en verwag dat toepassings dit gebruik. Die gas kan daardie bystand nie direk sien nie, maar die emulator kan aangesê word om dit te gebruik, hetsy deur die uitgebreide beheerders (Instellings, dan Instaanbediener, handmatige modus, gasheer 127.0.0.1 en die poort wat die kliënt druk) of by lanseering:

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

Kopieer die poort uit die kliëntvenster; ’n geraapte poort misluk stil en lyk soos ’n stukkende tonnel. Onthou wat dit dek: ’n HTTP-instaanbediener-instelling word deur instaanbewuste toepassings gerespekteer, en rou bystande ignoreer dit heeltemal. As die werklading ’n inheemse binêre lêer is wat sy eie verbindings oopmaak, is die instaanpad nie gelyk aan ’n tonnel nie en moet die vergelyking eksplisiet gemaak word.

Bewys die resultaat van binne die gas

Skei oplossing van roetering met twee toetse in dieselfde sessie. ’n Naam wat misluk terwyl die numeriese adres antwoord, is ’n DNS-momentopname-probleem, en die oplossing is ordening of ’n eksplisiete oplosser. Albei wat misluk, wys op roetering of beleid, en die volgende kontrole is of die toepassing in ’n werkprofiel met sy eie netwerkbeperkings loop.

Laastens, weet op watter gas jy toets. Baie ou emulatorbeelde is verskeep sonder die tun-ondersteuning wat ’n gas-kant VPN-kliënt nodig het, so geen profiel kon ooit daar werk nie; huidige beelde sluit dit in. ’n Kliënt wat op ’n huidige beeld misluk, is ’n kliënt- of profielprobleem, en om die gasheer se tonnel te herbou sal nie die uitkoms verander nie.