VPN na hostiteľovi alebo klient v Genymotione: rozhodnite, kto vlastní tunel

Desktop VPN ovplyvňuje Genymotion na dvoch miestach a oprava jedného nič nedokazuje o druhom. Prvé je spojenie, ktoré desktopová aplikácia používa na ovládanie virtuálneho zariadenia; druhé je cesta virtuálnej aplikácie pre Android k súkromnej službe. Rozhodnite, ktoré z nich skutočne meníte, skôr než sa dotknete adaptéra, potom si zapíšte verziu Genymotion Desktop, hostiteľský operačný systém a hypervizor, pretože pokyny napísané pre host-only adaptér VirtualBoxu sa neprenášajú na zariadenie QEMU ani na reláciu hostovanú v cloude.

Dve cesty na jednom stroji

Riadiaca cesta vedie z desktopovej aplikácie Genymotion k virtuálnemu zariadeniu, často cez host-only sieť. Cesta aplikácie vedie zvnútra Androidu k čomukoľvek, s čím aplikácia komunikuje. Hostiteľská VPN môže niesť druhú a zlomiť prvú, a preto fungujúci prehliadač na ploche znamená veľmi málo. Jeden tunel môže obslúžiť obe cesty alebo iba jednu a takéto usporiadanie je rozhodnutie, nie náhoda.

Zapíšte si, ktorú cestu diagnostikujete. Väčšina stratených hodín v tejto oblasti pochádza zo zmeny DNS súkromnej aplikácie, keď sa zariadenie vôbec nespustilo, alebo z uvoľnenia hostiteľskej VPN, keď mala aplikácia jednoducho nesprávny resolver.

Udržte riadiace spojenie živé

Vlastná poznámka podpory Genymotion Desktop dokumentuje prípad VirtualBoxu: keď je hostiteľská VPN hore, Desktop už virtuálne zariadenie nevidí, a výnimka, na ktorej záleží, je skutočný host-only adaptér uvedený v správcovi siete VirtualBoxu. Vymenujte tie adaptéry, namiesto toho aby ste hádali rozsah:

VBoxManage list hostonlyifs

Predvolený rozsah vytlačený v dokumentácii nie je ospravedlnením pre plošné obchádzanie súkromnej siete na každom stroji. Pridajte najmenšiu výnimku, ktorá pokrýva používaný adaptér, a nechajte ju schváliť správcom VPN, pretože spravovaný klient môže miestnu sieť blokovať zámerne. Zapíšte výnimku s názvom adaptéra a dátumom schválenia. O pol roka je tá poznámka jediné, čo vysvetľuje, prečo pravidlo existuje.

Tá istá poznámka hovorí, že kombinácia s QEMU nie je s VPN otestovaná. Berte to ako obmedzenie kompatibility, nie ako náznak, že prechod na bridged sieť to spraví; zmena adaptéra mení zlyhanie, ale neotestovanú kombináciu nerieši.

Možnosť A: nechajte hostiteľa niesť prevádzku

Pri tejto voľbe musia pakety hosťa doraziť na rozhranie, ktoré VPN aj povoľuje, aj šifruje. Je to otázka smerovania, nie kontrolky stavu: pakety hosťa musia doraziť na rozhranie, ktoré VPN bude šifrovať, a odpovede musia nájsť cestu späť.

Prehliadač na hostiteľovi dokazuje cestu hostiteľa a nič o tom, či je zdroj z virtuálneho zariadenia prijímaný. Niektorí klienti VPN spracúvajú preposlanú alebo preloženú prevádzku inak ako lokálne vytvorenú, preto testujte zvnútra Androidu, kým usúdite, že tunel funguje. Ani resolver Androidu nie je resolverom hostiteľa. Ak sa mená na ploche prekladajú a v aplikácii zlyhávajú, prečítajte si konfiguráciu resolvera hosťa, kým sa dotknete profilu VPN.

Možnosť B: spustite podporovaného klienta vnútri Androidu

Tu má hosť vlastný profil, prihlasovacie údaje, trasy a pravidlá resolvera. Bežné rozhrania VPN v Androide nevyžadujú prístup root, takže štandardný klient sa vnútri virtuálneho zariadenia nainštaluje a pripojí. Schválenie je tá časť, ktorú ľudia vynechávajú. Organizácia musí povoliť toho klienta a to prostredie virtuálneho zariadenia a čistý import sám o sebe nespĺňa kontroly registrácie zariadenia ani stavu. Spýtajte sa, kým okolo toho postavíte pracovný postup.

Obe voľby sa môžu aj vrstviť: tunel vnútri Androidu môže k svojmu serveru dôjsť tunelom, ktorý už beží na hostiteľovi. Také usporiadanie potrebuje dosiahnuteľný koncový bod a preposielanie, ktoré ste skutočne povolili, nie dve zelené svetlá, ktoré náhodou svietia spolu.

Overte to z aplikácie a zapíšte usporiadanie

Použite rovnakú aplikáciu pre Android pri každom teste a čítajte, čo hlási: či adresa odpovedá, či sa súkromné meno prekladá a čo aplikácia vracia. Tri pozorovania oddeľujú zlyhanie smerovania od zlyhania resolvera a od odmietnutia podľa pravidiel.

Keď sa zariadenie nespustí alebo ho Desktop stratí, berte to ako poruchu riadiacej cesty, nie ako poruchu DNS. Ten príznak patrí prvej ceste a oprava je na hostiteľovi, nie vnútri Androidu. Na záver zapíšte štyri fakty: verzia Genymotion Desktop, hypervizor, ktorá strana vlastní tunel a presnú výnimku host-only, ak bola pridaná. Vyberte zdokumentované usporiadanie, ktoré vlastník siete podporuje, a nevypínanie podnikovej VPN ani oslabenie kontrol stavu nepovažujte za neutrálnu diagnostiku, keď na nich súkromná služba stojí.