Mengapa aplikasi Android yang diblokir masih menampilkan pemakaian jaringan

Anda memblokir sebuah aplikasi di firewall VPN Android, aplikasi berhenti bekerja, dan baris pemakaiannya terus naik. Kesimpulan yang menggoda adalah blokirnya bocor, atau penghitungnya rusak. Tidak ada yang mengikuti. Catatan pemakaian menyatakan bahwa byte-atribut diberikan kepada identitas itu di suatu titik pengamatan; catatan itu tidak menyatakan apakah layanan jarak jauh menerima permintaan. Begitu Anda tahu batas mana yang diukur dan identitas mana yang dibebani, kedua pengamatan berhenti saling bertentangan.

Penghitung mengukur byte, bukan pengiriman

Android mengatribusikan lalu lintas ke sebuah UID dan menghitungnya di kedua arah, dan melakukannya pada batas antarmuka, bukan pada saat permintaan aplikasi berhasil.

Percobaan koneksi yang ditolak tetap memindahkan paket: SYN, reset, atau transmisi ulang yang menyusul, ditambah kueri DNS yang mendahului keduanya. Byte itu ada meskipun tidak ada yang terkirim, dan pada beberapa jalur byte dihitung sebelum filter mana pun memutuskan apa yang harus dilakukan.

Itulah sebabnya baris aplikasi yang diblokir bisa bertambah sementara setiap permintaan gagal. Penghitung menjawab «berapa byte yang diatribusikan ke identitas ini», bukan «apakah identitas ini mencapai internet». Grafik tidak dapat membedakan aliran yang diterima dari jabat tangan yang ditolak dengan sopan, dan total yang menjumlahkan kedua arah juga tidak bisa.

Atribusi mengikuti UID, bukan ikon

Baris itu per UID, dan satu UID dapat dipakai bersama oleh lebih dari satu paket, sementara aplikasi yang terlihat dapat menyerahkan pekerjaan ke komponen terpisah yang berjalan di bawah identitasnya sendiri. Tab peramban yang digambar oleh proses WebView bersama, layanan sinkronisasi latar belakang, atau paket pendamping yang dipasang bersama aplikasi utama semuanya menghasilkan lalu lintas yang mungkin ditampilkan layar pemakaian dengan nama yang tidak Anda duga, atau di bawah aplikasi yang memang Anda blokir. Paket yang diblokir dan pembantu yang membawa permintaannya adalah dua subjek berbeda, dan aturan itu hanya mencakup salah satunya.

Ketika angkanya tampak salah, bandingkan UID, bukan label. API pemakaian ditanyakan per UID, dan adb shell dumpsys package <package> | grep userId= mencetak angka yang harus dibandingkan, jadi dua entri dengan UID yang sama adalah identitas yang sama dari sudut pandang penghitung.

Jendela waktu bisa mendahului aturan Anda

Data pemakaian dikumpulkan dalam ember dan ditanyakan berkala, bukan dialirkan langsung. Total harian bisa mencakup menit sebelum Anda mengaktifkan blokir, sinkronisasi latar belakang dari jam sebelumnya, atau lalu lintas yang sudah dalam perjalanan. Membandingkan total kumulatif dengan satu permintaan yang ditolak dan menyebut selisihnya kebocoran adalah kesalahan pengukuran, bukan temuan firewall.

Gunakan jendela yang lebih pendek dan awal yang bersih. Catat stempel waktu saat Anda mengubah aturan, tunggu satu interval pengumpulan, lalu lihat hanya data setelahnya. Jika total terus naik pada jendela yang dimulai setelah aturan, ada sesuatu yang perlu diselidiki; jika berhenti naik, pertumbuhan sebelumnya adalah riwayat yang ditampilkan.

Layanan VPN mungkin bukan yang Anda konfigurasi

Firewall VPN hanya melihat lalu lintas yang dibawa layanannya sendiri. Jika aplikasi VPN lain mulai dan mengambil koneksi aktif, filter Anda tidak lagi berada di jalur sementara antarmukanya masih ada di pengaturan. Daftar lewati per aplikasi melakukan hal yang sama dengan sengaja, dan profil yang mengecualikan aplikasi bukan kebocoran ketika aplikasi itu kemudian bekerja.

IPv4, IPv6, dan DNS juga dapat berbeda. Filter yang menangani IPv4 mungkin membiarkan IPv6 atau resolver DNS privat di luarnya, sehingga sebagian lalu lintas aplikasi mengikuti jalur yang tidak pernah dijelaskan aturan Anda. Periksa aplikasi mana yang sekarang memiliki VPN dan apa kata daftar pengecualian sebelum menulis ulang apa pun:

adb shell settings get secure always_on_vpn_app
adb shell dumpsys connectivity
adb shell dumpsys netstats detail

Uji satu permintaan baru dan catat empat fakta

Pilih permintaan yang tidak berbahaya, lakukan sekali, dan catat empat fakta: aturan yang berlaku, UID aplikasi, keadaan jaringan, dan waktu. Lalu periksa apakah filter Anda mencatat alirannya, dan apakah tujuan atau gateway melihat koneksi yang sama. Satu aliran yang teridentifikasi di kedua sisi adalah bukti; total agregat bukan.

Kesimpulan yang dapat dipertahankan menyebutkan apa yang ditolak dan pengamatan mana yang mengonfirmasinya. «Penghitungnya naik» bukan temuan, dan «semua penghitung pemakaian palsu» juga bukan. Slogan lapisan OSI tidak menyelesaikan ini: jawaban jujurnya adalah penghitung dan blokir bisa keduanya benar sambil menjelaskan hal yang berbeda. Referensi NetworkStatsManager Android mendokumentasikan bagaimana ember itu ditanyakan dan diatribusikan.