VPN sur la gastiga komputilo aŭ kliento ene de Genymotion: decidu, kiu posedas la tunelon

Labortabla VPN efikas al Genymotion en du lokoj, kaj ripari unu pruvas nenion pri la alia. La unua estas la konekto, kiun la labortabla aplikaĵo uzas por regi la virtualan aparaton; la dua estas la vojo de la virtuala Android-aplikaĵo al privata servo. Decidu, kiun el ili vi vere ŝanĝas antaŭ ol tuŝi adaptilon, poste notu la version de Genymotion Desktop, la gastigan operaciumon kaj la hipervidebligilon, ĉar gvidilo skribita por VirtualBox host-only-adaptilo ne transiĝas al QEMU-aparato nek al sesio gastigata en la nubo.

Du vojoj sur unu maŝino

La rega vojo iras de la Genymotion-labortabla aplikaĵo al la virtuala aparato, ofte tra host-only-reto. La aplikaĵa vojo iras el Android al tio, kun kio la aplikaĵo parolas. Gastiga VPN povas porti la duan kaj rompi la unuan, kaj tial funkcianta retumilo sur la labortablo signifas tre malmulte. Unu tunelo povas servi ambaŭ vojojn aŭ nur unu el ili, kaj tiu aranĝo estas decido, ne hazardo.

Notu, kiun vojon vi esploras. Plej multaj perditaj horoj en ĉi tiu kampo venas de ŝanĝado de la DNS de la privata aplikaĵo, kiam la aparato neniam ekfunkciis, aŭ de malstreĉado de la gastiga VPN, kiam la aplikaĵo simple havis la malĝustan solvilon.

Tenu la regan konekton viva

La propra subtena noto de Genymotion Desktop dokumentas VirtualBox-kazon: post kiam gastiga VPN ekfunkcias, Desktop ne plu vidas la virtualan aparaton, kaj la escepto, kiu gravas, estas la reala host-only-adaptilo listigita en la retadministrilo de VirtualBox. Listigu tiujn adaptilojn anstataŭ diveni gamon:

VBoxManage list hostonlyifs

Defaŭlta gamo presita en dokumentaro ne estas senkulpigo por ĝenerala preteriro de la privata reto sur ĉiu maŝino. Aldonu la plej malgrandan escepton, kiu kovras la uzatan adaptilon, kaj ricevu aprobon de la VPN-administranto, ĉar administrata kliento povas intence bloki la lokan reton. Notu la escepton kun la adaptila nomo kaj la aproba dato. Ses monatojn poste tiu noto estas la sola afero, kiu klarigas, kial la regulo ekzistas.

La sama noto diras, ke la QEMU-kombinaĵo ne estas testita kun VPN. Traktu tion kiel kongruecan limigon, ne kiel aludon, ke ŝanĝo al bridged-reto riparos ĝin; ŝanĝi la adaptilon ŝanĝas la fiaskon, sed ne solvas la netestitan kombinaĵon.

Opcio A: lasu la gastiganton porti la trafikon

Ĉe ĉi tiu elekto la paketoj de la gasto devas alveni ĉe interfaco, kiun la VPN kaj permesas kaj ĉifras. Tio estas demando pri enkursigado, ne pri statlumo: la paketoj de la gasto devas alveni ĉe interfaco, kiun la VPN ĉifros, kaj la respondoj devas trovi la vojon reen.

Retumilo sur la gastiganto pruvas la vojon de la gastiganto kaj nenion pri tio, ĉu fonto el virtuala aparato estas akceptata. Iuj VPN-klientoj traktas plusenditan aŭ tradukitan trafikon alie ol loke generitan trafikon, do testu el Android antaŭ ol konkludi, ke la tunelo funkcias. Ankaŭ la solvilo de Android ne estas la solvilo de la gastiganto. Se nomoj solviĝas sur la labortablo kaj fiaskas en la aplikaĵo, legu la solvilan agordon de la gasto antaŭ ol tuŝi la VPN-profilon.

Opcio B: rulu subtenatan klienton ene de Android

Ĉi tie la gasto tenas sian propran profilon, akreditaĵojn, vojojn kaj solvilan politikon. La ordinaraj Android-VPN-API-oj bezonas neniun root-aliro, do norma kliento instaliĝas kaj konektiĝas ene de la virtuala aparato. Aprobo estas la parto, kiun homoj preterlasas. La organizo devas permesi tiun klienton kaj tiun virtualan aparatan medion, kaj pura importo per si mem ne plenumas aparatan registriĝon nek statuskontrolojn. Demandu antaŭ ol konstrui laborfluon ĉirkaŭ ĝi.

La du elektoj ankaŭ povas stakiĝi: tunelo ene de Android povas atingi sian servilon tra tunelo jam kuranta sur la gastiganto. Tia aranĝo bezonas atingeblan finpunkton kaj plusendadon, kiun vi vere permesis, ne du verdajn lumojn, kiuj hazarde brilas kune.

Kontrolu el la aplikaĵo kaj notu la aranĝon

Uzu la saman Android-aplikaĵon por ĉiu testo kaj legu, kion ĝi raportas: ĉu la adreso respondas, ĉu la privata nomo solviĝas kaj kion la aplikaĵo redonas. Tri observoj apartigas enkursigan fiaskon de solvila fiasko kaj de politika malakcepto.

Kiam la aparato ne ekfunkcias aŭ Desktop perdas ĝin, traktu tion kiel difekton de la rega vojo, ne kiel DNS-difekton. Tiu simptomo apartenas al la unua vojo, kaj la riparo estas sur la gastiganto, ne ene de Android. Finu notante kvar faktojn: versio de Genymotion Desktop, hipervidebligilo, kiu flanko posedas la tunelon, kaj la ĝusta host-only-escepto, se unu estis aldonita. Elektu dokumentitan aranĝon, kiun la retposedanto subtenas, kaj ne traktu malŝaltadon de entreprena VPN aŭ malfortigadon de statuskontroloj kiel neŭtralan problemserĉadon, kiam la privata servo dependas de ili.