Android 12 và IKEv1 VPN: phiên bản phát hành, IKEv2, ứng dụng bên thứ ba

Hai điện thoại cùng hiển thị Android 12 trong Cài đặt, và chỉ một trong số đó vẫn khởi động hồ sơ IPsec XAuth cũ mà cổng của bạn cung cấp. Khác biệt không phải một cài đặt mà người dùng chạm tới được: lớp bảo vệ chặn đường IKEv1 cũ gốc nhìn vào cấp SDK mà thiết bị được xuất xưởng, không chỉ bản phát hành nó đang chạy. Chi tiết duy nhất đó quyết định việc so sánh đội thiết bị có ý nghĩa hay không, và cũng quyết định bạn thực sự cần con đường di trú nào trong ba con đường.

Hai điện thoại Android 12 không phải cùng một ca kiểm thử

Thay đổi trong AOSP khiến thiết bị mới không thể khởi động hồ sơ IKEv1 cũ so sánh DEVICE_INITIAL_SDK_INT với Android S, tức API 31. Trên đường khởi động cũ gốc, một hồ sơ đủ điều kiện gây lỗi thao tác không được hỗ trợ trước khi có bất kỳ kết nối hữu ích nào. Một điện thoại xuất xưởng với Android 11 và được cập nhật sau đó vẫn vượt qua lớp bảo vệ đó; một mẫu ra mắt với Android 12 thì không.

Bạn có thể đọc hai con số trên thiết bị đã bật gỡ lỗi:

adb shell getprop ro.product.first_api_level
adb shell getprop ro.build.version.sdk
adb shell getprop ro.build.version.release

Giá trị đầu là cấp phát hành mà lớp bảo vệ quan tâm, giá trị thứ hai là thứ điện thoại đang chạy hôm nay. Ở nơi thuộc tính không có, hãy dựa vào tài liệu hỗ trợ của mẫu thay vì đoán từ tên tiếp thị, và đừng cho rằng bản dựng của nhà sản xuất giữ mọi đường tương thích mà bản phát hành gốc có.

Một điểm khác biệt nữa tiết kiệm một giờ thời gian hỗ trợ lãng phí: một hồ sơ đã lưu vẫn còn trong cài đặt VPN không chứng minh gì về việc nền tảng có khởi động nó hay không. Nhập lại PSK hay sửa tuyến đường không thể xóa một kiểm tra hỗ trợ giao thức chạy trước đó, và lỗi trông như vấn đề thông tin đăng nhập trong khi không phải.

Con đường một: giữ ngăn xếp cũ gốc ở nơi nó còn chạy

Ngăn xếp cũ là thứ đọc các hồ sơ IPsec XAuth PSK, IPsec Hybrid RSA và L2TP/IPsec PSK từ màn hình VPN của hệ thống. Trên thiết bị xuất xưởng dưới API 31, nó vẫn là con đường khả thi sau khi nâng cấp, vì vậy một thử nghiệm trên máy cũ có thể thành công trong khi máy mới từ chối cùng hồ sơ đó.

Việc so sánh quan trọng là theo lớp thiết bị, không theo phiên bản Android: liệt kê các mẫu trong đội, đọc cấp API phát hành của chúng và chia thành thiết bị còn khởi động hồ sơ và thiết bị không thể. Bất cứ điều gì khác tạo ra một chính sách hỗ trợ tự mâu thuẫn ngay khi người dùng mua điện thoại mới.

Con đường hai: hồ sơ IKEv2 của nền tảng

Mô hình cấp phát công khai của Android cho IKEv2 là một đối tượng khác, không phải hồ sơ IKEv1 được đổi tên. API nền tảng cho hồ sơ IKEv2 đến với API 30 và mong đợi IKEv2 với phương thức xác thực mà cổng cung cấp, thường dựa trên chứng chỉ hoặc EAP. Không có nâng cấp tương thích ở mức đường truyền từ IKEv1 XAuth hoặc Hybrid lên IKEv2: cổng phải được cấu hình cho giao thức mới, và hồ sơ phải mang danh tính khớp.

Đây là con đường có tuổi thọ dài nhất, và cũng là con đường phơi ra công việc thật. Xác thực danh tính, xác thực người dùng, DNS, tuyến đường chia tách và ủy quyền tài nguyên đều phải sống sót qua di trú; nếu chỉ bắt tay thành công, người dùng vẫn kết nối vào một đường hầm không tới đâu.

Triển khai thường đi qua MDM hoặc cấu hình được quản lý, không phải người dùng tự gõ các trường. Nếu hạ tầng đó chưa có, kế hoạch di trú phải bao gồm nó, vì nhập lại hồ sơ IKEv2 bằng tay trên từng thiết bị không phải thao tác mà bộ phận trợ giúp có thể gánh.

Con đường ba: ứng dụng khách bên thứ ba

Một số ứng dụng VPN mang theo cách triển khai giao thức riêng và không phụ thuộc vào ngăn xếp cũ gốc. Điều đó khiến chúng trở thành giải pháp tạm hợp lý cho một đội thiết bị không thể di trú nhanh, nhưng câu hỏi tương thích chuyển sang ứng dụng: liệu nó có triển khai đúng chế độ IKEv1 mà cổng của bạn nói, với xác thực và bộ mã hóa mà cổng yêu cầu.

Hãy coi ma trận hỗ trợ của chính ứng dụng là thẩm quyền chứ không phải mô tả trên cửa hàng, và kiểm tra một thiết bị thật với cổng thật trước khi đề xuất. Root điện thoại để khôi phục một đường nền tảng đã bị gỡ cũng không phải giải pháp được duy trì; nó chuyển vấn đề sang một cấu hình không được hỗ trợ mà bản cập nhật hệ thống kế tiếp có thể phá vỡ trong im lặng.

Chọn theo những gì cổng có thể cung cấp

Quyết định thu hẹp khi bạn biết hai điều: thiết bị nào ra mắt ở API 31 hoặc sau đó, và liệu cổng có thể trình bày dịch vụ IKEv2 với cùng mô hình đăng ký hay không. Nếu có, hãy di trú và ngừng đầu tư vào hồ sơ cũ. Nếu chưa, hãy giữ IKEv1 cho các thiết bị còn khởi động nó, và cho thiết bị mới một ứng dụng khách bên thứ ba như một ngoại lệ có tài liệu và có thời hạn thay vì một lối vòng không được nói ra.

Hai điểm làm kế hoạch đứng vững. Thứ nhất, ghi lại lý do của từng ngoại lệ cùng mẫu và cấp phát hành, để kiểm toán viên thấy ranh giới là lớp bảo vệ nền tảng chứ không phải sở thích không giải thích. Thứ hai, coi di trú là công việc có kế hoạch: IKEv1 đã bị xem là lỗi thời theo lộ trình tiêu chuẩn (RFC 9395), nghĩa là số thiết bị còn lại sẽ tiếp tục giảm và các ngoại lệ nên hết hạn cùng chúng.