Emulátor Android a VPN na hostiteli: snímek DNS a vysvětlení NAT

Když se emulátor nedostane na build server, který prohlížeč na hostiteli otevře bez problémů, užitečná otázka není, zda VPN funguje. Je to, který ze dvou mechanismů hostu chybí. Virtuální zařízení provozuje vlastní síťový stack za NAT emulátoru a jeho seznam resolverů je kopie pořízená při startu, takže tunel, který se zvedne později, změní cestu hostitele, ale nezmění to, na co se host ptá. Pochopení těchto dvou vrstev vysvětluje téměř každou variantu tohoto problému.

Host je samostatný stack za pevným NAT

Síť QEMU v uživatelském režimu umísťuje hosta na 10.0.2.15, bránu na 10.0.2.2 a službu DNS na 10.0.2.3 až 10.0.2.6. Odchozí provoz hosta nepředává jádro hostitele; překládá se na sockety na straně hostitele, jeden pro každé spojení hosta, a tyto sockety vycházejí z adresního prostoru hostitele. Proto spojení hosta dědí rozhodnutí o směrování hostitele v okamžiku vzniku a proto host nemá v tabulce směrování žádný záznam, který by jmenoval váš tunel.

Stejný mechanismus dává hostu užitečný východ. 10.0.2.2 je alias rozhraní loopback hostitele, takže služba naslouchající na 127.0.0.1 na notebooku je z hosta dostupná na této adrese. Vše, co klient vystavuje jen na loopbacku, lze takto dosáhnout, a to je základ proxy uspořádání popsaného níže.

Host nemůže pozorovat síť hostitele, jako by na ní byl jmenný prostor. Není zde most, žádná sdílená tabulka směrování ani zděděný resolver, jen služba NAT, která přijímá jeho pakety, a snímek, který spouštěč pořídil při startu virtuálního zařízení.

DNS je snímek, ne živý pohled

Při startu emulátor přečte seznam resolverů hostitele a předá hostu až čtyři servery, vystavené na adresách 10.0.2.3 až 10.0.2.6. Pokud byl tunel v tu chvíli vypnutý, snímek obsahuje jakýkoli veřejný resolver, který notebook používal, a host se ho ptá po zbytek života. Veřejná jména se přeloží, interní selžou a každý příznak ukazuje na VPN, zatímco skutečná zastaralá hodnota je seznam resolverů zachycený minuty před tím, než se tunel zvedl.

Oprava pořadím tedy není pověra. Nejprve připojte tunel, potom restartujte emulátor a dejte přednost studenému startu před obnovením snímku, protože obraz rychlého startu se může vrátit se stavem resolveru a směrování, který si dříve uložil. Pokud potřebujete vidět, co host právě používá, ptejte se zařízení, ne hostitele:

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

Emulátor přijímá při spuštění také explicitní resolver, což je užitečné, když přesně víte, který server má host použít, a nebezpečné, když je tento server veřejný:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Veřejný resolver nemá kopii interní zóny, takže připnutí jednoho mění problém pořadí v trvalé selhání. Pokud profil tlačí privátní DNS, nechte tunel, ať ho dodá, a spusťte hosta studeně místo natvrdo zapsané adresy.

Směrování následuje hostitele v okamžiku spojení

Protože se spojení hosta stávají sockety hostitele, rozhodnutí o směrování se dělá při vytvoření socketu. Tunel před požadavkem znamená, že požadavek vychází tunelem podle tras profilu. Profil s rozděleným tunelem, který nese jen vybrané prefixy, s chutí nechá vaši privátní podsíť venku, takže dosažitelnost hostitele je hypotéza o hostu, ne výsledek. Existující spojení hosta si drží cestu, se kterou vznikla, a proto klient, který se znovu připojí, ne vždy opraví zaseknuté stahování uvnitř emulátoru.

Ověřování patří na rozhraní hostitele, ne do statistik hosta:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Pokud se požadavek hosta objeví na rozhraní tunelu, směrování funguje a problém je nad ním. Pokud se objeví na fyzickém rozhraní, profil tento prefix nepokrývá a žádné překonfigurování na straně hosta to nezmění.

Když klient nabízí jen proxy na loopbacku

Někteří komerční klienti systémový tunel vůbec nevytvářejí. Vystavují HTTP nebo SOCKS posluchač na 127.0.0.1 a očekávají, že jej aplikace použijí. Host tento socket přímo nevidí, ale emulátoru lze říct, aby jej použil, buď přes rozšířené ovládací prvky (Nastavení, potom Proxy, ruční režim, hostitel 127.0.0.1 a port, který klient vypíše), nebo při spuštění:

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

Zkopírujte port z okna klienta; odhadnutý port selhává tiše a vypadá jako rozbitý tunel. Mějte na paměti, co to pokrývá: nastavení HTTP proxy respektují aplikace, které proxy znají, a surové sockety je zcela ignorují. Pokud je zátěží nativní binárka, která otevírá vlastní spojení, cesta přes proxy není ekvivalentní tunelu a srovnání je třeba provést výslovně.

Dokažte výsledek zevnitř hosta

Oddělte překlad od směrování dvěma testy v téže relaci. Jméno, které selže, zatímco číselná adresa odpovídá, je problém snímku DNS a opravou je pořadí nebo explicitní resolver. Pokud selžou oba, ukazuje to na směrování nebo politiku a další kontrola je, zda aplikace běží v pracovním profilu s vlastními síťovými omezeními.

Nakonec vězte, na kterém hostu testujete. Velmi staré obrazy emulátoru se dodávaly bez podpory tun, kterou klient VPN na straně hosta potřebuje, takže tam žádný profil nemohl fungovat; současné obrazy ji obsahují. Klient, který selhává na současném obrazu, je problém klienta nebo profilu a přestavba tunelu hostitele výsledek nezmění.