Android емулатор и 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. Нема bridge, нема заедничка табела со рути и нема наследен резолвер; има само 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, рачен режим, host 127.0.0.1 и портата што ја печати клиентот) или при стартување:

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

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

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

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

На крајот, знајте на кој гостин тестирате. Многу стари слики на емулаторот се испорачуваа без поддршка за tun што му е потребна на VPN клиент на страната на гостинот, па таму ниту еден профил не можеше да работи; сегашните слики ја имаат. Клиент што неуспева на сегашна слика е проблем на клиентот или профилот, и повторното градење на тунелот на домаќинот нема да го смени резултатот.