Андроид емулатор и VPN на домаћину: DNS снимак и NAT

Када емулатор не може да дође до сервера за изградњу који прегледач на домаћину отвара без проблема, корисно питање није да ли VPN ради. Питање је који од два механизма недостаје госту. Виртуелни уређај покреће сопствени мрежни стек иза NAT-а емулатора, а његова листа резолвера је копија направљена при подизању, па тунел који се подигне касније мења путању домаћина, али не мења оно што гост пита. Разумевање ова два слоја објашњава скоро сваку варијанту овог проблема.

Гост је одвојен стек иза фиксног NAT-а

QEMU мрежа у корисничком режиму поставља госта на 10.0.2.15 са пролазом на 10.0.2.2 и DNS услугу на 10.0.2.3 до 10.0.2.6. Излазни саобраћај госта не прослеђује језгро домаћина; он се преводи у прикључке на страни домаћина, по један за сваку везу госта, и ти прикључци излазе из адресног простора домаћина. Зато веза госта наслеђује одлуку о рутирању домаћина у тренутку када настаје, и зато гост нема унос у табели рута који именује ваш тунел.

Исти механизам даје госту користан излаз. 10.0.2.2 је алијас loopback интерфејса домаћина, па је услуга која слуша на 127.0.0.1 на преносном рачунару доступна из госта на тој адреси. Све што клијент излаже само на loopback-у може се достићи тим путем, и то је основа подешавања проксија описаног ниже.

Оно што гост не може јесте да посматра мрежу домаћина као да је њен namespace. Нема моста, нема дељене табеле рута и нема наслеђеног резолвера; постоји само NAT услуга која прихвата његове пакете и снимак који је покретач направио када је виртуелни уређај покренут.

DNS је снимак, а не живи приказ

При покретању емулатор чита листу резолвера домаћина и даје госту до четири сервера, изложена на адресама 10.0.2.3 до 10.0.2.6. Ако је тунел у том тренутку био спуштен, снимак садржи онај јавни резолвер који је преносни рачунар користио, и гост га пита целог живота. Јавна имена се решавају, интерна имена падају, и сви симптоми показују на VPN, док је стварна застарела вредност листа резолвера забележена неколико минута пре него што се тунел подигао.

Зато исправка редоследа није фолклор. Прво повежите тунел, затим поново покрените емулатор, и дајте предност хладном подизању уместо враћања снимка, јер слика са брзим подизањем може да се врати са раније сачуваним стањем резолвера и рута. Ако треба да видите шта гост тренутно користи, питајте уређај, а не домаћина:

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

Емулатор прихвата и експлицитни резолвер при покретању, што је корисно када тачно знате који сервер гост треба да користи, а опасно када је тај сервер јаван:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Јавни резолвер нема копију интерне зоне, па прикивање једног претвара проблем редоследа у трајан неуспех. Ако профил гура приватни DNS, пустите тунел да га обезбеди и хладно подигните госта уместо да тврдо кодирате адресу.

Рутирање прати домаћина у тренутку везе

Пошто везе госта постају прикључци домаћина, одлука о рутирању доноси се када се прикључак створи. Тунел подигнут пре захтева значи да захтев излази кроз тунел, у складу са рутама профила. Профил split-tunnel који носи само изабране префиксе радо ће оставити вашу приватну подмрежу напољу, па је доступност домаћина хипотеза о госту, а не резултат. Постојеће везе госта задржавају путању са којом су створене, зато клијент који се поново повезује не поправља увек заглављено преузимање у емулатору.

Провера припада интерфејсу домаћина, а не статистици госта:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Ако се захтев госта појави на интерфејсу тунела, рутирање ради и проблем је изнад њега. Ако се појави на физичком интерфејсу, профил не покрива тај префикс, и никакво реконфигурисање на страни госта то неће променити.

Када клијент нуди само loopback прокси

Неки комерцијални клијенти уопште не праве системски тунел. Излажу HTTP или SOCKS слушалац на 127.0.0.1 и очекују да га апликације користе. Гост не види тај прикључак директно, али емулатору се може рећи да га користи, било кроз проширене контроле (Settings, затим Proxy, ручни режим, домаћин 127.0.0.1 и порт који клијент испише) било при покретању:

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

Копирајте порт из прозора клијента; погођени порт тихо пада и изгледа као покварен тунел. Имајте на уму шта ово покрива: подешавање HTTP проксија поштују апликације које знају за прокси, а сирови прикључци га потпуно игноришу. Ако је радни терет native binary који отвара сопствене везе, пут кроз прокси није еквивалентан тунелу и поређење мора да се уради експлицитно.

Докажите резултат из унутрашњости госта

Раздвојите решавање имена од рутирања са два теста у истој сесији. Име које пада док нумеричка адреса одговара је проблем DNS снимка, а решење је редослед или експлицитни резолвер. Ако оба падну, то указује на рутирање или политику, и следећа провера је да ли апликација ради у радном профилу са сопственим мрежним ограничењима.

На крају, знајте на ком госту тестирате. Веома старе слике емулатора испоручиване су без tun подршке која је потребна VPN клијенту на страни госта, па ниједан профил тамо није могао да ради; актуелне слике је имају. Клијент који пада на актуелној слици је проблем клијента или профила, и поновно прављење тунела домаћина неће променити исход.