Chế độ SOCKS của NetGuard chỉ bao phủ TCP, không phải mọi giao thức
NetGuard lọc lưu lượng qua giao diện VPN của Android và có thể chuyển các kết nối được hỗ trợ sang SOCKS. UDP, DNS và khả năng tiếp cận giữa các hồ sơ cần một cuộc kiểm tra riêng.
NetGuard chiếm giao diện VPN của Android để lọc lưu lượng, và có thể chuyển các kết nối được hỗ trợ đến một điểm cuối SOCKS. Hai sự thật này thường được đọc thành “điện thoại đang ở trên VPN”, một kết luận mà cơ chế này không ủng hộ. Bộ lọc thấy các gói tin; proxy chỉ thấy những kết nối thực sự được chuyển cho nó. Giữa hai phát biểu đó là toàn bộ câu hỏi về phạm vi bao phủ.
FAQ của dự án gốc ghi lại cả giới hạn một dịch vụ và tùy chọn SOCKS. Sự tồn tại của tùy chọn không phải bằng chứng rằng mọi gói tin được phép đều dùng nó, và các câu hỏi về phạm vi nảy sinh chính từ khoảng trống đó.
Hai đường chuyển tiếp bên trong một ứng dụng
Phía TCP của phần triển khai có xử lý kết nối SOCKS, nên một kết nối TCP được phép có thể được thương lượng với proxy và được mang qua nó. Phía UDP có một đường socket riêng, và việc xử lý gửi nhận của nó không phụ thuộc vào cuộc thương lượng TCP đó. Vì vậy một datagram mà bộ lọc cho phép có thể đến mạng thông thường mà không bao giờ đi qua proxy. Không điều nào trong số này là lỗi của ứng dụng; đó đơn giản là những gì hai đường thực thi.
Sự khác biệt này có một hệ quả mà người ta mô tả sai theo cả hai hướng. Gọi mọi gói UDP là rò rỉ bỏ qua các quy tắc chặn, vì một datagram bị từ chối không bao giờ rời đi. Gọi toàn bộ cách bố trí là VPN bỏ qua đường trực tiếp được phép, vì một phần lưu lượng thực sự đi ra mà không qua proxy. Thứ bạn có là một thiết bị được lọc với proxy một phần, và mô tả trung thực là một ma trận, không phải một nhãn.
Quảng cáo UDP không phải là triển khai nó
Một máy chủ SOCKS tuyên bố hỗ trợ UDP không thêm phần xử lý phía máy khách tương ứng vào ứng dụng trên điện thoại của bạn. Các tính năng lý thuyết của giao thức và hành vi của bản dựng đã cài đặt là những chủ đề khác nhau, và chỉ cái thứ hai mô tả lưu lượng của bạn.
Hãy kiểm tra phiên bản và cấu hình bạn thực sự chạy, sau đó thử một luồng datagram vô hại và quan sát xem nó có xuất hiện ở proxy không. Mọi thứ khác là suy luận từ danh sách tính năng, và danh sách tính năng mô tả ý định chứ không phải đường đi của mã.
DNS là đường thứ ba, không phải chi tiết
Việc phân giải tên thêm nhánh riêng của nó vào ma trận. Một bộ chuyển tiếp DNS cục bộ, một truy vấn UDP thông thường, một tên máy chủ đích do chính proxy phân giải và một bộ phân giải mã hóa trong trình duyệt là bốn cách bố trí khác nhau. Chúng khác nhau ở việc ai nhìn thấy truy vấn và đường mạng nào mang nó, và trộn chúng lại tạo ra một thử nghiệm không chứng minh được gì về những cái còn lại.
Hãy quyết định có ý thức xem bạn muốn cái nào. Nếu yêu cầu là tên được phân giải qua đường hầm, chỉ một thiết lập trình duyệt sẽ không đáp ứng được, và một proxy tự phân giải tên máy chủ chỉ thay đổi câu trả lời cho những kết nối mà nó thực sự xử lý.
Việc truyền qua proxy không tự động là riêng tư
SOCKS đơn thuần không phải là một liên kết mã hóa từ điện thoại đến proxy. Nếu điểm cuối được tiếp cận qua một đường được bảo vệ khác, hãy nêu tên đường đó và chính sách khi lỗi của nó, vì việc quay lại mạng mở sẽ biến một cách bố trí riêng tư thành công khai mà không cảnh báo. Việc xác thực của chính proxy cũng quan trọng: một bộ lắng nghe mở trên thiết bị chia sẻ là dịch vụ mà không ai chịu trách nhiệm.
Các cách bố trí giữa các hồ sơ cũng đáng được xem xét như vậy. VPN của hồ sơ công việc chỉ bảo vệ lưu lượng dùng đường của nó, và sự cùng tồn tại của tường lửa hồ sơ cá nhân với đường hầm công việc không chứng minh rằng kết nối tiếp theo của tường lửa đến được đường hầm đó. Hãy xác minh khả năng tiếp cận và xác thực thay vì cho rằng hai hồ sơ hợp tác với nhau.
Kiểm tra phạm vi bằng ma trận, không phải bằng việc tải trang
Đối với một đánh giá được ủy quyền, hãy chọn những ví dụ vô hại đại diện cho từng lớp mà bạn quan tâm: TCP bắt buộc, UDP được phép và DNS trong cả hai họ địa chỉ. Với mỗi cái, ghi lại xem nó có qua proxy, bị chặn hay được gửi trực tiếp. Bảng duy nhất đó chính là kết quả, và nó hữu ích hơn nhiều so với ảnh chụp màn hình của một trang đã tải.
Nếu yêu cầu là toàn bộ lưu lượng ứng dụng được chọn phải đi qua một đường hầm từ xa, hãy chọn một phần triển khai có hỗ trợ rõ ràng việc lọc và đóng đường hầm kết hợp. Một thành phần chỉ có proxy TCP vẫn hữu ích cho các nhiệm vụ hẹp hơn, miễn là lưu lượng khác được xử lý có chủ đích chứ không bị quên.