Bộ đếm băng thông có cho biết bạn đã xem những trang nào qua VPN không?

Bạn mở trang lưu lượng của router, hoặc bảng điều khiển của nhà cung cấp VPN, và ở đó có tổng byte theo từng thiết bị kèm một biểu đồ bên cạnh. Thật dễ đọc biểu đồ đó như lịch sử duyệt web. Nó không phải, và lý do là về cấu trúc chứ không phải pháp lý. Bộ đếm cộng kích thước, còn lịch sử ghi lại đích đến và nội dung, và chỉ cái thứ hai mới cho biết ai đó đã đi đâu.

Hãy bắt đầu từ màn hình bạn đang đọc

Trước khi diễn giải một con số, hãy tìm hiểu điều gì tạo ra nó. Tổng theo thiết bị trên router thường đến từ bộ đếm của giao diện vật lý, tổng trong ứng dụng VPN đến từ đường hầm của nó, và bảng của nhà cung cấp đến từ việc tính toán ở đầu xa. Mỗi cái đếm một phần khác nhau của cùng một phiên. Hai bảng hiển thị số khác nhau cho cùng một giờ thường đều đúng.

Khoảng thời gian quan trọng ngang với nguồn. Tổng của cả vòng đời, bản tổng hợp theo ngày và tốc độ tức thời là ba phép đo khác nhau, và chỉ tốc độ tức thời có đủ độ phân giải để gắn với một hành động.

Hãy ghi nguồn và khoảng thời gian trước khi ghi kết luận.

Bộ đếm đo các lớp, không đo trang

Trên một peer WireGuard, các bộ đếm truyền tải trong wg show là tổng cho peer đó, bao gồm cả phần tải đã mã hóa. Kết quả trạng thái của OpenVPN báo cáo byte theo từng máy khách ở lớp của chính nó. Trên máy chủ, giao diện tun đếm gói IP bên trong trong khi card mạng vật lý đếm gói UDP bên ngoài, nên hai cái khác nhau bởi chi phí đóng gói và bởi mọi thứ khác dùng chung đường truyền.

Truyền lại làm phồng tổng lên mà không có nội dung mới nào đến, và một lần đồng bộ chạy nền có thể chiếm trọn một giờ trong khi người dùng đang đọc văn bản thuần.

Đó là lý do một tổng lớn gợi ý một hoạt động nặng về dữ liệu và không gì cụ thể hơn. Kích thước của tệp đã tải xuống và mức tăng của bộ đếm có liên quan, nhưng hiếm khi bằng nhau.

Một tổng có thể và không thể chứng minh điều gì

Một tổng byte không thể nêu tên một trang, vì tên và URL nằm bên trong các phiên TLS hoặc QUIC mà bộ đếm không bao giờ nhìn vào. Nó không thể tách một luồng video khỏi một bản sao lưu lớn, hay một lần tải trang khỏi vòng làm mới quảng cáo. Điều nó có thể chứng minh là một khẳng định về dung lượng và thời gian: thiết bị này đã truyền chừng ấy dữ liệu trong khoảng này.

Để biến điều đó thành khẳng định về một con người cần thêm hai thành phần, một danh tính và một sự tương quan.

Tài liệu RFC 6973 privacy considerations giải thích vì sao sự kết hợp đó quan trọng, và cũng vì thế một báo cáo cẩn thận tách điều được quan sát khỏi điều được suy ra. Nếu kết luận cần đến chữ vì, chỉ riêng bộ đếm không đủ bằng chứng.

Thời điểm và danh tính thay đổi câu trả lời

Gắn một bộ đếm với một người dùng có tên và một khoảng thời gian chính xác thì nó trở thành một đối tượng khác.

Khi đó bạn có thể đặt nó cạnh những quan sát khác: một bản ghi đăng nhập, một truy vấn DNS, một phiên trên hệ thống khác. Bộ đếm không tiết lộ đích đến, nhưng nó giúp người đã có giả thuyết xác nhận giả thuyết đó. Mã hóa bảo vệ nội dung và tên trên đường truyền, và nó không giấu việc đã có một luồng, luồng đó lớn chừng nào hay bắt đầu khi nào.

Đó là ranh giới trung thực: các mẫu hình thì thấy được, ý nghĩa thì không.

Hãy quyết định giữ lại gì trước khi thu thập

Nếu yêu cầu là quy hoạch dung lượng, một bản tổng hợp theo ngày thô là đủ và tốn ít. Nếu yêu cầu là lịch sử theo từng người dùng, hãy nói rõ điều đó, nêu tên các trường và khoảng lưu giữ, và coi quyết định đó là chính sách chứ không phải một tính năng của bảng điều khiển. Thu thập lịch sử chi tiết chỉ vì bảng điều khiển hỗ trợ là cách lưu giữ tăng lên mà không ai quyết định.

Khi khắc phục sự cố, hãy so bộ đếm với hành động bạn đang kiểm tra. Một tổng tăng đều chứng minh có lưu lượng chảy, không phải ứng dụng hoạt động.

Một bộ đếm đứng yên trong một phiên rõ ràng đang hoạt động thường có nghĩa là bạn đang đọc một giá trị được lưu đệm hoặc sai giao diện. Hãy nêu tên các trường được giữ lại và khoảng thời gian, và lần kiểm tra sau sẽ có thứ cụ thể để đối chiếu.