VPN на хосте или клиент внутри Genymotion: решите, кому принадлежит туннель

Настольный VPN влияет на Genymotion в двух местах, и исправление одного ничего не доказывает про другое. Первое — это соединение, которое настольное приложение использует для управления виртуальным устройством; второе — путь виртуального приложения Android к частной службе. Решите, что именно из этого вы действительно меняете, прежде чем трогать адаптер, и запишите версию Genymotion Desktop, операционную систему хоста и гипервизор, потому что указания, написанные для адаптера «только хост» из VirtualBox, не переносятся на устройство QEMU или на сеанс, размещённый в облаке.

Два пути на одной машине

Путь управления идёт от настольного приложения Genymotion к виртуальному устройству, часто через сеть «только хост». Путь приложения идёт изнутри Android наружу, к тому, с чем приложение разговаривает. VPN на хосте может нести второй и ломать первый, и поэтому работающий браузер на рабочем столе доказывает очень мало. Один туннель может обслуживать оба пути или только один, и такая схема — решение, а не случайность.

Запишите, какой путь вы диагностируете. Большая часть потерянных часов в этой области возникает из-за смены DNS частного приложения, когда устройство так и не запустилось, или из-за ослабления VPN на хосте, когда у приложения просто был неправильный резолвер.

Держите канал управления живым

Собственная памятка поддержки Genymotion Desktop описывает случай VirtualBox: как только VPN на хосте поднят, Desktop больше не видит виртуальное устройство, а важное исключение — это настоящий адаптер «только хост», перечисленный в сетевом менеджере VirtualBox. Перечислите эти адаптеры вместо того, чтобы угадывать диапазон:

VBoxManage list hostonlyifs

Диапазон по умолчанию, напечатанный в документации, не оправдание для полного обхода частной сети на каждой машине. Добавьте наименьшее исключение, покрывающее используемый адаптер, и получите одобрение администратора VPN, потому что управляемый клиент может намеренно блокировать локальную сеть. Запишите исключение с именем адаптера и датой одобрения. Через полгода эта заметка будет единственным, что объясняет, зачем существует правило.

Та же памятка говорит, что сочетание с QEMU не проверялось с VPN. Считайте это ограничением совместимости, а не намёком на то, что переход на мостовую сеть это исправит; смена адаптера меняет характер сбоя, но не решает непроверенное сочетание.

Вариант первый: пусть хост несёт трафик

При таком выборе пакеты гостя должны прийти на интерфейс, который VPN одновременно разрешает и шифрует. Это вопрос маршрутизации, а не лампочки состояния: пакеты гостя должны прийти на интерфейс, который VPN будет шифровать, а ответы должны найти путь обратно.

Браузер на хосте доказывает путь хоста и ничего не говорит о том, принимается ли источник с виртуального устройства. Некоторые клиенты VPN обрабатывают пересланный или транслированный трафик иначе, чем локально созданный, поэтому проверяйте изнутри Android, прежде чем заключать, что туннель работает. И резолвер Android — не резолвер хоста. Если имена разрешаются на рабочем столе, а в приложении не разрешаются, прочитайте конфигурацию резолвера гостя, прежде чем трогать профиль VPN.

Вариант второй: запустите поддерживаемый клиент внутри Android

Здесь гость хранит собственный профиль, учётные данные, маршруты и политику резолвера. Обычные интерфейсы VPN в Android не требуют прав суперпользователя, поэтому стандартный клиент устанавливается и подключается внутри виртуального устройства. Одобрение — та часть, которую люди пропускают. Организация должна разрешить этот клиент и эту среду виртуального устройства, а чистый импорт сам по себе не выполняет проверки регистрации устройства или состояния. Спросите, прежде чем строить вокруг этого рабочий процесс.

Два варианта могут и накладываться: туннель внутри Android может достичь своего сервера через туннель, уже работающий на хосте. Такая схема требует доступной конечной точки и пересылки, которую вы действительно разрешили, а не двух зелёных лампочек, случайно горящих одновременно.

Проверьте из приложения и запишите схему

Используйте одно и то же приложение Android в каждой проверке и читайте, что оно сообщает: отвечает ли адрес, разрешается ли частное имя и что приложение возвращает. Три наблюдения отделяют сбой маршрутизации от сбоя резолвера и от отказа по политике.

Когда устройство не запускается или Desktop теряет его, считайте это сбоем канала управления, а не сбоем DNS. Этот симптом относится к первому пути, и исправление находится на хосте, а не внутри Android. Закончите записью четырёх фактов: версия Genymotion Desktop, гипервизор, какая сторона владеет туннелем и точное исключение «только хост», если оно было добавлено. Выберите документированную схему, которую поддерживает владелец сети, и не считайте отключение корпоративного VPN или ослабление проверок состояния нейтральной диагностикой, когда частная служба на них опирается.