Android-emulaattori ja isäntäkoneen VPN: DNS-tilannekuva ja NAT selitettynä

Kun emulaattori ei tavoita build-palvelinta, jonka isäntäkoneen selain avaa ongelmitta, hyödyllinen kysymys ei ole se, toimiiko VPN. Se on, kumpi kahdesta mekanismista vieraalta puuttuu. Virtuaalilaite ajaa omaa verkkopinoaan emulaattorin NAT:n takana, ja sen selvityspalvelinluettelo on käynnistyksessä otettu kopio, joten myöhemmin noussut tunneli muuttaa isäntäkoneen reittiä muuttamatta sitä, mitä vieras kysyy. Näiden kahden kerroksen ymmärtäminen selittää lähes jokaisen tämän ongelman muunnelman.

Vieras on erillinen pino kiinteän NAT:n takana

QEMU:n käyttäjätilan verkko sijoittaa vieraan osoitteeseen 10.0.2.15, yhdyskäytävän osoitteeseen 10.0.2.2 ja DNS-palvelun osoitteisiin 10.0.2.3–10.0.2.6. Isäntäkoneen ydin ei välitä vieraan lähtevää liikennettä; se muunnetaan isäntäkoneen puolen pistokkeiksi, yksi jokaista vieraan yhteyttä kohti, ja ne pistokkeet lähtevät isäntäkoneen osoiteavaruudesta. Siksi vieraan yhteys perii isäntäkoneen reitityspäätöksen syntyhetkellään, ja siksi vieraalla ei ole reititystaulussa merkintää, joka nimeäisi tunnelisi.

Sama mekanismi antaa vieraalle hyödyllisen ulospääsyn. 10.0.2.2 on isäntäkoneen loopback-liitännän alias, joten kannettavassa 127.0.0.1:ssä kuunteleva palvelu on vieraasta saavutettavissa siinä osoitteessa. Kaikki, mitä asiakas tarjoaa vain loopbackissa, on siten saavutettavissa, ja se on perusta jäljempänä kuvatulle välityspalvelinjärjestelylle.

Sen vieras ei voi tehdä, on tarkkailla isäntäkoneen verkkoa ikään kuin se olisi sen päällä oleva nimiavaruus. Siltaa ei ole, yhteistä reititystaulua ei ole eikä perittyä selvittäjää ole, vain NAT-palvelu, joka ottaa sen paketit vastaan, ja tilannekuva, jonka käynnistäjä otti virtuaalilaitteen käynnistyessä.

DNS on tilannekuva, ei elävä näkymä

Käynnistyessään emulaattori lukee isäntäkoneen selvittäjäluettelon ja antaa vieraalle enintään neljä palvelinta, jotka näkyvät osoitteissa 10.0.2.3–10.0.2.6. Jos tunneli oli sillä hetkellä alhaalla, tilannekuva sisältää minkä tahansa julkisen selvittäjän, jota kannettava käytti, ja vieras kysyy sitä koko loppuelämänsä. Julkiset nimet selviävät, sisäiset epäonnistuvat, ja jokainen oire osoittaa VPN:ään, vaikka todellinen vanhentunut arvo on luettelo selvittäjistä, joka tallennettiin minuutteja ennen tunnelin nousua.

Järjestyksen korjaus ei siis ole kansanperinnettä. Yhdistä ensin tunneli, käynnistä sitten emulaattori uudelleen ja suosi kylmäkäynnistystä tilannekuvan palauttamisen sijaan, koska pikakäynnistyksen kuva voi palata aiemmin tallennetulla selvittäjä- ja reititystilalla. Jos haluat nähdä, mitä vieras käyttää nyt, kysy laitteelta äläkä isäntäkoneelta:

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

Emulaattori hyväksyy käynnistyksessä myös nimenomaisen selvittäjän, mikä on hyödyllistä, kun tiedät tarkalleen, mitä palvelinta vieraan pitäisi käyttää, ja vaarallista, kun se palvelin on julkinen:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Julkisella selvittäjällä ei ole kopiota sisäisestä vyöhykkeestä, joten yhden kiinnittäminen muuttaa järjestysongelman pysyväksi epäonnistumiseksi. Jos profiili työntää yksityistä DNS:ää, anna tunnelin toimittaa se ja kylmäkäynnistä vieras sen sijaan, että kovakoodaisit osoitteen.

Reititys seuraa isäntäkonetta yhteyden hetkellä

Koska vieraan yhteydet muuttuvat isäntäkoneen pistokkeiksi, reitityspäätös tehdään pistokkeen luontihetkellä. Ennen pyyntöä nostettu tunneli tarkoittaa, että pyyntö lähtee tunnelin kautta profiilin reittien mukaisesti. Jaetun tunnelin profiili, joka kuljettaa vain valitut etuliitteet, jättää yksityisen aliverkkosi mielellään ulkopuolelle, joten isäntäkoneen tavoitettavuus on oletus vieraasta, ei tulos. Olemassa olevat vieraan yhteydet säilyttävät reitin, jolla ne luotiin, ja siksi uudelleen yhdistävä asiakas ei aina korjaa emulaattorin sisällä jumissa olevaa latausta.

Varmistus kuuluu isäntäkoneen liitännälle, ei vieraan tilastoihin:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Jos vieraan pyyntö näkyy tunneliliitännällä, reititys toimii ja ongelma on sen yläpuolella. Jos se näkyy fyysisellä liitännällä, profiili ei kata sitä etuliitettä, eikä mikään uudelleenmääritys vieraan puolella muuta sitä.

Kun asiakas tarjoaa vain loopback-välityspalvelinta

Jotkin kaupalliset asiakkaat eivät luo järjestelmätunnelia lainkaan. Ne tarjoavat HTTP- tai SOCKS-kuuntelijan osoitteessa 127.0.0.1 ja odottavat sovellusten käyttävän sitä. Vieras ei näe sitä pistoketta suoraan, mutta emulaattorille voidaan kertoa sen käytöstä joko laajennettujen säätimien kautta (Asetukset, sitten Välityspalvelin, manuaalinen tila, isäntä 127.0.0.1 ja portti, jonka asiakas tulostaa) tai käynnistyksessä:

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

Kopioi portti asiakkaan ikkunasta; arvattu portti epäonnistuu äänettömästi ja näyttää rikkinäiseltä tunnelilta. Muista, mitä tämä kattaa: HTTP-välityspalvelinasetusta noudattavat välityspalvelintietoiset sovellukset, ja raakat pistokkeet jättävät sen kokonaan huomiotta. Jos työkuorma on oman yhteytensä avaava natiivi binääri, välityspolku ei vastaa tunnelia ja vertailu on tehtävä nimenomaisesti.

Todista tulos vieraan sisältä

Erota selvitys reitityksestä kahdella testillä samassa istunnossa. Nimi, joka epäonnistuu numeerisen osoitteen vastatessa, on DNS-tilannekuvan ongelma, ja korjaus on järjestys tai nimenomainen selvittäjä. Jos molemmat epäonnistuvat, se viittaa reititykseen tai käytäntöön, ja seuraava tarkistus on, ajetaanko sovellusta työprofiilissa, jolla on omat verkkorajoituksensa.

Lopuksi tiedä, millä vieraalla testaat. Hyvin vanhat emulaattorikuvat toimitettiin ilman tun-tukea, jota vieraan puolen VPN-asiakas tarvitsee, joten mikään profiili ei voinut koskaan toimia siellä; nykyiset kuvat sisältävät sen. Asiakas, joka epäonnistuu nykyisellä kuvalla, on asiakas- tai profiiliongelma, eikä isäntäkoneen tunnelin uudelleenrakennus muuta tulosta.