Emulator Android dan VPN Hos: Snapshot DNS serta NAT

Apabila emulator gagal mencapai pelayan build yang dibuka dengan baik oleh pelayar hos, soalan yang berguna bukanlah sama ada VPN berfungsi. Soalannya ialah mekanisme mana antara dua yang tiada pada guest. Peranti maya menjalankan stack rangkaiannya sendiri di belakang NAT emulator, dan senarai resolvernya ialah salinan yang diambil semasa boot, jadi terowong yang naik kemudian mengubah laluan hos tanpa mengubah apa yang ditanya oleh guest. Memahami kedua-dua lapisan ini menjelaskan hampir setiap variasi masalah ini.

Guest ialah stack berasingan di belakang NAT tetap

Rangkaian mod pengguna QEMU meletakkan guest pada 10.0.2.15 dengan gateway pada 10.0.2.2, dan perkhidmatan DNS pada 10.0.2.3 hingga 10.0.2.6. Trafik keluar guest tidak dihadkan oleh kernel hos; ia diterjemahkan kepada soket di sebelah hos, satu bagi setiap sambungan guest, dan soket itu keluar dari ruang alamat hos. Itulah sebabnya sambungan guest mewarisi keputusan penghalaan hos pada saat ia dicipta, dan sebabnya guest tiada entri jadual laluan yang menamakan terowong anda.

Mekanisme yang sama memberikan guest jalan keluar yang berguna. 10.0.2.2 ialah alias untuk antara muka loopback hos, jadi perkhidmatan yang mendengar pada 127.0.0.1 pada komputer riba boleh dicapai dari guest pada alamat itu. Apa sahaja yang klien dedahkan hanya pada loopback boleh dicapai melalui cara itu, dan inilah asas susunan proksi yang diterangkan di bawah.

Apa yang guest tidak boleh lakukan ialah memerhati rangkaian hos seolah-olah ia namespace padanya. Tiada jambatan, tiada jadual laluan dikongsi dan tiada resolver diwarisi; hanya perkhidmatan NAT yang menerima paketnya dan snapshot yang diambil pelancar semasa peranti maya dimulakan.

DNS ialah snapshot, bukan pandangan langsung

Semasa permulaan emulator membaca senarai resolver hos dan memberikan guest sehingga empat pelayan, didedahkan pada alamat 10.0.2.3 hingga 10.0.2.6. Jika terowong turun pada masa itu, snapshot mengandungi resolver awam yang digunakan oleh komputer riba, dan guest terus bertanya kepadanya sepanjang hayatnya. Nama awam diselesaikan, nama dalaman gagal, dan semua gejala menunjuk kepada VPN sedangkan nilai basi sebenar ialah senarai resolver yang dirakam beberapa minit sebelum terowong naik.

Pembetulan urutan itu bukan cerita rakyat. Sambungkan terowong dahulu, kemudian mulakan semula emulator, dan utamakan cold boot berbanding pemulihan snapshot, kerana imej quick-boot boleh kembali dengan keadaan resolver dan laluan yang disimpan lebih awal. Jika anda perlu melihat apa yang guest gunakan sekarang, tanya peranti, bukan hos:

adb shell dumpsys connectivity | grep -i -A2 dns
adb shell ping -c 1 build.internal.example

Emulator juga menerima resolver eksplisit semasa pelancaran, yang berguna apabila anda tahu tepat pelayan mana yang harus digunakan guest dan berbahaya apabila pelayan itu awam:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Resolver awam tiada salinan zon dalaman, jadi menyematkan satu mengubah masalah urutan menjadi kegagalan kekal. Jika profil menolak DNS peribadi, biarkan terowong membekalkannya dan cold boot guest dan bukan mengekod alamat secara keras.

Penghalaan mengikut hos pada masa sambungan

Oleh sebab sambungan guest menjadi soket hos, keputusan penghalaan dibuat apabila soket dicipta. Terowong naik sebelum permintaan bermakna permintaan keluar melalui terowong, tertakluk kepada laluan profil. Profil split-tunnel yang membawa hanya awalan terpilih akan dengan senang hati membiarkan subnet peribadi anda di luar, jadi kebolehcapaian hos ialah hipotesis tentang guest, bukan hasil. Sambungan guest sedia ada mengekalkan laluan semasa ia dicipta, itulah sebabnya klien yang menyambung semula tidak selalu membaiki muat turun yang tersekat dalam emulator.

Pengesahan terletak pada antara muka hos, bukan dalam statistik guest:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Jika permintaan guest muncul pada antara muka terowong, penghalaan berfungsi dan masalahnya di atasnya. Jika ia muncul pada antara muka fizikal, profil tidak meliputi awalan itu, dan tiada pengkonfigurasian semula di sebelah guest akan mengubahnya.

Apabila klien hanya menawarkan proksi loopback

Sesetengah klien komersial tidak mencipta terowong sistem langsung. Mereka mendedahkan pendengar HTTP atau SOCKS pada 127.0.0.1 dan menjangka aplikasi menggunakannya. Guest tidak dapat melihat soket itu secara langsung, tetapi emulator boleh diberitahu untuk menggunakannya, sama ada melalui kawalan lanjutan (Settings, kemudian Proxy, mod manual, hos 127.0.0.1 dan port yang dicetak oleh klien) atau semasa pelancaran:

emulator -avd Pixel_API_34 -http-proxy http://127.0.0.1:8080

Salin port dari tetingkap klien; port yang diteka gagal secara senyap dan kelihatan seperti terowong rosak. Ingat apa yang diliputinya: tetapan proksi HTTP dihormati oleh aplikasi yang menyedari proksi, dan soket mentah mengabaikannya sepenuhnya. Jika beban kerja ialah binari asli yang membuka sambungannya sendiri, laluan proksi tidak setara dengan terowong dan perbandingan mesti dibuat secara eksplisit.

Buktikan hasilnya dari dalam guest

Pisahkan penyelesaian daripada penghalaan dengan dua ujian dalam sesi yang sama. Nama yang gagal sedangkan alamat berangka menjawab ialah masalah snapshot DNS, dan pembaikannya ialah urutan atau resolver eksplisit. Kedua-duanya gagal menunjuk kepada penghalaan atau dasar, dan semakan seterusnya ialah sama ada aplikasi berjalan dalam work profile dengan sekatan rangkaiannya sendiri.

Akhir sekali, ketahui guest mana yang anda uji. Imej emulator yang sangat lama dihantar tanpa sokongan tun yang diperlukan oleh klien VPN sebelah guest, jadi tiada profil boleh berfungsi di sana; imej semasa memasukkannya. Klien yang gagal pada imej semasa ialah masalah klien atau profil, dan membina semula terowong hos tidak akan mengubah hasilnya.