Một dòng trong tài liệu yêu cầu — “ứng dụng này được dùng VPN, và không gì khác” — lặng lẽ đòi hai cơ chế mà không một công tắc đơn lẻ nào cung cấp. Lưu lượng cần một đường đi xuyên qua đường hầm dự định, và lưu lượng lẽ ra đi thẳng phải bị từ chối. Những công cụ làm tốt một trong hai mà không làm gì với cái còn lại thì phổ biến, vì thế một so sánh chỉ hỏi liệu có thứ gì chặn được hay không sẽ tự tin trả lời nửa câu hỏi. Hãy viết ranh giới trước, rồi chọn những thành phần bao phủ cả hai nửa của nó.

Hai yêu cầu ẩn trong một câu

Định tuyến là phần đưa một kết nối vào đường hầm hoặc proxy. Từ chối là phần ngăn chính kết nối đó đi ra bằng bất kỳ tuyến nào khác. Các thành phần khác nhau thực hiện chúng, chúng thất bại theo cách khác nhau, và một sản phẩm có thể xuất sắc ở mặt này mà không nói gì về mặt kia:

ApproachSteers trafficRefuses direct egressKnows the app identity
Per-app VPN profileYes, for the apps it namesOnly if a filter or firewall also blocksYes, within its own rules
Application proxy settingPartly, for requests that honour itNoNo
Content filterNoYesYes, if the filter is written that way
Local PF rulesetNoYes, by address and portNot reliably

Hãy đọc bảng như danh sách kiểm tra chứ không phải bảng xếp hạng. Không hàng nào lấp đầy cả hai cột giữa, và những hàng bao phủ chúng là hai thành phần phối hợp: một bên sở hữu đường đi, bên kia sở hữu sự từ chối. Cột nhận diện quan trọng vì lý do khác, bởi một quy tắc không thể gọi tên ứng dụng thì không thể thực thi quy tắc về ứng dụng đó. Bất cứ gì bạn triển khai cũng phải trả lời cả ba, nếu không ranh giới trong tài liệu yêu cầu không phải ranh giới trên máy.

Chỉ định tuyến thì vẫn để lại lối ra

Thiết lập proxy của ứng dụng là ví dụ rõ nhất về định tuyến không có từ chối. Nó có thể định tuyến các yêu cầu từ một ứng dụng tôn trọng proxy hệ thống, và không bao phủ gì khác: một tiến trình phụ, trình cập nhật, dịch vụ nền hay giao thức khác có thể đi theo đường riêng mà không bao giờ đọc thiết lập đó. Vì vậy chọn một điểm cuối SOCKS trong một bảng điều khiển không tạo ra chính sách cấm ra trực tiếp cho ứng dụng. Nếu yêu cầu là về toàn bộ ứng dụng, hãy hỏi quy tắc thực sự nhận diện những thành phần nào.

Hồ sơ VPN theo từng ứng dụng định tuyến tốt hơn proxy, vì nền tảng quyết định ứng dụng nào đi vào đường hầm thay vì mỗi ứng dụng tự quyết định. Tuy vậy nó không từ chối gì: hồ sơ cung cấp một đường đi, và lưu lượng không khớp sẽ đi theo tuyến thông thường. Chính khoảng trống đó là nơi thành phần thứ hai giành được chỗ đứng, và đó là lý do các sản phẩm trông như một công tắc thường là hai.

Chỉ từ chối thì làm hỏng ứng dụng

Tài liệu của Apple về bộ lọc nội dung mô tả một phán quyết cho-phép-hoặc-chặn đối với lưu lượng khi nó đi qua ngăn xếp mạng. Phán quyết đó không phải đường hầm và không phải kết nối proxy, vì nó quyết định liệu thứ gì đó có được tiếp tục hay không, chứ không phải nó đi đâu. Chỉ một bộ lọc thực thi sự từ chối hoàn hảo và để ứng dụng không dùng được, với nhật ký sạch và không lời giải thích. Phán quyết của bộ lọc có thể dừng một kết nối nhưng không bao giờ cung cấp đường hầm, nên ghép nó với định tuyến là quyết định thiết kế chứ không phải phần thêm tùy chọn.

Một bộ quy tắc PF được quản trị cục bộ nằm ở đầu kia của phổ đó. Đó là một quyết định hỗ trợ hợp lý trên một máy do quản trị viên sở hữu, và nó không tự động là nền tảng của một sản phẩm có thể phân phối, vì ai sở hữu bộ quy tắc thì cũng sở hữu các tương tác của nó với người dùng tường lửa khác, đường nâng cấp và việc khôi phục khi một quy tắc sai. Thêm PF vào một sản phẩm không loại bỏ câu hỏi sở hữu đó; nó định nghĩa câu hỏi ấy.

Việc triển khai quyết định quy tắc còn tồn tại vào ngày mai hay không

Cách một Network Extension được triển khai trên các nền tảng Apple phụ thuộc vào loại nhà cung cấp, cách đóng gói và phiên bản hệ điều hành trước mắt bạn. Một tiện ích ứng dụng trên macOS chạy trong ngữ cảnh người dùng và kết thúc khi người dùng đó đăng xuất, trong khi tiện ích hệ thống có ngữ cảnh toàn cục không phụ thuộc phiên. Nếu sự bảo vệ phải sống sót qua đăng xuất, khác biệt đó chính là toàn bộ thiết kế chứ không phải chú thích. Hãy xác nhận đường triển khai trước khi hứa về hành vi, vì cùng một mã sẽ hạ cánh khác nhau tùy loại tiện ích được gửi đi.

Khả năng có mã nguồn là vấn đề tách biệt với việc thực thi. Đọc một kho mã cho bạn biết thứ gì đó được hiện thực thế nào, chứ không phải tệp nhị phân đã cài được phép làm gì trên máy này. Việc ký, cài đặt và cấp quyền vẫn áp dụng, và những hướng dẫn dựng quanh một tiện ích hạt nhân lỗi thời hay một mẹo chèn thư viện mô tả một nền tảng khác và một thế đứng rủi ro khác, dù chúng từng chạy tốt đến đâu.

Một ca chấp nhận có nêu tên ứng dụng

Chọn một hành động mà ứng dụng tự thực hiện, ghi lại địa chỉ mà nó phải đến và địa chỉ đó là IPv4 hay IPv6, rồi lặp lại hành động đó ở trạng thái không đường hầm đã được phê duyệt. Lần chạy thứ hai phải tạo ra sự từ chối đã tuyên bố chứ không phải một lần thử lại trực tiếp lặng lẽ. Đó là nửa mà người ta để không xác định, và là nửa duy nhất chứng minh rằng sự từ chối có tồn tại. Hãy chạy nó trước khi có đường hầm, để khác biệt giữa hai kết quả chỉ có thể đến từ đường hầm bị thiếu.

Sau đó đi qua các chuyển tiếp mà yêu cầu nêu tên: khởi động lại ứng dụng, một tiến trình phụ kích hoạt, đường hầm kết nối lại, máy đổi mạng, và đăng xuất hoặc khởi động lại ở nơi phù hợp. Trang IP công cộng trên trình duyệt không phải phép thử socket của một ứng dụng khác, nên nó không thể thay thế phép thử này. Ở nơi không có triển khai được hỗ trợ nào bao phủ hành vi thực của ứng dụng, một môi trường cô lập được cấp phép với cổng rõ ràng và không có lối ra thay thế là quyết định ngăn chặn có chi phí quản lý riêng, không phải thứ thay cho ô chọn.

Kết thúc bằng việc ghi bốn mục: ứng dụng gồm những thành phần nào, ai sở hữu định tuyến, ai sở hữu sự từ chối, và các trạng thái mà quy tắc vẫn phải giữ. Một kho mã công khai có thể là một tiêu chí chọn lựa, nhưng nó không phải một trong bốn mục đó, và chính các mục ấy quyết định liệu một công cụ có đáp ứng yêu cầu mạng hay không.

Bài viết liên quan