Cách các quy tắc miền của Apple VPN On Demand kích hoạt một đường hầm

Đường hầm mở ra khi bạn yêu cầu một tên nội bộ và vẫn đóng khi ứng dụng tiếp theo cần nó gay gắt như vậy. Đó không phải lỗi trong ứng dụng; đó là hình dạng của một quy tắc miền. Cấu hình on-demand của Apple mô tả các điều kiện để thiết lập kết nối, và dạng miền của những điều kiện đó hỏi trình phân giải của hệ thống một câu hỏi trước khi một gói tin duy nhất di chuyển. Hai câu hỏi thường bị nhầm lẫn: khi nào đường hầm nên dựng lên và đường hầm mang gì khi nó tồn tại. Câu thứ nhất là trình kích hoạt, câu thứ hai là chính sách tuyến và trình phân giải, và một cấu hình thường đặt cả hai trong cùng một payload, nên một quy tắc miền đúng vẫn có thể để bạn ở mạng sai.

Trình kích hoạt và việc chọn lưu lượng nằm ở các lớp khác nhau

Một quy tắc on-demand sống trong từ điển on-demand của payload VPN: danh sách quy tắc có thứ tự, mỗi quy tắc có một hành động và một tập điều kiện khớp. Hệ thống đánh giá chúng khi kết nối thay đổi hoặc khi có gì đó cố gắng chạm tới mạng, và hành động quyết định đường hầm được dựng lên, đánh giá, ngắt kết nối hay bỏ qua. Tất cả điều này diễn ra trong lớp mạng của nền tảng, trước khi ứng dụng của bạn có socket.

Phần tiếp theo là một nhóm khóa riêng: cài đặt IPv4 và IPv6 của đường hầm, các tuyến được bao gồm và loại trừ, địa chỉ máy chủ DNS, và trên iOS và iPadOS ánh xạ theo từng ứng dụng quyết định ứng dụng nào được dùng đường hầm. Một cấu hình có thể ghép một trình kích hoạt rộng với một tuyến hẹp, hoặc một trình kích hoạt hẹp với tuyến mặc định. Chỉ đọc một nửa và nửa còn lại sẽ trông như trục trặc.

Tôi có một cấu hình phòng thí nghiệm kết nối mỗi khi có gì đó dưới một miền nội bộ được yêu cầu nhưng chỉ định tuyến một /16 vào đường hầm. Nó làm đúng những gì payload nói, và đây cũng là kiểu cấu hình tạo ra phiếu hỗ trợ: người ta cho rằng đường hầm đã kết nối nghĩa là lưu lượng của họ ở bên trong.

Một quy tắc miền thực sự hỏi trình phân giải điều gì

Dạng miền của quy tắc, thường được gọi là connect-if-needed, không kiểm tra payload gói tin và không theo dõi URL. Khi một tên được phân giải, hệ thống so sánh nó với các miền trong quy tắc và, nếu khớp, hỏi liệu tên đó có thể được phân giải qua các máy chủ DNS mà đường hầm cung cấp hay không. Nếu trình phân giải của đường hầm trả lời, tên được coi là nội bộ và kết nối bắt đầu. Nếu trình phân giải cục bộ trả lời thay vào đó, tên được coi là bên ngoài và không có đường hầm nào xuất hiện. Tổng quan triển khai của Apple mô tả điều này là phát hiện mạng theo sau là đánh giá kết nối.

Hai hệ quả theo sau. Cấu hình phải nêu tên các máy chủ DNS bên trong đường hầm; một quy tắc miền không có trình phân giải đường hầm thì không có gì để so sánh, nên việc đánh giá không thể tạo ra kết quả khớp mà bạn mong đợi. Và truy vấn phải tới được trình phân giải của hệ thống. Một ứng dụng hoặc trình duyệt chạy DNS mã hóa riêng, một tiện ích trả lời cục bộ, hoặc kết nối tới địa chỉ nguyên văn không bao giờ tạo ra phân giải tên mà quy tắc đang chờ. Một trong những buổi chiều dài nhất tôi từng trải qua kết thúc khi tôi phát hiện máy khách trước đường hầm đang dùng DNS over HTTPS.

Bộ nhớ đệm cũng loại bỏ trình kích hoạt. Một tên đã có trong bộ nhớ đệm có thể được trả lời mà không cần phép dò vốn sẽ khởi động đường hầm, nên một quy tắc hoạt động hôm qua sẽ thất bại sau khi khởi động lại, hoặc sau khi đường hầm đã dựng lên một lúc. Trên macOS, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder đặt lại trạng thái; trên iOS, bật tắt chế độ máy bay hoặc khởi động lại thiết bị cho bạn một khởi đầu sạch tương đương.

Phạm vi khớp: tên, ứng dụng và mạng

Khớp miền là một kiểu trong số nhiều kiểu. Một quy tắc cũng có thể khớp với loại giao diện (Wi-Fi, di động, Ethernet) và một SSID cụ thể, và các mục theo ứng dụng hoặc miền Safari ràng buộc một đường hầm với một luồng công việc. Ràng buộc đó giải thích trải nghiệm kỳ lạ khi chỉ một ứng dụng hành xử khác mọi thứ còn lại: các ứng dụng khác nằm ngoài phạm vi của đường hầm, nên chúng tiếp tục dùng đường cục bộ ngay cả khi biểu tượng đường hầm báo đã kết nối.

Thứ tự quan trọng hơn người ta tưởng. Các quy tắc được đánh giá tuần tự và quy tắc khớp đầu tiên cung cấp hành động, nên một quy tắc rộng kết-nối-mọi-Wi-Fi đặt trên một quy tắc miền hẹp sẽ thắng một cách âm thầm và khiến quy tắc miền không thể kiểm tra. Trước khi viết lại danh sách miền, hãy xác nhận rằng không có quy tắc nào trước đó đã khớp.

Đó là lý do always-on không chỉ là một quy tắc on-demand chặt chẽ hơn. Việc thực thi always-on là một chế độ triển khai riêng với các yêu cầu giám sát và quản lý riêng; nó giữ đường hầm mở thay vì phản ứng với một tên. Nếu điều bạn cần là một đường hầm không bao giờ sập, quy tắc miền là công cụ sai.

Các kiểu hỏng bắt chước một quy tắc bị hỏng

Hầu hết các báo cáo rằng quy tắc miền không hoạt động rơi vào một trong năm chỗ, và chỉ chỗ cuối cùng là văn bản của quy tắc.

Cổng captive đáng có dòng riêng, vì Wi-Fi khách sạn và sân bay chặn đúng truy vấn mà quy tắc phụ thuộc vào. Cho tới khi cổng cho thiết bị vào, máy chủ DNS của đường hầm không thể tiếp cận, phép dò thất bại, và lỗi trông như một miền viết sai chính tả. Xác thực là trường hợp im lặng khác: quy tắc có thể kích hoạt, đường hầm có thể bắt đầu kết nối, và kết nối chết trên chứng chỉ hết hạn hoặc trên lời nhắc xuất hiện ở màn hình khác.

IPv6 tạo ra một biến thể dễ chẩn đoán sai. Một tên có cả hai họ địa chỉ có thể được trả lời trước từ bản ghi AAAA, trong khi danh sách tuyến của đường hầm chỉ mang IPv4. Một trình duyệt thành công, trình duyệt khác thất bại, và danh sách miền hoàn toàn vô can.

Hãy thử bằng một yêu cầu thật, theo thứ tự này

Đọc chính sách trước khi đoán. Trên macOS, sudo profiles show -type configuration in ra các cấu hình đã cài đặt bao gồm payload VPN, scutil --nc list hiển thị trạng thái dịch vụ, và scutil --nc show <service> in ra từ điển on-demand mà hệ thống dùng. Trên iPhone hoặc iPad được quản lý, cùng payload đó đến từ bảng điều khiển quản lý hoặc báo cáo MDM. Nhật ký mạng có sẵn với log stream --predicate 'subsystem == "com.apple.networkextension"' trên macOS, và qua bảng điều khiển thiết bị khi điện thoại được kết nối.

Sau đó thử với một tên máy chủ chưa được truy vấn trước đó trong phiên. Chọn một tên trong vùng DNS của đường hầm mà bạn biết là phân giải nội bộ, yêu cầu nó một lần, và xem đường hầm có xuất hiện không. Chạy cùng truy vấn đó hai lần: lần thử thứ hai thực hành đường bộ nhớ đệm, và sự khác biệt giữa hai lần cho bạn biết trình kích hoạt là phân giải hay định tuyến.

Khi đường hầm đã dựng lên, hãy xác minh hai lớp riêng biệt. netstat -rn -f inet và netstat -rn -f inet6 cho biết mỗi tiền tố trỏ tới đâu, scutil --dns cho biết thứ tự trình phân giải và giao diện nào sở hữu từng trình phân giải, và nettop -m route cho biết giao diện nào đã mang các byte. Nếu đường hầm đã dựng lên và trình phân giải đúng nhưng tài nguyên vẫn lỗi, hãy ngừng sửa quy tắc; kiểm tra ủy quyền phía máy chủ và tuyến quay về.

Khi quy tắc thuộc về người khác

Nếu đường hầm xuất hiện lại sau khi bạn ngắt kết nối, quy tắc thường thuộc về một cấu hình chứ không phải một ứng dụng: cấu hình được đẩy qua MDM, một cấu hình cá nhân còn sót lại, hoặc cấu hình do một máy khách khác cài đặt. sudo profiles show -type configuration cùng với tìm kiếm các khóa on-demand sẽ thu hẹp nó, và đường gỡ bỏ là cấu hình, không phải công tắc trên thanh menu. Xóa mục dịch vụ hoặc ứng dụng để lại quy tắc, và lần cài đặt tiếp theo lại thừa hưởng nó.

Một phép thử giải quyết quyền sở hữu: ngắt kết nối, chờ, yêu cầu lại tên nội bộ. Nếu đường hầm quay lại, trình kích hoạt đang hoạt động như thiết kế và câu hỏi mở là ai quản lý nó và liệu phạm vi đó có phải điều bạn muốn.

Trước khi báo cáo điều này như một lỗi, hãy đi qua đúng năm kiểm tra: địa chỉ trình phân giải của đường hầm có trong payload, một tên chưa được lưu đệm, không có quy tắc trước đó đã khớp, một đường AAAA được danh sách tuyến bao phủ, và ứng dụng nằm trong phạm vi đường hầm. Khi cả năm đúng, quy tắc đang làm việc của nó và lỗi nằm xa hơn trên đường đi.