Khi một ứng dụng Android ngừng hoạt động đúng lúc đường hầm được bật lên, ba thứ khác nhau có thể chịu trách nhiệm, và chúng tạo ra những lỗi trông giống nhau. Ứng dụng có thể đọc trạng thái mạng của chính điện thoại và từ chối cục bộ. Máy chủ có thể phân loại địa chỉ bạn đến từ đó và từ chối nó. Hoặc việc từ chối có thể chẳng liên quan gì đến VPN. Trình tự dưới đây thu thập bằng chứng trước khi thay đổi bất cứ điều gì, vì đổi lối ra là bước tốn kém nhất và ít có khả năng giúp ích nhất nếu kiểm tra là cục bộ.

Bước 1: tìm hiểu khi nào ứng dụng từ chối

Thời điểm là yếu tố phân biệt đầu tiên. Xóa bộ đệm nhật ký, tái hiện lỗi và xem ứng dụng đã làm gì trước khi phàn nàn:

adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60

Nếu ứng dụng từ chối trước khi bất kỳ yêu cầu gửi ra nào được thử, bạn đang xét một quyết định cục bộ. Nếu nó kết nối, gửi một thứ gì đó rồi mới hiện lỗi, sự từ chối đến từ phía bên kia. Nếu ứng dụng thất bại y hệt khi đường hầm tắt, VPN chưa bao giờ là biến số.

Coi thời điểm đó là bằng chứng chứ không phải bằng chứng quyết định. Ứng dụng có thể phát lại một phản hồi đã lưu trong bộ đệm, và các yêu cầu nền có thể đã thành công hoặc thất bại trước khi bạn nhìn. Ghi lại dấu thời gian của yêu cầu thành công cuối cùng và của lỗi, không chỉ khoảnh khắc thông báo xuất hiện.

Bước 2: đọc cách điện thoại tự nhìn mạng

Android hiển thị trạng thái VPN như một khả năng của mạng, nên ứng dụng không cần danh sách nhà cung cấp thương mại để nhận ra một đường hầm đang hoạt động. Nó hỏi dịch vụ kết nối mạng hiện tại là gì, và câu trả lời có một bit vận chuyển VPN:

val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true

Kiểm tra đó là cục bộ và rẻ, và nó giải thích cả một nhóm báo cáo "ứng dụng này không chạy qua VPN" mà không cần bất kỳ phân loại từ xa nào. Những gì ứng dụng có thể thấy vẫn phụ thuộc vào ngữ cảnh mạng của chính nó, nên đừng cho rằng mọi ứng dụng đều kiểm tra mọi hồ sơ trên thiết bị.

Từ một máy trạm, bạn thấy cùng trạng thái đó trên thiết bị thử nghiệm bằng adb shell dumpsys connectivity và bằng cách tìm mục mạng VPN. So sánh một lần chạy khi đường hầm bật với một lần chạy khi nó tắt, và giữ cả hai đầu ra.

Bước 3: đọc những gì máy chủ thực sự thấy

Người quan sát còn lại là dịch vụ. Nó thấy địa chỉ nguồn đi đến, và nó có thể hành động dựa trên địa chỉ, mạng lưu trữ phía sau, khu vực, nhà mạng hoặc các tín hiệu gắn với tài khoản và thiết bị. Không thứ nào trong đó là danh tính duy nhất, và việc chia sẻ địa chỉ khiến các chặn kèm theo trở nên bình thường: một địa chỉ bị hạn chế có thể làm hỏng những người dùng không liên quan phía sau cùng một phép dịch.

Lấy địa chỉ theo đúng đường mà ứng dụng dùng, không phải từ trình duyệt trên máy tính xách tay. Trên điện thoại, một yêu cầu đơn giản tới dịch vụ dội địa chỉ cho thấy phía xa nhận được gì, và so sánh nó với một yêu cầu qua mạng di động cho bạn biết địa chỉ có thay đổi hay không.

Nếu ứng dụng chạy qua mạng di động và thất bại qua đường hầm với cùng tài khoản, sự từ chối nằm ở đầu xa hoặc trong chính sách của ứng dụng. Nếu nó thất bại ở cả hai, VPN không phải là khác biệt và bạn nên dừng kiểm thử các điểm cuối.

Bước 4: khớp bằng chứng với một trong ba kết luận

Ba tổ hợp bao phủ gần như mọi báo cáo. Từ chối mà không có nỗ lực gửi ra trong khi đường hầm hoạt động chỉ về một kiểm tra vận chuyển cục bộ. Một yêu cầu đi ra rồi trở về với lỗi, hết thời gian trên một máy chủ cụ thể hoặc thông báo về khu vực chỉ về phía xa. Một lỗi lặp lại trên mạng di động không có đường hầm chỉ về tài khoản, phiên bản ứng dụng hoặc chính sách của dịch vụ, và không thay đổi VPN nào làm nó nhúc nhích.

Ghi kết luận cùng với bằng chứng tạo ra nó. Giá trị của bước này là nó dừng vòng lặp nơi ai đó đổi nút ra bốn lần để sửa một kiểm tra chạy ngay trên điện thoại.

Nó cũng giữ cho các tuyên bố trung thực. Tự lưu trữ thay đổi điểm cuối và lối ra internet của nó; nó không làm Android quên rằng một mạng VPN đang hoạt động và không bảo đảm được chấp nhận bởi một dịch vụ phân loại địa chỉ. Một bộ lọc cục bộ có thể kích hoạt trên mạng VPN bạn sở hữu dễ như trên một mạng thương mại.

Bước 5: đi theo con đường được hỗ trợ và xác minh

Bắt đầu với chính sách được ghi trong tài liệu của sản phẩm và người phụ trách hỗ trợ. Gửi phiên bản máy khách, thông báo chính xác và một khoảng thời gian lỗi hẹp; đừng gửi toàn bộ bản ghi lưu lượng hay thông tin đăng nhập chỉ để chứng minh rằng có lỗi.

Nếu dịch vụ cho phép truy cập trực tiếp và chính sách thiết bị cho phép, loại trừ theo từng ứng dụng là cơ chế được hỗ trợ, và nó cố ý đưa ứng dụng đó ra khỏi đường hầm thay vì giấu đường hầm. Lưu lượng của ứng dụng sau đó đi theo đường riêng, đó là một quyết định chính sách mà ai đó phải chịu trách nhiệm. Trong cấu hình chặn không có VPN, một ứng dụng bị loại trừ có thể chỉ đơn giản mất kết nối, nên hãy thử tổ hợp đó trước khi hứa nó hoạt động.

Sau mọi thay đổi, lặp lại bài kiểm tra thời điểm của bước một, xác nhận ứng dụng hoạt động và xác nhận mọi ứng dụng khác vẫn dùng đường hầm. Sau đó khôi phục cấu hình trước và kiểm tra xem lỗi có quay lại không, vì một bản sửa bạn không thể tái hiện là một sự trùng hợp bạn sẽ còn gặp lại.

Bài viết liên quan