VPN di host atau klien di dalam Genymotion: putuskan siapa yang memiliki tunnel

VPN desktop memengaruhi Genymotion di dua tempat, dan memperbaiki yang satu tidak membuktikan apa pun tentang yang lain. Yang pertama adalah koneksi yang dipakai aplikasi desktop untuk mengendalikan perangkat virtual; yang kedua adalah jalur aplikasi Android virtual ke layanan privat. Putuskan mana dari keduanya yang benar-benar Anda ubah sebelum menyentuh adaptor, lalu catat versi Genymotion Desktop, sistem operasi host, dan hypervisor, karena panduan yang ditulis untuk adaptor host-only VirtualBox tidak berlaku untuk perangkat QEMU atau sesi yang di-host di cloud.

Dua jalur pada satu mesin

Jalur kontrol berjalan dari aplikasi desktop Genymotion ke perangkat virtual, sering melalui jaringan host-only. Jalur aplikasi berjalan dari dalam Android ke apa pun yang diajak bicara oleh aplikasi. VPN host dapat membawa yang kedua dan merusak yang pertama, itulah sebabnya browser yang berfungsi di desktop tidak membuktikan banyak hal. Satu tunnel dapat melayani kedua jalur atau hanya satu, dan pengaturan itu adalah keputusan, bukan kebetulan.

Catat jalur mana yang Anda diagnosis. Sebagian besar jam yang terbuang di bidang ini berasal dari mengubah DNS aplikasi privat padahal perangkat tidak pernah menyala, atau dari melonggarkan VPN host padahal aplikasi hanya memakai resolver yang salah.

Jaga koneksi kontrol tetap hidup

Catatan dukungan Desktop milik Genymotion sendiri mendokumentasikan kasus VirtualBox: begitu VPN host aktif, Desktop tidak lagi melihat perangkat virtual, dan pengecualian yang penting adalah adaptor host-only asli yang terdaftar di manajer jaringan VirtualBox. Daftarkan adaptor tersebut alih-alih menebak rentang:

VBoxManage list hostonlyifs

Rentang bawaan yang tercetak dalam dokumentasi bukan alasan untuk melewati seluruh jaringan privat di setiap mesin. Tambahkan pengecualian terkecil yang mencakup adaptor yang dipakai, dan mintalah persetujuan administrator VPN, karena klien terkelola dapat memblokir jaringan lokal dengan sengaja. Catat pengecualian itu beserta nama adaptor dan tanggal persetujuan. Enam bulan kemudian catatan itulah satu-satunya hal yang menjelaskan mengapa aturan itu ada.

Catatan yang sama menyatakan kombinasi QEMU belum diuji dengan VPN. Perlakukan itu sebagai batasan kompatibilitas, bukan petunjuk bahwa beralih ke jaringan bridged akan memperbaikinya; mengganti adaptor mengubah kegagalannya, tetapi tidak menyelesaikan kombinasi yang belum diuji.

Opsi A: biarkan host membawa lalu lintas

Dengan pilihan ini, paket tamu harus tiba di antarmuka yang diizinkan dan dienkripsi oleh VPN. Ini pertanyaan perutean, bukan pertanyaan lampu status: paket tamu harus tiba di antarmuka yang akan dienkripsi VPN, dan balasannya harus menemukan jalan kembali.

Browser di host membuktikan jalur host dan tidak membuktikan apakah sumber dari perangkat virtual diterima. Sebagian klien VPN memperlakukan lalu lintas yang diteruskan atau diterjemahkan berbeda dari lalu lintas yang dibuat secara lokal, jadi ujilah dari dalam Android sebelum menyimpulkan tunnel bekerja. Resolver Android juga bukan resolver host. Jika nama terselesaikan di desktop tetapi gagal di aplikasi, baca konfigurasi resolver tamu sebelum menyentuh profil VPN.

Opsi B: jalankan klien yang didukung di dalam Android

Di sini tamu menyimpan profil, kredensial, rute, dan kebijakan resolver-nya sendiri. API VPN Android biasa tidak memerlukan akses root, jadi klien standar terpasang dan terhubung di dalam perangkat virtual. Persetujuan adalah bagian yang dilewati orang. Organisasi harus mengizinkan klien itu dan lingkungan perangkat virtual itu, dan impor yang bersih tidak dengan sendirinya memenuhi pemeriksaan pendaftaran perangkat atau postur. Tanyakan sebelum Anda membangun alur kerja di atasnya.

Kedua pilihan juga dapat ditumpuk: tunnel di dalam Android dapat mencapai servernya melalui tunnel yang sudah berjalan di host. Pengaturan seperti itu memerlukan titik akhir yang dapat dijangkau dan penerusan yang benar-benar Anda izinkan, bukan dua lampu hijau yang kebetulan menyala bersama.

Verifikasi dari aplikasi dan catat pengaturannya

Gunakan aplikasi Android yang sama untuk setiap pengujian dan baca apa yang dilaporkannya: apakah alamat menjawab, apakah nama privat terselesaikan, dan apa yang dikembalikan aplikasi. Tiga pengamatan memisahkan kegagalan perutean dari kegagalan resolver dan dari penolakan kebijakan.

Ketika perangkat gagal menyala, atau Desktop kehilangannya, perlakukan itu sebagai kesalahan jalur kontrol, bukan kesalahan DNS. Gejala itu milik jalur pertama, dan perbaikannya ada di host, bukan di dalam Android. Akhiri dengan mencatat empat fakta: versi Genymotion Desktop, hypervisor, sisi mana yang memiliki tunnel, dan pengecualian host-only yang tepat jika ada yang ditambahkan. Pilih pengaturan terdokumentasi yang didukung pemilik jaringan, dan jangan menganggap menonaktifkan VPN perusahaan atau melemahkan pemeriksaan postur sebagai pemecahan masalah netral ketika layanan privat bergantung padanya.