VPN isäntäkoneessa vai asiakas Genymotionin sisällä: päätä, kumpi omistaa tunnelin

Työpöytä-VPN vaikuttaa Genymotoniin kahdessa kohdassa, eikä toisen korjaaminen todista mitään toisesta. Ensimmäinen on yhteys, jota työpöytäsovellus käyttää virtuaalilaitteen ohjaamiseen; toinen on virtuaalisen Android-sovelluksen polku yksityiseen palveluun. Päätä, kumpaa niistä todella muutat, ennen kuin kosket sovittimeen, ja kirjaa sitten Genymotion Desktopin versio, isäntäkoneen käyttöjärjestelmä ja hypervisori, koska VirtualBoxin host-only-sovittimelle kirjoitetut ohjeet eivät siirry QEMU-laitteelle eivätkä pilvessä isännöityyn istuntoon.

Kaksi polkua yhdellä koneella

Ohjauspolku kulkee Genymotionin työpöytäsovelluksesta virtuaalilaitteelle, usein host-only-verkon kautta. Sovelluksen polku kulkee Androidin sisältä siihen, minkä kanssa sovellus puhuu. Isäntä-VPN voi kantaa toista ja rikkoa ensimmäisen, minkä vuoksi työpöydällä toimiva selain merkitsee hyvin vähän. Yksi tunneli voi palvella molempia polkuja tai vain toista, ja tämä järjestely on päätös eikä sattuma.

Kirjoita ylös, kumpaa polkua selvität. Suurin osa tällä alueella menetetyistä tunneista tulee yksityisen sovelluksen DNS:n muuttamisesta silloin, kun laite ei koskaan käynnistynyt, tai isäntä-VPN:n löysentämisestä silloin, kun sovelluksella oli yksinkertaisesti väärä resolveri.

Pidä ohjausyhteys elossa

Genymotionin oma Desktop-tukihuomautus dokumentoi VirtualBox-tapauksen: kun isäntä-VPN on päällä, Desktop ei enää näe virtuaalilaitetta, ja tärkeä poikkeus on VirtualBoxin verkkohallinnassa lueteltu todellinen host-only-sovitin. Luettele ne sovittimet sen sijaan, että arvaisit vaihteluvälin:

VBoxManage list hostonlyifs

Dokumentaatiossa painettu oletusvaihteluväli ei ole tekosyy kiertää yksityisverkkoa kaikilla koneilla. Lisää pienin poikkeus, joka kattaa käytössä olevan sovittimen, ja hanki VPN-järjestelmänvalvojan hyväksyntä, koska hallittu asiakasohjelma voi estää paikallisverkon tarkoituksella. Kirjoita poikkeus muistiin sovittimen nimellä ja hyväksymispäivällä. Puoli vuotta myöhemmin tuo muistiinpano on ainoa asia, joka selittää, miksi sääntö on olemassa.

Sama huomautus sanoo, että QEMU-yhdistelmää ei ole testattu VPN:n kanssa. Käsittele sitä yhteensopivuusrajoituksena, älä vihjeenä siitä, että siirtyminen bridged-verkkoon korjaa sen; sovittimen vaihtaminen muuttaa vikaa, mutta ei ratkaise testaamatonta yhdistelmää.

Vaihtoehto A: anna isäntäkoneen kantaa liikenne

Tässä valinnassa vieraan pakettien on saavuttava rajapintaan, jonka VPN sekä sallii että salaa. Se on reitityskysymys, ei tilavalokysymys: vieraan pakettien on saavuttava rajapintaan, jonka VPN salaa, ja vastausten on löydettävä tie takaisin.

Isäntäkoneen selain todistaa isäntäkoneen polun eikä mitään siitä, hyväksytäänkö virtuaalilaitteen lähde. Jotkin VPN-asiakasohjelmat käsittelevät edelleenlähetettyä tai käännettyä liikennettä eri tavalla kuin paikallisesti tuotettua liikennettä, joten testaa Androidin sisältä ennen kuin päättelet tunnelin toimivan. Androidin resolveri ei ole isäntäkoneen resolverikaan. Jos nimet ratkeavat työpöydällä ja epäonnistuvat sovelluksessa, lue vieraan resolverin kokoonpano ennen kuin kosket VPN-profiilia.

Vaihtoehto B: aja tuettua asiakasohjelmaa Androidin sisällä

Tässä vieraalla on oma profiilinsa, tunnuksensa, reittinsä ja resolverikäytäntönsä. Tavalliset Androidin VPN-rajapinnat eivät tarvitse root-oikeuksia, joten vakioasiakasohjelma asentuu ja yhdistyy virtuaalilaitteen sisällä. Hyväksyntä on se osa, jonka ihmiset ohittavat. Organisaation on sallittava tuo asiakasohjelma ja tuo virtuaalilaiteympäristö, eikä puhdas tuonti itsessään täytä laitteen rekisteröinnin tai tilan tarkistuksia. Kysy ennen kuin rakennat työnkulun sen varaan.

Kaksi valintaa voivat myös pinoutua: Androidin sisäinen tunneli voi tavoittaa palvelimensa jo isäntäkoneella toimivan tunnelin kautta. Sellainen järjestely tarvitsee saavutettavan päätepisteen ja todella sallimasi edelleenlähetyksen, ei kahta vihreää valoa, jotka sattuvat palamaan yhtä aikaa.

Tarkista sovelluksesta ja kirjoita järjestely muistiin

Käytä samaa Android-sovellusta joka testissä ja lue, mitä se raportoi: vastaako osoite, ratkeaako yksityinen nimi ja mitä sovellus palauttaa. Kolme havaintoa erottavat reititysvian resolveriviasta ja käytännön hylkäyksestä.

Kun laite ei käynnisty tai Desktop menettää sen, käsittele sitä ohjauspolun vikana eikä DNS-vikana. Se oire kuuluu ensimmäiselle polulle, ja korjaus on isäntäkoneella, ei Androidin sisällä. Lopeta kirjaamalla neljä tosiasiaa: Genymotion Desktopin versio, hypervisori, kumpi puoli omistaa tunnelin ja tarkka host-only-poikkeus, jos sellainen lisättiin. Valitse dokumentoitu järjestely, jota verkon omistaja tukee, äläkä pidä yritys-VPN:n poiskytkemistä tai tilan tarkistusten heikentämistä neutraalina vianmäärityksenä, kun yksityinen palvelu nojautuu niihin.