VPN на домаќинот или клиент внатре во Genymotion: одлучете чиј е тунелот

Десктоп VPN влијае на Genymotion на две места, а поправањето на едното не докажува ништо за другото. Првото е врската што десктоп апликацијата ја користи за контрола на виртуелниот уред; второто е патеката на виртуелната Android апликација до приватна услуга. Одлучете кое од двете навистина го менувате пред да допрете адаптер, потоа запишете ја верзијата на Genymotion Desktop, оперативниот систем на домаќинот и хипервизорот, бидејќи упатствата напишани за адаптер «само хост» на VirtualBox не се пренесуваат на уред QEMU ниту на сесија хостирана во облак.

Две патеки на една машина

Контролната патека оди од Genymotion десктоп апликацијата до виртуелниот уред, често преку мрежа «само хост». Патеката на апликацијата оди од внатрешноста на Android кон сето она со што апликацијата разговара. VPN на домаќинот може да го носи второто и да го скрши првото, затоа браузер што работи на десктопот докажува многу малку. Еден тунел може да служи и двете патеки или само едната, и тој распоред е одлука, а не случајност.

Запишете која патека ја дијагностицирате. Поголемиот дел од изгубените часови во оваа област доаѓаат од менување на DNS на приватната апликација кога уредот никогаш не се подигнал, или од олабавување на VPN на домаќинот кога апликацијата едноставно имала погрешен резолвер.

Одржете ја контролната врска жива

Сопствената Desktop белешка за поддршка на Genymotion документира случај со VirtualBox: штом VPN на домаќинот е подигнат, Desktop веќе не го гледа виртуелниот уред, а исклучокот што е важен е вистинскиот адаптер «само хост» наведен во мрежниот менаџер на VirtualBox. Наведете ги тие адаптери наместо да погодувате опсег:

VBoxManage list hostonlyifs

Стандардниот опсег отпечатен во документацијата не е изговор за целосно заобиколување на приватната мрежа на секоја машина. Додајте го најмалиот исклучок што го покрива адаптерот што се користи, и добијте одобрување од администраторот на VPN, бидејќи управуван клиент може намерно да ја блокира локалната мрежа. Запишете го исклучокот со името на адаптерот и датумот на одобрување. По шест месеци таа белешка е единственото нешто што објаснува зошто правилото постои.

Истата белешка вели дека комбинацијата со QEMU не е тестирана со VPN. Третирајте го тоа како ограничување за компатибилност, а не како навестување дека преминот на мостова мрежа ќе го поправи; менувањето на адаптерот ја менува грешката, но не ја решава неиспитаната комбинација.

Прва опција: нека домаќинот го носи сообраќајот

Со овој избор пакетите на гостинот мора да стигнат до интерфејс што VPN-от и го дозволува и го шифрира. Тоа е прашање на рутирање, а не на статусно светло: пакетите на гостинот мора да стигнат до интерфејс што VPN-от ќе го шифрира, а одговорите мора да го најдат патот назад.

Браузерот на домаќинот ја докажува патеката на домаќинот и ништо за тоа дали се прифаќа извор од виртуелен уред. Некои VPN клиенти го третираат препратениот или преведениот сообраќај поинаку од локално создадениот, затоа тестирајте од внатрешноста на Android пред да заклучите дека тунелот работи. Ни резолверот на Android не е резолверот на домаќинот. Ако имињата се решаваат на десктопот, а не успеваат во апликацијата, прочитајте ја конфигурацијата на резолверот на гостинот пред да го допрете VPN профилот.

Втора опција: стартувајте поддржан клиент внатре во Android

Овде гостинот ги држи сопствениот профил, акредитивите, рутите и политиката на резолверот. Обичните Android VPN интерфејси не бараат пристап на суперкорисник, па стандарден клиент се инсталира и поврзува внатре во виртуелниот уред. Одобрувањето е делот што луѓето го прескокнуваат. Организацијата мора да го дозволи тој клиент и таа околина на виртуелен уред, а чистиот увоз сам по себе не ги задоволува проверките за регистрација на уредот или за состојба. Прашајте пред да изградите работен тек околу тоа.

Двете опции можат и да се натрупаат: тунел внатре во Android може да стигне до својот сервер преку тунел што веќе работи на домаќинот. Таквиот распоред бара достапна крајна точка и преправќање што навистина сте го дозволиле, а не две зелени светла што случајно светат заедно.

Проверете од апликацијата и запишете го распоредот

Користете ја истата Android апликација за секој тест и читајте што пријавува: дали адресата одговара, дали приватното име се решава и што враќа апликацијата. Три набљудувања одделуваат рутирачка грешка од грешка на резолверот и од одбивање по политика.

Кога уредот не се подига или Desktop го губи, третирајте го тоа како дефект на контролната патека, а не како DNS дефект. Тој симптом и припаѓа на првата патека, а поправката е на домаќинот, не внатре во Android. Завршете со запишување на четири факти: верзија на Genymotion Desktop, хипервизор, која страна го поседува тунелот и точниот исклучок «само хост» ако е додаден. Изберете документиран распоред што го поддржува сопственикот на мрежата, и не третирајте го исклучувањето на корпоративен VPN или слабеењето на проверките за состојба како неутрално отстранување проблеми кога приватната услуга се потпира на нив, дури и кога таа мрежа сѐ уште е мала.