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 чи послаблення перевірок стану нейтральною діагностикою, коли приватна служба на них спирається.