Vì sao ứng dụng Android bị chặn vẫn hiển thị mức dùng mạng

Bạn chặn một ứng dụng trong tường lửa VPN Android, ứng dụng ngừng hoạt động, và dòng mức dùng của nó vẫn tiếp tục tăng. Kết luận hấp dẫn là chặn bị rò, hoặc bộ đếm bị hỏng. Không điều nào suy ra. Một bản ghi mức dùng nói rằng byte đã được gán cho danh tính đó tại một điểm quan sát nào đó; nó không nói gì về việc một dịch vụ từ xa có chấp nhận yêu cầu hay không. Khi bạn biết ranh giới nào được đo và danh tính nào bị tính, hai quan sát thôi mâu thuẫn với nhau.

Bộ đếm đo byte, không đo việc giao nhận

Android gán lưu lượng cho một UID và đếm nó theo cả hai chiều, và làm việc đó tại một ranh giới giao diện, không phải tại thời điểm yêu cầu của ứng dụng thành công.

Một nỗ lực kết nối bị từ chối vẫn làm di chuyển gói tin: SYN, gói đặt lại hoặc các lần truyền lại tiếp theo, cùng truy vấn DNS đã đi trước cả hai. Những byte đó tồn tại dù không có gì được giao, và trên một số đường đi chúng được đếm trước khi bất kỳ bộ lọc nào quyết định làm gì với chúng.

Đó là lý do dòng của một ứng dụng bị chặn có thể tăng trong khi mọi yêu cầu đều thất bại. Bộ đếm trả lời «bao nhiêu byte được gán cho danh tính này», không phải «danh tính này có tới được internet không». Một biểu đồ không thể phân biệt luồng được chấp nhận với cái bắt tay bị từ chối một cách lịch sự, và một tổng cộng cả hai chiều cũng không.

Việc gán đi theo UID, không theo biểu tượng

Dòng này tính theo UID, và một UID có thể được nhiều gói chia sẻ, trong khi một ứng dụng hiển thị có thể giao việc cho một thành phần riêng chạy dưới danh tính của chính nó. Một tab trình duyệt do tiến trình WebView dùng chung vẽ ra, một dịch vụ đồng bộ nền, hay một gói đồng hành cài bên cạnh ứng dụng chính đều tạo ra lưu lượng mà màn hình mức dùng có thể hiển thị dưới một cái tên bạn không ngờ tới, hoặc dưới ứng dụng mà bạn đã chặn. Gói bị chặn và trình trợ giúp mang yêu cầu của nó là hai chủ thể khác nhau, và quy tắc chỉ bao phủ một trong hai.

Khi các con số có vẻ sai, hãy so sánh UID chứ không phải nhãn. API mức dùng được truy vấn theo UID, và adb shell dumpsys package <package> | grep userId= in ra con số để so sánh, nên hai mục có cùng UID là cùng một danh tính theo góc nhìn của bộ đếm.

Cửa sổ thời gian có thể có trước quy tắc của bạn

Dữ liệu mức dùng được thu vào các nhóm và được truy vấn định kỳ, không truyền trực tiếp. Một tổng theo ngày có thể bao gồm những phút trước khi bạn bật chặn, một lần đồng bộ nền từ giờ trước, hoặc lưu lượng đã đang trên đường. So sánh một tổng tích lũy với một yêu cầu bị từ chối rồi gọi phần chênh lệch là rò rỉ là lỗi đo lường, không phải phát hiện của tường lửa.

Dùng cửa sổ ngắn hơn và khởi đầu sạch. Ghi lại mốc thời gian khi bạn đổi quy tắc, chờ một khoảng thu thập, rồi chỉ xem dữ liệu sau đó. Nếu tổng vẫn tăng trong một cửa sổ bắt đầu sau quy tắc, bạn có thứ để điều tra; nếu nó ngừng tăng, mức tăng trước đó là lịch sử đang được hiển thị.

Dịch vụ VPN có thể không phải cái bạn đã cấu hình

Một tường lửa VPN chỉ thấy lưu lượng mà dịch vụ của chính nó mang. Nếu một ứng dụng VPN khác khởi động và chiếm kết nối đang hoạt động, bộ lọc của bạn không còn trên đường đi trong khi giao diện của nó vẫn tồn tại trong cài đặt. Danh sách bỏ qua theo từng ứng dụng cũng làm điều đó một cách cố ý, và một hồ sơ loại trừ một ứng dụng không phải là rò rỉ khi ứng dụng đó sau này vẫn chạy.

IPv4, IPv6 và DNS cũng có thể lệch nhau. Một bộ lọc xử lý IPv4 có thể để IPv6 hoặc một trình phân giải DNS riêng ở ngoài nó, nên một phần lưu lượng của ứng dụng đi theo con đường mà các quy tắc của bạn chưa từng mô tả. Hãy kiểm tra ứng dụng nào đang sở hữu VPN và danh sách loại trừ nói gì trước khi viết lại bất cứ thứ gì:

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

Thử một yêu cầu mới và ghi lại bốn sự kiện

Chọn một yêu cầu vô hại, thực hiện một lần, và ghi lại bốn sự kiện: quy tắc đang áp dụng, UID của ứng dụng, trạng thái mạng và thời điểm. Sau đó kiểm tra xem bộ lọc của bạn có ghi nhận luồng hay không, và điểm đích hay cổng có thấy cùng kết nối đó không. Một luồng được nhận diện ở cả hai phía là bằng chứng; một tổng gộp thì không.

Một kết luận có thể bảo vệ nêu rõ điều gì đã bị từ chối và quan sát nào đã xác nhận điều đó. «Bộ đếm tăng» không phải là phát hiện, và «mọi bộ đếm mức dùng đều là giả» cũng không. Một khẩu hiệu về tầng OSI không giải quyết điều này: câu trả lời trung thực là bộ đếm và việc chặn có thể cùng đúng trong khi mô tả những thứ khác nhau. Tài liệu tham chiếu NetworkStatsManager của Android ghi lại cách các nhóm đó được truy vấn và gán.