VPN pada hos atau klien di dalam Genymotion: tentukan siapa memiliki terowong

VPN desktop mempengaruhi Genymotion di dua tempat, dan membaiki satu tidak membuktikan apa-apa tentang yang lain. Yang pertama ialah sambungan yang digunakan aplikasi desktop untuk mengawal peranti maya; yang kedua ialah laluan aplikasi Android maya ke perkhidmatan persendirian. Tentukan yang mana antara keduanya benar-benar anda ubah sebelum menyentuh penyesuai, kemudian catat versi Genymotion Desktop, sistem pengendalian hos dan hypervisor, kerana panduan yang ditulis untuk penyesuai host-only VirtualBox tidak berpindah ke peranti QEMU atau sesi yang dihoskan di awan.

Dua laluan pada satu mesin

Laluan kawalan berjalan dari aplikasi desktop Genymotion ke peranti maya, selalunya melalui rangkaian host-only. Laluan aplikasi berjalan dari dalam Android keluar ke apa sahaja yang diajak oleh aplikasi. VPN hos boleh membawa yang kedua dan memecahkan yang pertama, sebab itulah pelayar yang berfungsi di desktop membuktikan sangat sedikit. Satu terowong boleh melayani kedua-dua laluan atau hanya satu, dan susunan itu ialah keputusan, bukan kebetulan.

Catat laluan mana yang anda diagnosis. Kebanyakan jam yang terbuang dalam bidang ini datang daripada menukar DNS aplikasi persendirian sedangkan peranti tidak pernah dimulakan, atau daripada melonggarkan VPN hos sedangkan aplikasi hanya mempunyai penyelesai yang salah.

Kekalkan sambungan kawalan hidup

Nota sokongan Desktop Genymotion sendiri mendokumenkan kes VirtualBox: sebaik VPN hos dihidupkan, Desktop tidak lagi melihat peranti maya, dan pengecualian yang penting ialah penyesuai host-only sebenar yang disenaraikan dalam pengurus rangkaian VirtualBox. Senaraikan penyesuai itu daripada meneka julat:

VBoxManage list hostonlyifs

Julat lalai yang dicetak dalam dokumentasi bukan alasan untuk memintas rangkaian persendirian secara menyeluruh pada setiap mesin. Tambah pengecualian terkecil yang meliputi penyesuai yang digunakan, dan dapatkan kelulusan pentadbir VPN, kerana klien terurus mungkin menyekat rangkaian tempatan dengan sengaja. Catat pengecualian itu dengan nama penyesuai dan tarikh kelulusan. Enam bulan kemudian nota itulah satu-satunya yang menjelaskan mengapa peraturan itu wujud.

Nota yang sama menyatakan gabungan QEMU belum diuji dengan VPN. Layan ini sebagai had keserasian dan bukan petunjuk bahawa beralih ke rangkaian bridged akan membaikinya; menukar penyesuai mengubah bentuk kegagalan, tetapi tidak menyelesaikan gabungan yang belum diuji.

Pilihan pertama: biarkan hos membawa trafik

Dengan pilihan ini, paket tetamu mesti tiba di antara muka yang dibenarkan dan disulitkan oleh VPN. Ini persoalan penghalaan, bukan lampu status: paket tetamu mesti tiba di antara muka yang akan disulitkan oleh VPN, dan balasan mesti menemui jalan pulang.

Pelayar pada hos membuktikan laluan hos dan tidak apa-apa tentang sama ada sumber dari peranti maya diterima. Sesetengah klien VPN melayan trafik yang dimajukan atau diterjemah berbeza daripada trafik yang dijana secara setempat, jadi uji dari dalam Android sebelum membuat kesimpulan terowong berfungsi. Penyelesai Android juga bukan penyelesai hos. Jika nama diselesaikan di desktop tetapi gagal dalam aplikasi, baca konfigurasi penyelesai tetamu sebelum menyentuh profil VPN.

Pilihan kedua: jalankan klien yang disokong di dalam Android

Di sini tetamu menyimpan profil, kelayakan, laluan dan dasar penyelesainya sendiri. Antara muka VPN Android biasa tidak memerlukan akses root, jadi klien standard dipasang dan bersambung di dalam peranti maya. Kelulusan ialah bahagian yang orang langkau. Organisasi mesti membenarkan klien itu dan persekitaran peranti maya itu, dan import yang bersih tidak dengan sendirinya memenuhi semakan pendaftaran peranti atau postur. Tanya sebelum anda membina aliran kerja di atasnya.

Kedua-dua pilihan juga boleh bertindan: terowong di dalam Android boleh sampai ke pelayan melalui terowong yang sudah berjalan pada hos. Susunan sedemikian memerlukan titik hujung yang boleh dicapai dan pemajuan yang benar-benar anda benarkan, bukan dua lampu hijau yang kebetulan menyala bersama.

Sahkan dari aplikasi dan catat susunannya

Gunakan aplikasi Android yang sama untuk setiap ujian dan baca apa yang dilaporkannya: sama ada alamat menjawab, sama ada nama persendirian diselesaikan, dan apa yang dipulangkan oleh aplikasi. Tiga pemerhatian memisahkan kegagalan penghalaan daripada kegagalan penyelesai dan daripada penolakan dasar.

Apabila peranti gagal dimulakan, atau Desktop kehilangannya, layan itu sebagai kerosakan laluan kawalan dan bukan kerosakan DNS. Gejala itu milik laluan pertama, dan pembaikan ada pada hos, bukan di dalam Android. Akhiri dengan mencatat empat fakta: versi Genymotion Desktop, hypervisor, pihak mana yang memiliki terowong, dan pengecualian host-only yang tepat jika satu ditambah. Pilih susunan terdokumen yang disokong pemilik rangkaian, dan jangan anggap mematikan VPN perusahaan atau melemahkan semakan postur sebagai penyelesaian masalah neutral apabila perkhidmatan persendirian bergantung padanya.