Emulator Android dan VPN Host: Snapshot DNS serta NAT Dijelaskan

Saat emulator gagal menjangkau server build yang terbuka normal di browser host, pertanyaan yang berguna bukanlah apakah VPN bekerja. Pertanyaannya adalah mekanisme mana yang tidak dimiliki guest. Perangkat virtual menjalankan tumpukan jaringannya sendiri di balik NAT emulator, dan daftar resolver-nya adalah salinan yang diambil saat boot, sehingga terowongan yang aktif belakangan mengubah jalur host tanpa mengubah apa yang ditanyakan guest. Memahami kedua lapisan itu menjelaskan hampir semua varian masalah ini.

Guest adalah tumpukan terpisah di balik NAT tetap

Jaringan user-mode QEMU menempatkan guest di 10.0.2.15 dengan gateway di 10.0.2.2, dan layanan DNS di 10.0.2.3 sampai 10.0.2.6. Lalu lintas keluar guest tidak diteruskan oleh kernel host; lalu lintas itu diterjemahkan menjadi socket di sisi host, satu per koneksi guest, dan socket tersebut keluar dari ruang alamat host. Itulah sebabnya koneksi guest mewarisi keputusan routing host pada saat koneksi dibuat, dan sebabnya guest tidak punya entri tabel route yang menyebut terowongan Anda.

Mekanisme yang sama memberi guest jalan keluar yang berguna. 10.0.2.2 adalah alias untuk antarmuka loopback host, jadi layanan yang mendengarkan di 127.0.0.1 pada laptop dapat dijangkau dari guest di alamat itu. Apa pun yang hanya diekspos klien di loopback bisa dijangkau dengan cara itu, dan inilah dasar pengaturan proxy yang dijelaskan di bawah.

Yang tidak bisa dilakukan guest adalah mengamati jaringan host seolah-olah guest adalah namespace di dalamnya. Tidak ada bridge, tidak ada tabel route bersama, dan tidak ada resolver warisan; hanya layanan NAT yang menerima paketnya dan snapshot yang diambil launcher saat perangkat virtual dimulai.

DNS adalah snapshot, bukan pandangan langsung

Saat startup emulator membaca daftar resolver host dan memberi guest hingga empat server, yang diekspos pada alamat 10.0.2.3 sampai 10.0.2.6. Jika terowongan sedang mati saat itu, snapshot berisi resolver publik apa pun yang dipakai laptop, dan guest terus menanyakannya sepanjang umurnya. Nama publik berhasil diresolusi, nama internal gagal, dan semua gejala menunjuk ke VPN padahal nilai basi yang sebenarnya adalah daftar resolver yang ditangkap beberapa menit sebelum terowongan aktif.

Perbaikan urutan karena itu bukan mitos. Hubungkan terowongan lebih dulu, lalu mulai ulang emulator, dan utamakan cold boot daripada pemulihan snapshot, karena image quick-boot bisa kembali dengan status resolver dan route yang disimpan sebelumnya. Jika Anda perlu melihat apa yang sedang dipakai guest, tanyakan ke perangkat, bukan ke host:

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

Emulator juga menerima resolver eksplisit saat diluncurkan, yang berguna bila Anda tahu persis server mana yang harus dipakai guest dan berbahaya bila server itu publik:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Resolver publik tidak memiliki salinan zona internal, jadi menyematkannya mengubah masalah urutan menjadi kegagalan permanen. Jika profil mendorong DNS privat, biarkan terowongan yang menyediakannya dan cold boot guest alih-alih menuliskan alamat secara hard-code.

Routing mengikuti host pada saat koneksi

Karena koneksi guest menjadi socket host, keputusan routing dibuat saat socket dibuat. Terowongan sudah aktif sebelum permintaan berarti permintaan keluar melalui terowongan, tergantung route pada profil. Profil split-tunnel yang hanya membawa prefix terpilih akan dengan senang hati meninggalkan subnet privat Anda di luar, jadi keterjangkauan host hanyalah hipotesis tentang guest, bukan hasil. Koneksi guest yang sudah ada mempertahankan jalur saat dibuat, itulah sebabnya klien yang menyambung ulang tidak selalu memperbaiki unduhan yang macet di dalam emulator.

Verifikasi tempatnya di antarmuka host, bukan di statistik guest:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Jika permintaan guest muncul di antarmuka terowongan, routing bekerja dan masalahnya ada di atasnya. Jika muncul di antarmuka fisik, profil tidak mencakup prefix itu, dan sebanyak apa pun konfigurasi ulang di sisi guest tidak akan mengubahnya.

Saat klien hanya menawarkan proxy loopback

Sebagian klien komersial sama sekali tidak membuat system tunnel. Mereka mengekspos listener HTTP atau SOCKS di 127.0.0.1 dan mengharapkan aplikasi memakainya. Guest tidak bisa melihat socket itu secara langsung, tetapi emulator dapat diberi tahu untuk memakainya, baik melalui extended controls (Settings, lalu Proxy, mode manual, host 127.0.0.1 dan port yang dicetak klien) maupun saat peluncuran:

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

Salin port dari jendela klien; port yang ditebak gagal diam-diam dan tampak seperti terowongan rusak. Ingat apa yang dicakupinya: pengaturan HTTP proxy dihormati oleh aplikasi yang sadar proxy, dan socket mentah mengabaikannya sepenuhnya. Jika beban kerjanya adalah biner native yang membuka koneksinya sendiri, jalur proxy tidak setara dengan terowongan dan perbandingannya harus dibuat secara eksplisit.

Buktikan hasilnya dari dalam guest

Pisahkan resolusi dari routing dengan dua uji dalam sesi yang sama. Nama yang gagal sementara alamat numerik menjawab adalah masalah snapshot DNS, dan perbaikannya adalah urutan atau resolver eksplisit. Keduanya gagal menunjuk ke routing atau kebijakan, dan pemeriksaan berikutnya adalah apakah aplikasi berjalan di dalam work profile dengan pembatasan jaringannya sendiri.

Terakhir, ketahui guest mana yang Anda uji. Image emulator yang sangat lama dikirim tanpa dukungan tun yang dibutuhkan klien VPN sisi guest, jadi tidak ada profil yang bisa bekerja di sana; image saat ini sudah menyertakannya. Klien yang gagal pada image saat ini adalah masalah klien atau profil, dan membangun ulang terowongan host tidak akan mengubah hasilnya.