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 или отслабването на проверките за състояние като неутрална диагностика, когато частната услуга разчита на тях.