Androidi emulaator ja hosti VPN: DNS-i hetktõmmis ja NAT-i selgitus

Kui emulaator ei jõua build-serverini, mille hosti brauser avab probleemideta, ei ole kasulik küsimus see, kas VPN töötab. See on, millist kahest mehhanismist külalisel puudu on. Virtuaalne seade käitab oma võrgupinu emulaatori NAT-i taga ja selle resolverite nimekiri on alglaadimisel tehtud koopia, seega hiljem üles tõusnud tunnel muudab hosti teekonda, muutmata seda, mida külaline küsib. Nende kahe kihi mõistmine selgitab peaaegu iga selle probleemi varianti.

Külaline on eraldi pinu fikseeritud NAT-i taga

QEMU võrk kasutajarežiimis paigutab külalise aadressile 10.0.2.15, lüüsi 10.0.2.2 ja DNS-teenuse 10.0.2.3 kuni 10.0.2.6. Külalise väljuvat liiklust ei edasta hosti kernel; see tõlgitakse hosti poolseteks soketiteks, üks iga külalise ühenduse kohta, ja need soketid väljuvad hosti aadressiruumist. Seetõttu pärib külalise ühendus hosti marsruudimisotsuse loomise hetkel ja seetõttu ei ole külalisel ühtki marsruuditabeli kirjet, mis sinu tunnelit nimetaks.

Sama mehhanism annab külalisele kasuliku väljapääsu. 10.0.2.2 on hosti loopback-liidese alias, seega sülearvutis 127.0.0.1 peal kuulav teenus on külaliselt sellel aadressil kättesaadav. Kõik, mida klient ainult loopbackil pakub, on nii kättesaadav, ja see on allpool kirjeldatud puhverserveri lahenduse alus.

Mida külaline teha ei saa, on vaadelda hosti võrku nii, nagu oleks see tema peal nimeruum. Silda ei ole, ühist marsruuditabelit ei ole ja päritud resolverit ei ole, on ainult NAT-teenus, mis tema pakette vastu võtab, ja hetktõmmis, mille käivitaja virtuaalseadme startimisel tegi.

DNS on hetktõmmis, mitte reaalajas vaade

Käivitamisel loeb emulaator hosti resolverite nimekirja ja annab külalisele kuni neli serverit, mis on välja pandud aadressidel 10.0.2.3 kuni 10.0.2.6. Kui tunnel oli sel hetkel maas, sisaldab hetktõmmis ükskõik millist avalikku resolverit, mida sülearvuti kasutas, ja külaline küsib seda kogu oma elu. Avalikud nimed lahenevad, sisemised ebaõnnestuvad, ja iga sümptom osutab VPN-ile, samal ajal kui tegelik aegunud väärtus on resolverite nimekiri, mis jäädvustati minuteid enne tunnelitõusu.

Seega järjekorraparandus ei ole rahvajutt. Ühenda esmalt tunnel, seejärel taaskäivita emulaator, ja eelista külma alglaadimist hetktõmmise taastamisele, sest kiirkäivituse kujutis võib naasta varem salvestatud resolveri- ja marsruudiseisundiga. Kui tahad näha, mida külaline praegu kasutab, küsi seadmelt, mitte hostilt:

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

Emulaator võtab käivitamisel vastu ka selgesõnalise resolveri, mis on kasulik siis, kui tead täpselt, millist serverit külaline peaks kasutama, ja ohtlik siis, kui see server on avalik:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Avalikul resolveril ei ole sisemise tsooni koopiat, seega ühe kinnitamine muudab järjekorraprobleemi püsivaks tõrkeks. Kui profiil surub peale privaatse DNS-i, lase tunnelil see pakkuda ja käivita külaline külmalt, selle asemel et aadressi kõvasti kodeerida.

Marsruutimine järgib hosti ühenduse hetkel

Kuna külalise ühendused muutuvad hosti soketiteks, tehakse marsruudimisotsus soketi loomisel. Tunnel enne päringut tähendab, et päring väljub tunnelist vastavalt profiili marsruutidele. Jaotatud tunneli profiil, mis kannab ainult valitud prefikseid, jätab sinu privaatse alamvõrgu hea meelega välja, seega hosti kättesaadavus on hüpotees külalise kohta, mitte tulemus. Olemasolevad külalise ühendused säilitavad tee, millega need loodi, ja seetõttu ei paranda uuesti ühenduv klient alati emulaatoris takerdunud allalaadimist.

Kontrollimine kuulub hosti liidesele, mitte külalise statistikasse:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Kui külalise päring ilmub tunneli liidesele, töötab marsruutimine ja probleem on sellest kõrgemal. Kui see ilmub füüsilisele liidesele, ei kata profiil seda prefiksit, ja ükski ümberseade külalise poolel ei muuda seda.

Kui klient pakub ainult loopback-puhverserverit

Mõned kommertskliendid ei loo üldse süsteemset tunnelit. Nad pakuvad HTTP- või SOCKS-kuulajat aadressil 127.0.0.1 ja eeldavad, et rakendused seda kasutavad. Külaline ei näe seda soketit otseselt, kuid emulaatorile saab öelda, et see seda kasutaks, kas laiendatud juhtelementide kaudu (Seaded, seejärel Puhverserver, käsitsi režiim, host 127.0.0.1 ja port, mille klient välja trükib) või käivitamisel:

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

Kopeeri port kliendi aknast; oletatud port ebaõnnestub vaikselt ja näeb välja nagu katkine tunnel. Pea meeles, mida see katab: HTTP-puhverserveri seadet austavad puhverserverist teadlikud rakendused, ja töötlemata soketid eiravad seda täielikult. Kui töökoormus on omi ühendusi avav natiivne binaarfail, ei ole puhverserveri tee tunneliga samaväärne ja võrdlus tuleb teha selgesõnaliselt.

Tõesta tulemus külalise seest

Eralda lahendamine marsruutimisest kahe testiga samas seansis. Nimi, mis ebaõnnestub, samal ajal kui numbriline aadress vastab, on DNS-i hetktõmmise probleem, ja parandus on järjekord või selgesõnaline resolver. Kui mõlemad ebaõnnestuvad, viitab see marsruutimisele või poliitikale, ja järgmine kontroll on, kas rakendus töötab tööprofiilis, millel on oma võrgupiirangud.

Lõpuks tea, millisel külalisel sa testid. Väga vanad emulaatori kujutised tarniti ilma tun-toeta, mida külalise poolne VPN-klient vajab, seega ei saanud ükski profiil seal kunagi töötada; praegused kujutised sisaldavad seda. Klient, mis ebaõnnestub praegusel kujutisel, on kliendi või profiili probleem, ja hosti tunneli ümberehitamine ei muuda tulemust.