Niềm tin sai lầm là fail-closed là thiết lập an toàn còn fail-open là cẩu thả. Cả hai đều mô tả điều gì xảy ra với lưu lượng sau khi đường hầm biến mất, và không cái nào thay đổi mức độ mã hóa của đường hầm đó. Một chính sách fail-closed với danh sách ngoại lệ dài có thể rò rỉ nhiều hơn chính sách fail-open trên thiết bị không bao giờ rời khỏi mạng văn phòng. Hãy chọn kết quả mà bạn có thể giải thích cho người sở hữu lưu lượng.

Nhãn mô tả kết quả, không phải sức mạnh

Từ vựng đến từ các hệ thống điều khiển: fail-open cho phép hoạt động khi một thành phần hỏng, fail-closed từ chối. Áp dụng cho VPN, thành phần hỏng là đường hầm, và câu hỏi là lưu lượng có được phép tiếp tục theo đường khác hay không. Việc chọn mật mã, độ dài khóa và giao thức là những quyết định riêng.

Sự nhầm lẫn còn tồn tại vì kill switch nghe như một tính năng bảo mật, và nhà cung cấp tiếp thị nó như vậy. Về mặt cơ chế, nó là một quy tắc định tuyến và tường lửa chặn lưu lượng mà đường hầm lẽ ra phải mang, được triển khai trong ứng dụng khách, trong hệ điều hành hoặc trên cổng nối. Tầng nào thực thi thì tầng đó cũng định nghĩa phạm vi của nó, và quy tắc ở một tầng không bao phủ tầng khác. Quy tắc trên cổng nối không thể bảo vệ máy tính xách tay đã chuyển sang mạng khác.

Mỗi kết quả trông như thế nào

Cùng một chính sách có thể hành xử rất khác nhau tùy theo lỗi bạn gặp, vì vậy hãy so sánh sự kiện chứ không phải nhãn.

EventFail-open resultFail-closed result
Tunnel drops while a transfer runsTransfer continues on the direct pathTransfer stalls until the tunnel returns
Client exits or crashesRules disappear with the processRules persist only if the OS owns them
Device boots before sign-inNormal network accessBlocked until the VPN connects
Captive portal neededPortal loads normallyPortal unreachable without an exception
IPv6 not carried by the tunnelIPv6 traffic leaks directlyLeaks too, unless the block covers IPv6

Hàng cuối là hàng bắt được những người cho rằng kill switch là một công tắc duy nhất. Một quy tắc viết cho bảng định tuyến IPv4 để nguyên tuyến mặc định IPv6, và ứng dụng có thể vui vẻ dùng nó.

Phạm vi quyết định có rò rỉ hay không

Hỏi chính sách bao phủ những gì trước khi hỏi đó là chế độ nào. Quy tắc theo từng ứng dụng bảo vệ một ứng dụng và không gì khác, quy tắc toàn thiết bị bảo vệ mọi thứ trừ các ngoại lệ, và quy tắc trên cổng nối chỉ bảo vệ lưu lượng đến được cổng đó. DNS cần quyết định riêng, vì truy vấn gửi tới trình phân giải cục bộ có thể tiết lộ tên ngay cả khi tải trọng bị chặn.

Các ngoại lệ mạng cục bộ tồn tại cho máy in, truyền màn hình và cổng đăng nhập, và mỗi cái là một lỗ trong chặn. Ghi lại chúng bên cạnh chính sách, vì người kế thừa cấu hình sẽ đọc fail-closed như tuyệt đối nếu không.

Kết nối lại và chặn cũng là những điều khiển riêng. Ứng dụng khách có thể tự động kết nối lại mà không bao giờ chặn, hoặc chặn mà không kết nối lại, và sự kết hợp quyết định người dùng trải nghiệm gì trong lúc gián đoạn.

Hãy chứng minh trong lúc chuyển đổi

Kiểm tra trạng thái ổn định không chứng minh được gì. Cố ý ngắt đường hầm và thử ứng dụng lẽ ra phải được bảo vệ, sau đó kiểm tra xem nó có tới được mạng không. So sánh chỉ báo của ứng dụng khách với kết quả, vì chỉ báo vẫn nói đã kết nối chính là trường hợp mà chính sách tồn tại. Nếu ứng dụng được bảo vệ thành công, tên của chế độ không quan trọng; bạn đang có rò rỉ.

Lặp lại từ khởi động nguội trước khi đăng nhập, khi chuyển từ Wi-Fi sang mạng di động và với ứng dụng được bảo vệ ở chế độ nền. Nếu tiến trình của ứng dụng khách thực thi việc chặn, hãy thử cả điều gì xảy ra khi tiến trình đó bị giết thay vì đóng gọn gàng.

Cuối cùng, kiểm tra đường dọn dẹp. Nếu một ứng dụng khách bị gỡ cài đặt khi các quy tắc của nó đang hoạt động, hãy dùng quy trình gỡ bỏ được nhà cung cấp ghi lại thay vì tắt tường lửa của hệ điều hành, vì việc tắt tường lửa gỡ bỏ bảo vệ không liên quan mà không trả lời quy tắc còn lại thuộc về ai.

Bài viết liên quan