Always On VPN và VPN On Demand trên iPhone: nên triển khai cái nào

Hai chiếc iPhone đều có thể nói VPN nhưng hành xử hoàn toàn khác nhau. On Demand mở đường hầm khi một quy tắc khớp, và người dùng vẫn có thể tắt nó trong Cài đặt. Always On được quản lý giữ vùng phủ được thực thi trên thiết bị được giám sát, kể cả những lúc đường hầm không thể dựng lên. Hãy chọn bằng cách hỏi điều gì phải đúng khi người dùng không làm gì, rồi kiểm tra các chuyển tiếp thay vì trạng thái ổn định. Các bước dưới đây đi theo thứ tự mà một lần triển khai thực sự thất bại.

Bước 1: xác định thiết bị có thể thực thi điều gì

Always On là tính năng của thiết bị được giám sát. Nếu đội thiết bị không được giám sát, cuộc thảo luận kết thúc trước khi bắt đầu, và không khóa payload nào biến một điện thoại không được giám sát thành thiết bị bị ép buộc. Xác nhận giám sát từ phía quản lý và từ thiết bị, rồi xác nhận ai đã ký hồ sơ.

Trên điện thoại, mở Cài đặt, rồi Cài đặt chung, rồi VPN và Quản lý thiết bị. Mục hồ sơ nêu chủ sở hữu, và hồ sơ cá nhân cài thủ công trông khác với hồ sơ do dịch vụ quản lý gửi đến. Đừng suy ra việc thực thi từ tên hồ sơ hay nhãn tiếp thị của nhà cung cấp; nhãn không phải chính sách của nền tảng.

Ghi lại ba sự thật trước khi chạm vào cấu hình: được giám sát hay không, hồ sơ được quản lý hay cá nhân, và cách triển khai ứng dụng khách nào mang đường hầm. Mọi bước sau phụ thuộc vào ba điều đó, và việc chuyển hành vi từ điện thoại cá nhân sang hồ sơ được quản lý là cách một lần triển khai được duyệt theo đường cơ sở sai.

Bước 2: đọc các quy tắc on-demand chứ không đọc tên tính năng

On Demand là một danh sách quy tắc được đánh giá theo thứ tự. Mỗi quy tắc nêu một hành động và các điều kiện chọn nó, và điều kiện mới là phần thú vị: loại giao diện, Wi-Fi SSID, hậu tố miền DNS, hay một URL thử nghiệm. Một bộ quy tắc không bao giờ khớp là tính năng không bao giờ kết nối.

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

Đọc toàn bộ mảng và hỏi hai câu cho mỗi quy tắc: điều kiện này có bao giờ đúng trên đội thiết bị này không, và điều gì xảy ra khi không quy tắc nào khớp? Mạng doanh nghiệp đổi tên điểm truy cập, gộp SSID và đổi hậu tố DNS, và mỗi thay đổi đó lặng lẽ tách một quy tắc khỏi thực tế.

Điều kiện hậu tố DNS là điều kiện hay sai nhất ngoài thực địa, vì hậu tố mà điện thoại báo trên mạng khách không phải hậu tố mà trình phân giải của công ty phục vụ. Hãy kiểm chứng tên mà thiết bị thực sự phân giải trước khi tin vào quy tắc.

Bước 3: kiểm tra các chuyển tiếp, không phải kết nối tĩnh

Một đường hầm đang dựng trong lúc bạn nhìn chỉ chứng minh rất ít. Thực hiện từng chuyển tiếp một cách có chủ đích và ghi lại thiết bị làm gì, dùng cùng một tài nguyên riêng tư mỗi lần để kết quả so sánh được:

• Kết nối vào mạng nơi một quy tắc phải khớp, rồi yêu cầu tài nguyên riêng tư và xác nhận nó tải được.
• Chuyển sang mạng di động khi ứng dụng ở chế độ nền, rồi đưa lên trước và lặp lại yêu cầu.
• Kết nối Wi-Fi có captive portal và xem cổng có truy cập được hay việc thực thi chặn mọi thứ trước khi bạn xác thực được.
• Tắt đường hầm thủ công trên thiết bị được giám sát và kiểm tra xem nó có tự trở lại không, và nhanh đến mức nào.

Chạy cùng danh sách đó trên một thiết bị không được giám sát nếu bạn có. Khác biệt giữa hai kết quả chính là hành vi thật của lần triển khai, và đó là phần mà ảnh chụp màn hình một đường hầm đang kết nối không bao giờ cho thấy.

Bước 4: biết hai dạng thất bại

Vùng phủ bị ép buộc thất bại bằng cách chặn. Khi đường hầm không dựng được, thiết bị mất truy cập internet thông thường cùng với tài nguyên riêng tư, và người dùng gặp một chiếc điện thoại đang trực tuyến nhưng không duyệt web được. Kết nối lại và chặn là hai quan sát riêng biệt, nên hãy ghi cả hai thay vì coi không có internet là một triệu chứng duy nhất.

On Demand thất bại bằng cách không kích hoạt. Quy tắc không khớp, không có đường hầm nào xuất hiện, và tài nguyên riêng tư chỉ đơn giản hết thời gian chờ. Dễ chẩn đoán nhầm đây là sự cố máy chủ, vì ứng dụng khách hành xử đúng như đã cấu hình.

Captive portal nằm giữa hai trường hợp: nó cần kết nối trước khi đường hầm tồn tại, nên một chính sách chặn mọi thứ cho đến khi đường hầm dựng lên cần một đường đi được ghi lại qua cổng. Hãy quyết định điều đó trong thiết kế, không phải ở bộ phận hỗ trợ.

Bước 5: kiểm chứng, rồi tập dượt việc quay lui

Việc kiểm chứng thuộc về con đường thật với lưu lượng vô hại: yêu cầu một tài nguyên riêng tư không được phép công khai, xác nhận thiết bị trình ra địa chỉ nào với bên ngoài, và lặp lại sau khi khởi động lại để thấy trình tự khởi động chứ không chỉ trạng thái đã ấm.

Sau đó tập dượt việc gỡ bỏ trên một thiết bị thử nghiệm trước khi cần đến nó trong môi trường thật. Gỡ hồ sơ đưa thiết bị về trạng thái trước đó, và biết việc đó mất bao lâu cùng người dùng thấy gì là một phần của cẩm nang. Hướng dẫn bảo mật VPN của Apple là tài liệu tham chiếu cho những gì nền tảng ghi lại về các chính sách này, và đáng đọc trước khi viết một cấu hình khẳng định nhiều hơn nền tảng.

Giữ ba sự thật từ bước một bên cạnh bộ quy tắc và kết quả kiểm tra. Khi người tiếp theo hỏi tại sao điện thoại kết nối trên mạng này mà không phải mạng khác, những ghi chú đó trả lời trong một phút thay vì phải dựng lại.