Mac của bạn có thể cài đặt đồng thời một đường hầm VPN, một bộ lọc nội dung và iCloud Private Relay, và không cái nào cho biết cái nào đang định hình một kết nối cụ thể. Các bảng cài đặt trông giống nhau, các biểu tượng trông giống nhau, và gần như nhà cung cấp nào cũng gọi sản phẩm của mình là bảo mật mạng. Ba sự thật phân biệt chúng: liệu lưu lượng có đi ra qua một điểm cuối từ xa mà bạn có thể gọi tên, liệu một động cơ chính sách có đưa ra quyết định cho phép-hoặc-bỏ đối với từng luồng, và liệu sự bảo vệ có dừng ở Safari. Làm rõ ba điều này thì phần lớn câu hỏi VPN-của-tôi-có-bật-không tự trả lời.

Ba điều kiện nhận diện thành phần

Điều kiện thứ nhất là đường ra. Nhà cung cấp đường hầm chuyển gói tin tới một cổng từ xa, nên địa chỉ công cộng của bạn thay đổi và, nếu hồ sơ nói vậy, các máy chủ sau cổng đó trở nên truy cập được. Nếu địa chỉ không bao giờ đổi và không có mạng con riêng nào mở ra, bạn không nhìn vào một đường hầm đang hoạt động, bất kể thanh menu nói gì.

Điều kiện thứ hai là quyết định. Bộ lọc nội dung đánh giá các luồng và trả về cho phép hoặc bỏ. Nó có thể áp đặt chặn theo danh mục, quy tắc theo ứng dụng hoặc chính sách do người sử dụng lao động đẩy xuống, và nó có thể ghi lại phán quyết. Điều nó không thể tự làm là cho lưu lượng một nơi để đi.

Điều kiện thứ ba là phạm vi. Private Relay bảo vệ một lát cắt xác định của việc duyệt web chứ không phải toàn bộ thiết bị, và việc của nó là tách bạn là ai khỏi bạn truy cập gì, không phải đặt bạn vào một mạng khác.

Đặt ba thứ cạnh nhau và ranh giới khó bỏ sót:

LayerQuestion it answersEvidence to look forWhat it does not do
VPN tunnel providerWhere does my traffic emerge, and which private networks can I reach?Changed public address, a connected service, a default route through a utun interfaceEnforce per-app content policy
Content filterMay this flow proceed, and who decided?A filter extension in Network Extensions, drop verdicts, an MDM profileSupply a different public exit
iCloud Private RelayCan the local network see which sites Safari loads?A relay egress address in Safari only, the relay toggle in iCloud settingsCover other apps or grant access to a private subnet

Bộ lọc nội dung là động cơ chính sách, không phải đường ra

Trên macOS, bộ lọc đến dưới dạng Network Extension xây trên lớp nhà cung cấp dữ liệu lọc của Apple, NEFilterDataProvider. Trong triển khai được quản lý, MDM đẩy nó xuống, nó được cài như tiện ích hệ thống và được chấp thuận một lần trong System Settings > General > Login Items and Extensions. Từ đó nó thấy các luồng TCP, và trong một số cấu hình cả UDP, rồi trả về phán quyết cho từng luồng.

Cách nó hỏng mới là điều khiến người ta bối rối. Một bộ lọc bỏ luồng tạo ra hết thời gian chờ, bắt tay TLS bị treo hoặc đặt lại, trông đúng như một đường hầm đã lên nhưng không chuyển được lưu lượng. Địa chỉ công cộng không hề đổi, vì không có đường ra nào để đổi nó.

Các ứng dụng thương mại thường gộp cả hai vai. Một bộ cài đặt mang theo nhà cung cấp đường hầm và bộ lọc, bộ lọc chặn và đường hầm định tuyến. Vì vậy tên ứng dụng không cho bạn biết thành phần nào đã từ chối kết nối. Kiểm tra danh sách tiện ích, rồi dịch vụ đã kết nối, rồi nhật ký ứng dụng, theo đúng thứ tự đó.

Private Relay phủ Safari, không phủ cả máy

Private Relay gửi việc duyệt web mà nó phủ qua hai rơ-le do các bên riêng biệt vận hành, nên không nhà vận hành đơn lẻ nào giữ cả danh tính và đích đến của bạn. Đây là thiết kế riêng tư, không phải đường hầm: không có cổng để đi vào, không có mạng con riêng, và không có cách ghim địa chỉ ra ở quốc gia bạn chọn.

Phạm vi của nó cố ý hẹp: nó phủ việc duyệt web trong Safari cùng các truy vấn DNS và lượt tải HTTP không bảo mật đi kèm. Một phiên terminal, ứng dụng thư, ứng dụng trò chuyện và trình khởi chạy trò chơi nằm ngoài. Nếu kiểm tra trong Terminal vẫn cho thấy địa chỉ mạng truy cập của bạn trong khi Safari hiển thị địa chỉ rơ-le, đó là kết quả mong đợi, không phải bản cài hỏng.

Tính khả dụng có điều kiện. Nó cần gói iCloud+, không được cung cấp ở mọi khu vực, và mạng được quản lý có thể chặn truy cập rơ-le, khi đó Safari quay về kết nối trực tiếp. Tổng quan về Private Relay của Apple là tài liệu tham chiếu cho phạm vi hiện tại. Khi hồ sơ VPN đã kết nối và mang lưu lượng đó, rơ-le không được xếp chồng lên trên; hồ sơ quyết định đường đi.

Đọc bằng chứng theo đúng thứ tự

Bắt đầu với trạng thái dịch vụ, vì đó là tín hiệu rẻ nhất. scutil --nc list in ra các dịch vụ VPN đã cấu hình và mỗi dịch vụ có kết nối hay không. Một hồ sơ có thể nằm đó nhiều năm mà không bao giờ kết nối, và người ta thường tính nó là đường hầm.

Rồi xem giao diện và tuyến đường. ifconfig hiển thị giao diện utun, nhưng chỉ riêng sự hiện diện của chúng chứng minh rất ít, vì macOS dùng utun cho nhiều mục đích ngoài VPN. Điều quan trọng là tuyến mặc định có đi vào một trong số chúng hay không, điều mà route -n get default báo cáo.

Với phân giải tên, scutil --dns liệt kê các bộ phân giải mà hệ thống thực sự dùng, và ở đó xuất hiện nhà cung cấp proxy DNS. So sánh dig +short example.com với dig +short example.com @1.1.1.1 tách bộ phân giải đang trả lời khỏi bộ phân giải đang bị chặn giữa.

Hoạt động của tiện ích đi vào nhật ký hợp nhất: log show --predicate 'subsystem == "com.apple.networkextension"' --last 5m. Bạn đang tìm tiện ích nào khởi động và liệu một bộ lọc có báo phán quyết trên luồng bạn quan tâm hay không, chứ không phải một dòng để học thuộc.

Thu hẹp triệu chứng trước khi tắt bất cứ thứ gì

Phân loại lỗi trước. Một tên không phân giải được, một kết nối bị từ chối ngay, và một kết nối treo tới hết thời gian chờ là ba quan sát khác nhau với ba bên chịu trách nhiệm khác nhau. Phân giải chỉ về bộ phân giải hoặc proxy DNS. Từ chối ngay chỉ về một quy tắc của bộ lọc. Im lặng thường chỉ về định tuyến, hoặc về một đường hầm đã lên nhưng không chuyển tiếp.

Trên một Mac được quản lý, hãy giả định bộ lọc thuộc về tổ chức. Tắt nó để thử VPN là gỡ đúng thành phần bạn muốn quan sát, và MDM thường khôi phục nó ở lần kiểm tra sau. Hỏi quản trị viên tên chính sách trước khi thay đổi bất cứ gì, và thử với đúng ứng dụng đã hỏng thay vì cả hệ thống.

Một cái bẫy nữa: tắt Private Relay để thử VPN không nói gì về lưu lượng nước ngoài, vì rơ-le chưa bao giờ phủ lưu lượng đó. Mỗi lớp phải được thử trong ứng dụng mà nó thực sự chi phối.

Đi qua danh sách này và dừng ở mục đầu tiên thất bại:

  • scutil --nc list có hiển thị dịch vụ bạn mong đợi là đã kết nối không?
  • Địa chỉ công cộng thấy từ Terminal có khác địa chỉ mà mạng truy cập của bạn cấp không?
  • Có tiện ích lọc nào được cài và nó có ghi phán quyết cho luồng đang hỏng không?
  • Lỗi chỉ xảy ra trong Safari? Nếu vậy, hãy kiểm tra phạm vi rơ-le trước khi đổ lỗi cho đường hầm.

Nếu cả bốn đều qua mà ứng dụng vẫn hỏng, vấn đề nằm trên lớp mạng: cài đặt proxy, tin cậy chứng chỉ, hoặc danh sách cho phép ở cấp ứng dụng.

Bài viết liên quan