Cách đọc trạng thái VPN và proxy của một ứng dụng công việc được quản lý

Một ứng dụng công việc gặp lỗi trên điện thoại được quản lý, ai đó kiểm tra công tắc VPN, thấy nó bật và tuyên bố đường đi khỏe mạnh. Đây là nơi phần lớn các chẩn đoán này dừng lại, và như vậy là quá sớm: một transport VPN đang hoạt động không nói rằng các yêu cầu của ứng dụng này đã dùng nó, và proxy thực sự áp dụng có thể là theo từng ứng dụng hoặc do một tệp PAC chọn thay vì được hiển thị trong Cài đặt. Hãy bắt đầu từ ứng dụng và hồ sơ cụ thể mà bạn đang gỡ lỗi, rồi đọc góc nhìn của chính nền tảng về đường đi.

Bắt đầu từ ứng dụng và hồ sơ của nó

Một ứng dụng có huy hiệu công việc thường chạy trong một hồ sơ riêng với chính sách mạng của nó. Một trình duyệt cá nhân trên cùng điện thoại không phải là bằng chứng cho nó, và kết quả từ thiết bị của đồng nghiệp với cách quản lý khác cũng không. Hãy ghi lại ứng dụng thuộc hồ sơ nào trước khi đọc bất cứ điều gì.

Trong Cài đặt, liệt kê các mục VPN đã cấu hình và ghi lại ai sở hữu từng mục. Trên các bản dựng Samsung, nhãn menu thay đổi giữa các bản phát hành, nên hãy mô tả mục nhập thay vì đường dẫn đến nó. Một mục bị làm xám hoặc được quản lý thuộc về người quản trị thiết bị; tắt nó như một thử nghiệm sẽ thay đổi thứ bạn đang cố đo và có thể trái với chính sách.

Đọc trạng thái mà nền tảng báo cáo

Bên trong một activity hiện có trong công cụ hỗ trợ của bạn, trên API 23 trở lên, trạng thái mạng có thể được đọc mà không gửi một byte nào. Lệnh gọi cần quyền manifest thông thường ACCESS_NETWORK_STATE để đọc các khả năng.

val cm = getSystemService(android.net.ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val caps = network?.let { cm.getNetworkCapabilities(it) }
val hasVpn = caps?.hasTransport(android.net.NetworkCapabilities.TRANSPORT_VPN)
val proxy = cm.defaultProxy

Mỗi giá trị trả lời một câu hỏi hẹp. Mạng đang hoạt động là mạng mặc định của tiến trình gọi tại thời điểm đó. Việc kiểm tra khả năng cho bạn biết mạng mặc định đó có được VPN hỗ trợ hay không. Lệnh gọi proxy báo cáo proxy HTTP mặc định hiệu lực, và đối tượng trả về có thể mô tả proxy tĩnh hoặc một script PAC.

Nếu bạn cần góc nhìn theo từng mạng thay vì mặc định, hãy đọc các thuộc tính liên kết của cùng mạng đó và so sánh với cm.getLinkProperties(network)?.httpProxy. Một proxy do quản lý thiết bị cài đặt xuất hiện trong lệnh gọi proxy mặc định và không xuất hiện trong thuộc tính liên kết, đây là cách nhanh để phân biệt proxy do chính sách cung cấp với proxy do mạng cấp.

Giữ đầu ra trong kênh hỗ trợ của bạn thay vì trong một báo cáo công khai. Tên máy chủ proxy, URL PAC và hậu tố nội bộ tiết lộ cách tổ chức của bạn định tuyến lưu lượng, và không cái nào trong số đó cần thiết để mô tả sự cố.

Diễn giải từng trường theo nghĩa hẹp

Một mạng null hoặc một đối tượng khả năng null nghĩa là trạng thái mạng của bên gọi không khả dụng hoặc đã thay đổi trong khi đọc. Điều đó không có nghĩa là không có VPN. Hãy coi đó là chưa biết và đọc lại sau khi ứng dụng lên trước, chứ không phải như một kết quả phủ định.

Transport VPN là tín hiệu yếu nhất trong các tín hiệu khẳng định. Bất kỳ ứng dụng nào giữ một VpnService đều tạo ra một cái, kể cả một ứng dụng lọc cục bộ không bao giờ gửi lưu lượng của bạn đi đâu cả. Vì vậy giá trị true nói rằng tồn tại một mạng mặc định được VPN hỗ trợ, không phải rằng lối ra của tổ chức bạn đã được dùng và chắc chắn không phải rằng đã có kiểm tra.

Một proxy mặc định null nghĩa là API này không báo cáo proxy HTTP mặc định nào cho cấu hình hiệu lực. Nó loại trừ rất ít: một ứng dụng có thể mang cấu hình SOCKS riêng, tự triển khai HTTP client riêng, hoặc bị điều hướng bởi một proxy tại gateway mà thiết bị không bao giờ biết.

PAC là trường hợp đánh bại câu trả lời một giá trị. Một script có thể định tuyến một đích qua proxy và gửi một đích khác trực tiếp, nên hai yêu cầu của cùng một ứng dụng trong một giây có thể đi theo các đường khác nhau. Và một ứng dụng buộc socket của nó vào một mạng đã chọn, hoặc gọi bindProcessToNetwork, không bắt buộc phải theo mặc định chút nào.

Điều ảnh chụp này không thể cho bạn biết

Đây không phải là lịch sử. Không có gì ở đây ghi lại yêu cầu thất bại đã đi theo đường nào, và một lần đọc thành công sau thất bại không phải là bằng chứng về thất bại. Đây cũng không phải bản kiểm kê: bạn nhận được mạng mặc định của tiến trình gọi, không phải danh sách các kết nối riêng của từng ứng dụng.

Nó cũng không nói gì về những gì xảy ra phía trên socket. Một bắt tay TLS thất bại trên thiết bị được quản lý có thể là vấn đề kho tin cậy, sự không khớp ghim hoặc một tên mà proxy từ chối, và không cái nào xuất hiện trong một lần đọc kết nối.

Đó là lý do hai nửa quan trọng cùng nhau: ảnh chụp thu hẹp nơi cần nhìn, và chẩn đoán của chính ứng dụng nói điều gì thực sự thất bại.

Báo cáo theo hình thức một quản trị viên có thể dùng

Nêu ứng dụng bị ảnh hưởng, hồ sơ, dấu thời gian và giai đoạn chính xác đã thất bại: phân giải tên, kết nối TCP, bắt tay TLS hoặc một trạng thái HTTP. Thêm các giá trị của ảnh chụp đúng như đã đọc, với null được viết là null chứ không phải là không có gì. Ghi lại liệu các ứng dụng khác trong cùng hồ sơ có thất bại theo cùng cách hay không, điều này tách vấn đề của ứng dụng khỏi vấn đề đường đi trên toàn hồ sơ.

Sau đó dừng lại và để chủ sở hữu đường đi phản hồi. Đừng coi chứng chỉ doanh nghiệp, địa chỉ proxy hoặc mục VPN là quyền gỡ bỏ quản lý hoặc vượt qua tuyến đã được phê duyệt; điều đó biến một ca hỗ trợ thành sự cố chính sách.

Hợp đồng proxy mặc định ngắn và đáng đọc một lần, vì nó xác định chính xác proxy nào mà lệnh gọi báo cáo, và mọi cách đọc quá mức ảnh chụp này đều bắt đầu bằng giả định rằng nó báo cáo nhiều hơn.