Bạn cần một màn hình hành xử khác đi khi đường hầm đang hoạt động, và không có lời gọi nào cho bạn biết điều đó. Đây là ràng buộc khi phát hành: trên macOS không framework công khai nào báo cáo liệu một VPN bất kỳ có được kết nối hay không, và trên iOS trạng thái thuộc về ứng dụng đã cài đặt cấu hình. Các bước kiểm tra dưới đây đi từ giới hạn đó đến một thứ bạn có thể phát hành, và bất kỳ bước nào cũng có thể kết thúc việc tìm kiếm sớm.

Kiểm tra 1: câu hỏi này có trả lời được không?

Sandbox giải quyết câu hỏi trước bất kỳ API nào. Một tiến trình bên thứ ba không thể liệt kê phần mở rộng của nhà cung cấp khác, và cũng không thể đọc cấu hình của phần mở rộng đó, nên không có đối tượng được hỗ trợ nào để hỏi.

Mọi cách lách đều đâm vào cùng một bức tường. Danh sách giao diện, scutil --nc list và việc đọc trực tiếp cấu hình hệ thống hoặc cần quyền mà sandbox giữ lại hoặc phụ thuộc vào hành vi mà Apple chưa bao giờ hứa. Nếu kế hoạch cần một trong những thứ đó, vấn đề là kế hoạch. Một tính năng xây trên chi tiết không được ghi chép là một phiếu hỗ trợ có ngày giao hàng.

Kiểm tra 2: ứng dụng của bạn có tự quản lý đường hầm không?

Nếu có, bạn có một câu trả lời được hỗ trợ cho cấu hình của riêng mình. Tải tùy chọn, xử lý lỗi, rồi đọc trạng thái và đăng ký nhận thay đổi thay vì thăm dò định kỳ:

vpnManager.loadFromPreferences { error in
    // handle a load failure before reading status
}

NotificationCenter.default.addObserver(
    forName: .NEVPNStatusDidChange,
    object: nil,
    queue: nil
) { note in
    let status = (note.object as? NEVPNConnection)?.status
}

Hãy chính xác về những gì lệnh này trả về: trạng thái của đường hầm bạn đã cài. Người dùng chạy một ứng dụng khách khác sẽ hiện là đã ngắt kết nối, và đó không phải lỗi trong mã của bạn. Hãy quyết định tính năng của bạn thực sự đang hỏi câu nào trong hai câu này trước khi xây dựng trên câu trả lời.

Kiểm tra 3: một heuristic thực sự cho bạn biết điều gì?

Cách làm được sao chép rộng rãi hỏi từ điển proxy của hệ thống về các mục có phạm vi và đọc các khóa, mà tình cờ là tên giao diện:

let settings = CFNetworkCopySystemProxySettings()?.takeRetainedValue() as NSDictionary?
let scoped = settings?["__SCOPED__"] as? [String: Any]
let names = scoped?.keys ?? []

Một khóa bắt đầu bằng tap, tun, ppp, ipsec hoặc utun ngụ ý rằng có một giao diện thuộc phạm vi đường hầm. So khớp toàn bộ tên thất bại ngay lập tức, vì iOS 12 đi kèm utun1 và utun2 và một số cấu hình xuất hiện dưới dạng ipsec4, ppp0 hoặc utun0. Hãy so sánh tiền tố thay vào đó.

Dù vậy, một cái tên không xác định chủ sở hữu. Các tính năng hệ thống và phần mở rộng của nhà cung cấp khác cũng tạo ra giao diện utun, và một cái có thể tồn tại mà không mang chút lưu lượng nào của bạn. Hãy đọc đó như một gợi ý rằng có thứ gì đó hình ống gần đây, không hơn. Dương tính giả ở đây rẻ nếu bạn chỉ chặn một tính năng, và đắt nếu bạn chặn màn hình đăng nhập.

Kiểm tra 4: bạn có thể kiểm tra đích đến thay vào đó không?

Nếu ứng dụng chỉ cần biết một dịch vụ nội bộ có thể truy cập được hay không, hãy kiểm tra dịch vụ đó. Một phép thử ngắn có thời gian chờ trả lời câu hỏi mà tính năng thực sự phụ thuộc vào, và nó tiếp tục hoạt động khi người dùng đổi ứng dụng khách hoặc đường hầm đổi hình dạng.

Khả năng truy cập là một quan sát về đường đi của bạn. Tên giao diện là một suy luận về thứ gì đó liền kề đường đi của bạn, vì thế heuristic tạo ra tranh cãi trong báo cáo lỗi còn phép thử tạo ra bằng chứng. Nếu phép thử thất bại trong khi người dùng khẳng định VPN đang bật, giờ bạn có một đường đi cụ thể để gỡ lỗi: phân giải tên, tuyến đường hoặc quyền của dịch vụ.

Kiểm tra 5: nền tảng có thể thực thi điều bạn cần không?

Khi yêu cầu là bảo đảm rằng không gì thoát khỏi đường hầm, hồ sơ cấu hình là nơi đúng, không phải bộ phát hiện. Bật includeAllNetworks trong cấu hình đường hầm đầy đủ trên iOS 14 trở lên sẽ thay đổi hành vi nền tảng thay vì bắt ứng dụng của bạn suy ra. Cờ này được ghi chép trong tài liệu tham chiếu NEVPNProtocol.

Đó là một kiểu câu trả lời khác: thực thi thay vì quan sát. Nó cũng chỉ áp dụng cho hồ sơ cấu hình bạn kiểm soát, nên không giúp được ứng dụng tiêu dùng đang theo dõi đường hầm của người khác.

Kiểm tra 6: làm cho thất bại an toàn và quan sát được

Chỉ tắt khả năng cần đường hầm và để phần còn lại của ứng dụng dùng được. Một bộ phát hiện ẩn toàn bộ giao diện mỗi khi không chắc chắn sẽ tạo ra gián đoạn cho bất kỳ ai có đường hầm dùng tên mà bạn chưa bao giờ lường trước. Hãy quay về hành vi thận trọng: các tính năng cục bộ vẫn hoạt động và chỉ lời gọi từ xa thực sự cần đường hầm bị vô hiệu hóa. Lựa chọn đó là một quyết định sản phẩm, và nó xứng đáng được ghi lại bên cạnh heuristic.

Ghi lại những gì bạn quan sát: tên giao diện, phiên bản nền tảng và kết quả của một phép thử. Điều đó biến báo cáo tiếp theo từ tranh cãi thành kiểm tra. Sau đó hãy ưu tiên một khai báo được hỗ trợ khi bạn có, vì cấu hình được quản lý có thể mang ý định một cách rõ ràng và loại bỏ phần lớn lý do phải kiểm tra tên.

Nếu các bước kiểm tra 1 đến 5 để bạn không có câu trả lời được hỗ trợ, hãy phát hành phép thử và dán nhãn kết quả một cách trung thực. Một tín hiệu nỗ lực tốt nhất được ghi chép là quyết định sản phẩm tốt hơn một API riêng sẽ hỏng ở bản phát hành tiếp theo.

Bài viết liên quan