Vì sao lưu lượng gỡ lỗi không dây không phải bằng chứng rò rỉ VPN

Bạn đã bật gỡ lỗi không dây, kết nối một laptop, và phiên vẫn tiếp tục hoạt động trong khi VPN đang bật. Điều đó trông như có gì đó lọt qua đường hầm. Gần như chắc chắn là không. Một phiên gỡ lỗi và yêu cầu của ứng dụng tới một trang web là hai quan hệ mạng khác nhau, và chỉ một trong số đó mới phải đi qua đường hầm.

Tôi đã gặp cách hiểu sai này hai lần: một lần khi điện thoại và laptop cùng một Wi-Fi, và một lần sau khi khởi động lại khi cặp ghép vẫn còn. Trong cả hai trường hợp, VPN đang làm đúng những gì nó được cấu hình để làm.

Đặt tên cho quan sát trước khi đặt tên cho lỗi

Ba sự kiện có thể xảy ra trước một tuyên bố rò rỉ, và chúng không thể thay thế cho nhau. Một công cụ có thể khám phá dịch vụ, thiết bị có thể chấp thuận một máy trạm, hoặc một phiên được cấp quyền có thể thực sự mang lệnh và byte. Hãy ghi lại bạn đã thấy cái nào, vì mỗi cái chứng minh ít hơn người ta tưởng.

Việc phát hiện thường là mDNS hoặc quét cổng. Ghép cặp là quyết định đăng ký được đưa ra trên điện thoại, xác nhận bằng mã người dùng nhập. Một phiên đang sống nghĩa là lưu lượng đã di chuyển giữa hai điểm cuối đã ghép cặp. Không điều nào trong số đó mô tả yêu cầu HTTPS của ứng dụng đi đâu.

Giữ đích, giao diện, họ địa chỉ, dấu thời gian và hồ sơ người dùng gắn với sự kiện. Không có những chi tiết đó, không thể so sánh quan sát với chính sách mạng cục bộ dự định, hoặc với bản dựng VPN đang chạy lúc đó.

Vì sao hai đường đi không bao giờ gặp nhau

Gỡ lỗi không dây là kết nối đi vào thiết bị. adbd lắng nghe trên một cổng gắn với giao diện Wi-Fi, và máy trạm kết nối tới đó sau khi ghép cặp. Hướng đi quan trọng: laptop của bạn đi vào điện thoại, không phải ngược lại. Đó là điều ngược với rò rỉ hướng ra.

Lưu lượng internet của ứng dụng đi ra qua giao diện đường hầm do VpnService cài đặt, được khớp theo UID và quy tắc định tuyến. adbd là một daemon hệ thống chạy dưới người dùng shell, không phải một ứng dụng trong tập định tuyến đó. Nó vẫn ở trên liên kết Wi-Fi bên dưới ngay cả khi mọi ứng dụng được ghim vào đường hầm.

Chế độ khóa áp đặt đường hầm cho các ứng dụng được bao phủ. Nó không biến một socket đang lắng nghe thành đường ra.

Vì thế một phiên ADB hoạt động và một công tắc ngắt hoạt động cùng tồn tại mà không mâu thuẫn. Để chứng minh rò rỉ, bạn phải quan sát hướng lẽ ra phải bị chặn.

Một bài kiểm tra hướng ra thực sự trông thế nào

Kiểm tra ứng dụng được bao phủ, không phải kênh gỡ lỗi. Cố ý tạo điều kiện thất bại, sau đó thực hiện một yêu cầu mới và ghi lại điều đã xảy ra.

1. Xác nhận VPN là đường duy nhất: bật VPN luôn bật với chặn kết nối không có VPN.
2. Dừng VPN theo cách được hỗ trợ và xác nhận ứng dụng báo không có kết nối.
3. Gửi một yêu cầu vô hại từ ứng dụng đó và ghi nhận nó thất bại hay thành công.
4. Lặp lại với gỡ lỗi không dây bật, rồi tắt, để cô lập biến số.

Một yêu cầu bị chặn trong những điều kiện đó là bằng chứng. Một phiên ADB thành công thì không, và một ping từ ứng dụng terminal cũng không.

Nếu yêu cầu thực sự thành công khi chế độ khóa đang bật, hãy ghi lại UID của ứng dụng và quyền VPN của nó, mạng đang hoạt động và phiên bản máy khách. Sự kết hợp đó là một phát hiện thật.

Cặp ghép sống lâu hơn phiên

Cặp ghép là trạng thái bền vững, không phải một cái bắt tay có thể quên sau bài kiểm tra cáp. Tài liệu gỡ lỗi của Android mô tả quy trình không dây và lưu ý rằng quan hệ tồn tại cho đến khi bị quên một cách rõ ràng hoặc các quyền bị thu hồi.

Kiểm tra xem còn gì được cấp quyền trước khi đổ lỗi cho đường hầm. Mở Gỡ lỗi không dây, xem Thiết bị đã ghép cặp, và quên mọi thứ bạn không còn nhận ra. Chạy adb devices từ máy trạm để xem mục nào còn trả lời, và adb disconnect để bỏ một mục đã cũ. Tắt gỡ lỗi không dây sẽ đóng hoàn toàn cổng lắng nghe.

Trên mạng chia sẻ hoặc không đáng tin cậy, hãy để nó tắt. Một quyền bền vững trên mạng bạn không kiểm soát là vấn đề lớn hơn một giả thuyết vượt TUN.

Trước khi bạn báo lỗi đó

Một báo cáo hữu ích nêu đúng ranh giới đã thất bại. Bao gồm kiểu thiết bị và phiên bản Android, ứng dụng khách VPN và phiên bản, chế độ khóa có bật hay không, gói ứng dụng và UID, và mạng mà điện thoại đang ở. Thêm lệnh hoặc yêu cầu đã tạo ra quan sát, cùng thời điểm nó xảy ra. Không có những thứ đó, không ai có thể tái tạo ranh giới mà bạn cho là hỏng.

Đừng tắt việc thực thi hoặc phơi bày gỡ lỗi trên mạng không đáng tin cậy để bài kiểm tra trông kịch tính hơn. Điều đó thay đổi hệ thống bạn đang đo và để lại bằng chứng không ai có thể lặp lại.

Nếu bằng chứng duy nhất của bạn là ADB đã kết nối trong khi VPN bật, bạn đã đo sai đường. Hãy chạy lại bài kiểm tra ở mức ứng dụng trước; câu trả lời thường đến ở đó.