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