Эмулятар 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 — гэта псеўданім інтэрфейсу зваротнай пятлі хаста, таму служба, якая слухае 127.0.0.1 на ноўтбуку, дасяжная з госця па гэтым адрасе. Усё, што кліент адкрывае толькі на зваротнай пятлі, можна дасягнуць такім чынам, і гэта аснова праксі-схемы, апісанай ніжэй.

Госць не можа назіраць сетку хаста так, быццам гэта прастора імёнаў на ёй. Няма моста, няма агульнай табліцы маршрутаў і няма ўспадкаванага развязвальніка — толькі служба 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, дайце тунелю забяспечыць яго і зрабіце халодную загрузку госця замест жорсткага задання адраса.

Маршрутызацыя ідзе за хастам у момант злучэння

Паколькі злучэнні госця становяцца сокетамі хаста, рашэнне аб маршрутызацыі прымаецца пры стварэнні сокета. Тунель да запыту азначае, што запыт выходзіць праз тунель згодна з маршрутамі профілю. Профіль з раздзеленым тунелем, які нясе толькі выбраныя прэфіксы, спакойна пакіне вашу прыватную падсетку звонку, таму дасяжнасць хаста — гэта гіпотэза пра госця, а не вынік. Існуючыя злучэнні госця захоўваюць шлях, з якім былі створаны, таму кліент, які перападключаецца, не заўсёды выпраўляе завіслае спампоўванне ўнутры эмулятара.

Праверка належыць інтэрфейсу хаста, а не статыстыцы госця:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Калі запыт госця ўзнікае на інтэрфейсе тунеля, маршрутызацыя працуе і праблема вышэй. Калі ён узнікае на фізічным інтэрфейсе, профіль не пакрывае гэты прэфікс, і ніякая перабудова на баку госця гэтага не зменіць.

Калі кліент прапануе толькі праксі на зваротнай пятлі

Некаторыя камерцыйныя кліенты зусім не ствараюць сістэмны тунель. Яны адкрываюць слухач HTTP або SOCKS на 127.0.0.1 і чакаюць, што праграмы будуць ім карыстацца. Госць не бачыць гэты сокет напрамую, але эмулятару можна загадаць выкарыстоўваць яго — праз пашыраныя элементы кіравання (Налады, потым Праксі, ручны рэжым, хост 127.0.0.1 і порт, які друкуе кліент) або пры запуску:

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

Скапіруйце порт з акна кліента; угаданы порт маўкліва няўдалы і выглядае як зламаны тунель. Памятайце, што гэта пакрывае: наладу праксі HTTP улічваюць праграмы, якія ведаюць пра праксі, а сырыя сокеты цалкам яе ігнаруюць. Калі нагрузка — гэта ўласны бінарнік, які адкрывае свае злучэнні, шлях праз праксі не эквівалентны тунелю, і параўнанне трэба рабіць яўна.

Дакажыце вынік знутры госця

Аддзяліце развязанне ад маршрутызацыі двума тэстамі ў адным сеансе. Імя, якое не развязваецца, пакуль лікавы адрас адказвае, — гэта праблема здымка DNS, і выпраўленне — парадак або яўны развязвальнік. Калі не працуюць абодва, гэта паказвае на маршрутызацыю або палітыку, і наступная праверка — ці працуе праграма ў працоўным профілі са сваімі сеткавымі абмежаваннямі.

Нарэшце, ведайце, на якім госці вы тэстуеце. Вельмі старыя вобразы эмулятара пастаўляліся без падтрымкі tun, патрэбнай кліенту VPN на баку госця, таму ні адзін профіль там не мог працаваць; сучасныя вобразы яе ўключаюць. Кліент, які не працуе на сучасным вобразе, — гэта праблема кліента або профілю, і перабудова тунеля хаста не зменіць выніку.