VPN pe gazdă sau client în interiorul Genymotion: decideți cine deține tunelul

Un VPN de desktop afectează Genymotion în două locuri, iar repararea unuia nu demonstrează nimic despre celălalt. Primul este conexiunea pe care aplicația de desktop o folosește pentru a controla dispozitivul virtual; al doilea este calea aplicației Android virtuale către un serviciu privat. Decideți pe care dintre ele îl schimbați efectiv înainte de a atinge un adaptor, apoi notați versiunea Genymotion Desktop, sistemul de operare al gazdei și hipervizorul, fiindcă indicațiile scrise pentru un adaptor host-only de VirtualBox nu se transferă pe un dispozitiv QEMU sau pe o sesiune găzduită în cloud.

Două căi pe o singură mașină

Calea de control merge de la aplicația de desktop Genymotion la dispozitivul virtual, adesea printr-o rețea host-only. Calea aplicației merge din interiorul Android spre orice cu care vorbește aplicația. Un VPN pe gazdă poate duce a doua și poate rupe prima, de aceea un browser care funcționează pe desktop dovedește foarte puțin. Un singur tunel poate servi ambele căi sau doar una, iar această aranjare este o decizie, nu un accident.

Notați ce cale diagnosticați. Cele mai multe ore pierdute în acest domeniu vin din schimbarea DNS-ului aplicației private când dispozitivul nu a pornit niciodată, sau din slăbirea VPN-ului de pe gazdă când aplicația avea pur și simplu resolverul greșit.

Țineți legătura de control în viață

Nota de suport a Genymotion Desktop documentează un caz VirtualBox: odată ce VPN-ul pe gazdă este activ, Desktop nu mai vede dispozitivul virtual, iar excepția care contează este adaptorul host-only real listat în managerul de rețea al VirtualBox. Enumerați acele adaptoare în loc să ghiciți un interval:

VBoxManage list hostonlyifs

Un interval implicit tipărit în documentație nu este o scuză pentru ocolirea completă a rețelei private pe fiecare mașină. Adăugați cea mai mică excepție care acoperă adaptorul folosit și obțineți aprobarea administratorului VPN, fiindcă un client gestionat poate bloca intenționat rețeaua locală. Notați excepția cu numele adaptorului și data aprobării. Șase luni mai târziu acea notă este singurul lucru care explică de ce există regula.

Aceeași notă spune că combinația cu QEMU nu a fost testată cu VPN. Tratați asta ca o limitare de compatibilitate și nu ca un indiciu că trecerea la rețea bridged o va repara; schimbarea adaptorului schimbă defecțiunea, dar nu rezolvă combinația netestată.

Opțiunea A: lăsați gazda să ducă traficul

Cu această alegere, pachetele oaspetelui trebuie să ajungă la o interfață pe care VPN-ul o permite și o criptează în același timp. Este o chestiune de rutare, nu de bec de stare: pachetele oaspetelui trebuie să ajungă la o interfață pe care VPN-ul o va cripta, iar răspunsurile trebuie să găsească drumul înapoi.

Un browser pe gazdă dovedește calea gazdei și nimic despre acceptarea unei surse din dispozitiv virtual. Unii clienți VPN tratează traficul redirecționat sau tradus diferit de traficul generat local, așa că testați din interiorul Android înainte de a concluziona că tunelul funcționează. Nici resolverul Android nu este resolverul gazdei. Dacă numele se rezolvă pe desktop și eșuează în aplicație, citiți configurația resolverului oaspetelui înainte de a atinge profilul VPN.

Opțiunea B: rulați un client acceptat în interiorul Android

Aici oaspetele are propriul profil, acreditări, rute și politică de resolver. Interfețele VPN obișnuite din Android nu necesită acces root, așa că un client standard se instalează și se conectează în interiorul dispozitivului virtual. Aprobarea este partea pe care oamenii o sar. Organizația trebuie să permită acel client și acel mediu de dispozitiv virtual, iar un import curat nu îndeplinește de unul singur verificările de înregistrare a dispozitivului sau de postură. Întrebați înainte de a construi un flux de lucru în jurul acestui lucru.

Cele două alegeri se pot și suprapune: un tunel din interiorul Android poate ajunge la serverul său printr-un tunel care rulează deja pe gazdă. O astfel de aranjare are nevoie de un capăt accesibil și de o redirecționare pe care ați permis-o cu adevărat, nu de două lumini verzi care se întâmplă să fie aprinse împreună.

Verificați din aplicație și notați aranjarea

Folosiți aceeași aplicație Android la fiecare test și citiți ce raportează: dacă adresa răspunde, dacă numele privat se rezolvă și ce returnează aplicația. Trei observații separă o defecțiune de rutare de una de resolver și de o respingere din politică.

Când dispozitivul nu pornește, sau Desktop îl pierde, tratați asta ca o defecțiune a căii de control și nu ca o defecțiune DNS. Simptomul aparține primei căi, iar remedierea este pe gazdă, nu în interiorul Android. Încheiați notând patru fapte: versiunea Genymotion Desktop, hipervizorul, ce parte deține tunelul și excepția host-only exactă dacă a fost adăugată una. Alegeți o aranjare documentată pe care proprietarul rețelei o susține și nu tratați dezactivarea unui VPN de întreprindere sau slăbirea verificărilor de postură ca diagnostic neutru când serviciul privat se bazează pe ele.