Mengapa lalu lintas debugging nirkabel bukan bukti kebocoran VPN

Anda mengaktifkan debugging nirkabel, menghubungkan laptop, dan sesi tetap berjalan selama VPN aktif. Itu terlihat seperti ada yang lolos melewati terowongan. Hampir pasti tidak. Sesi debugging dan permintaan aplikasi ke situs web adalah hubungan jaringan yang berbeda, dan hanya satu yang seharusnya melintasi terowongan.

Saya pernah mengalami salah baca ini dua kali: sekali saat ponsel dan laptop berada di Wi-Fi yang sama, dan sekali setelah reboot ketika pemasangan bertahan. Dalam kedua kasus VPN melakukan tepat apa yang dikonfigurasi untuk dilakukan.

Beri nama pengamatan sebelum memberi nama bug

Tiga peristiwa dapat mendahului klaim kebocoran, dan ketiganya tidak dapat saling menggantikan. Alat dapat menemukan layanan, perangkat dapat menyetujui workstation, atau sesi resmi dapat benar-benar membawa perintah dan byte. Catat mana yang Anda lihat, karena masing-masing membuktikan lebih sedikit daripada yang orang duga.

Penemuan biasanya mDNS atau pemindaian port. Pemasangan adalah keputusan pendaftaran yang dibuat di ponsel, dikonfirmasi dengan kode yang diketik pengguna. Sesi aktif berarti lalu lintas berpindah antara dua titik akhir yang dipasangkan. Tidak satu pun dari itu menjelaskan ke mana permintaan HTTPS aplikasi pergi.

Simpan tujuan, antarmuka, keluarga alamat, stempel waktu, dan profil pengguna melekat pada peristiwa. Tanpa detail itu, pengamatan tidak dapat dibandingkan dengan kebijakan jaringan lokal yang dimaksud, atau dengan versi VPN yang berjalan saat itu.

Mengapa kedua jalur tidak pernah bertemu

Debugging nirkabel adalah koneksi masuk ke perangkat. adbd mendengarkan pada port yang terikat ke antarmuka Wi-Fi, dan workstation terhubung ke sana setelah pemasangan. Arahnya penting: laptop Anda menjangkau ke dalam ponsel, bukan sebaliknya. Itu kebalikan dari kebocoran keluar.

Lalu lintas internet aplikasi keluar melalui antarmuka terowongan yang dipasang VpnService, dicocokkan berdasarkan UID dan aturan perutean. adbd adalah daemon sistem yang berjalan sebagai pengguna shell, bukan aplikasi di dalam kumpulan perutean itu. Ia tetap berada di tautan Wi-Fi yang mendasarinya bahkan ketika setiap aplikasi disematkan ke terowongan.

Mode penguncian menegakkan terowongan untuk aplikasi yang tercakup. Itu tidak mengubah soket yang mendengarkan menjadi jalur keluar.

Itulah sebabnya sesi ADB yang berfungsi dan tombol mati yang berfungsi hidup berdampingan tanpa kontradiksi. Untuk membuktikan kebocoran, Anda harus mengamati arah yang seharusnya diblokir.

Seperti apa tes keluar sebenarnya

Uji aplikasi yang tercakup, bukan kanal debugging. Siapkan kondisi kegagalan dengan sengaja, lalu buat satu permintaan baru dan catat apa yang terjadi.

1. Pastikan VPN adalah satu-satunya jalur: aktifkan VPN selalu aktif dengan blokir koneksi tanpa VPN.
2. Hentikan VPN dengan cara yang didukung dan pastikan aplikasi melaporkan tidak ada konektivitas.
3. Kirim satu permintaan tidak berbahaya dari aplikasi itu dan catat apakah gagal atau berhasil.
4. Ulangi dengan debugging nirkabel aktif, lalu mati, agar variabelnya terisolasi.

Permintaan yang diblokir dalam kondisi itu adalah bukti. Sesi ADB yang berhasil bukan, dan satu ping dari aplikasi terminal juga bukan.

Jika permintaan benar-benar berhasil saat penguncian aktif, catat UID aplikasi dan izin VPN-nya, jaringan aktif, dan versi klien. Kombinasi itu adalah temuan nyata.

Pemasangan bertahan lebih lama dari sesi

Pemasangan adalah status persisten, bukan jabat tangan yang bisa dilupakan setelah uji kabel. Dokumentasi debugging Android menjelaskan alur kerja nirkabel dan mencatat bahwa hubungan itu bertahan sampai dilupakan secara eksplisit atau otorisasinya dicabut.

Periksa apa yang masih diotorisasi sebelum menyalahkan terowongan. Buka Debugging nirkabel, lihat Perangkat yang dipasangkan, dan lupakan apa pun yang tidak lagi Anda kenali. Jalankan adb devices dari workstation untuk melihat entri mana yang masih menjawab, dan adb disconnect untuk melepas yang usang. Mematikan debugging nirkabel menutup port pendengaran sepenuhnya.

Pada jaringan bersama atau tidak tepercaya, biarkan mati. Otorisasi persisten pada jaringan yang tidak Anda kendalikan adalah masalah yang lebih besar daripada pengelakan TUN hipotetis.

Sebelum Anda melaporkan bug itu

Laporan yang berguna menyebutkan batas persis yang gagal. Sertakan model perangkat dan rilis Android, klien VPN dan versinya, apakah penguncian diaktifkan, paket aplikasi dan UID, serta jaringan tempat ponsel berada. Tambahkan perintah atau permintaan yang menghasilkan pengamatan, plus waktu kejadiannya. Tanpa itu, tidak ada yang dapat mereproduksi batas yang Anda klaim rusak.

Jangan menonaktifkan penegakan atau membuka debugging di jaringan tidak tepercaya agar tes terlihat lebih dramatis. Itu mengubah sistem yang Anda ukur dan meninggalkan bukti yang tidak dapat diulang siapa pun.

Jika satu-satunya bukti Anda adalah ADB terhubung saat VPN aktif, Anda mengukur jalur yang salah. Jalankan ulang uji tingkat aplikasi terlebih dahulu; jawabannya biasanya datang di sana.