Always On VPN không phải quyền truy cập LAN: danh sách kiểm tra tài nguyên

Always On là vòng đời của một kết nối: hồ sơ kết nối khi hoặc trước khi đăng nhập và tự kết nối lại mà người dùng không phải nhấn gì. Điều đó không có nghĩa là mọi đích riêng, giao thức và người dùng đều được phép. Câu hỏi thực tế là hồ sơ đã triển khai thực sự cung cấp những tài nguyên nào, và câu trả lời đòi hỏi kiểm tra từng tài nguyên, không phải nhìn vào huy hiệu Connected.

Bước 1: Ghi tài nguyên ra trước khi thử

Bắt đầu bằng một bản ghi ngắn cho mỗi ứng dụng, lấy từ môi trường thật: tên, tiền tố đích, dịch vụ và cổng, vai trò đường hầm, nhóm danh tính và đường đi của bộ phân giải.

Name: portal.corp.example
Destination: 10.20.5.0/24
Service: HTTPS 443
Tunnel role: user access after sign-in
Identity: assigned employee group
Resolver: corporate private DNS

Bản ghi buộc phải tách thành bốn câu hỏi. Tuyến đường quyết định địa chỉ đi đâu; chính sách DNS quyết định cách máy khách biết địa chỉ; bộ lọc lưu lượng quyết định lưu lượng đó có được dùng kết nối hay không; tường lửa và quyền của ứng dụng đích quyết định yêu cầu có được chấp nhận hay không. Không điều nào trong bốn điều đó đến từ một đường hầm đã kết nối.

Bước 2: Xác định đường hầm nào phải mang nó

Windows Always On VPN có đường hầm thiết bị và đường hầm người dùng, được cấu hình thành hai hồ sơ riêng với chứng chỉ và phạm vi riêng. Đường hầm thiết bị thường chỉ mang hạ tầng cần thiết trước khi đăng nhập, chẳng hạn quản lý và dịch vụ miền; quyền truy cập ứng dụng rộng cho nhân viên thuộc đường hầm người dùng.

Bộ lọc lưu lượng là tính năng của đường hầm thiết bị, vì vậy ví dụ của Microsoft dùng chúng cho lưu lượng quản lý. Sao chép ví dụ đó vào một hồ sơ tài nguyên chung sẽ cho ra đường hầm vẫn kết nối nhưng mang sai tập hợp. Xác nhận kết nối đang hoạt động bằng Get-VpnConnection và thử nghiệm dưới chính kết nối đó.

Bước 3: Kiểm chứng tuyến đường cho địa chỉ thật

Phân giải tên một lần, rồi kiểm tra tuyến đường: Find-NetRoute -RemoteIPAddress 10.20.5.10 báo giao diện được chọn, bước nhảy tiếp theo và địa chỉ nguồn. Nếu giao diện là card mạng vật lý, tiền tố không nằm trong tập tuyến của đường hầm hoặc máy khách đã loại nó bằng đường hầm chia tách. Hãy so với định nghĩa hồ sơ thay vì thêm một tuyến cục bộ.

Một route add cục bộ có thể làm bài kiểm tra đạt rồi biến mất ở lần làm mới chính sách tiếp theo, nên thay đổi phải nằm trong hồ sơ được quản lý. Kiểm tra tiền tố ở cả hồ sơ người dùng và thiết bị, và kiểm tra thiết lập đường hầm chia tách: đường hầm đầy đủ không cần tuyến theo tiền tố, đường hầm chia tách cần một tuyến cho mỗi tiền tố riêng mà nó mang.

Bước 4: Thử phân giải tên riêng một cách tách biệt

Tên riêng có đường chính sách của riêng chúng. Hồ sơ có thể cung cấp quy tắc NRPT và danh sách tìm kiếm hậu tố DNS, có hiệu lực khi đường hầm đang hoạt động. Đọc bằng Get-DnsClientNrptPolicy xem máy khách thực sự nhận được gì, rồi thử một tên và một địa chỉ trong cùng phiên. Tên hỏng trong khi địa chỉ chạy là do bộ phân giải; cả hai hỏng là do tuyến đường.

Tên cũng có thể phân giải tới một địa chỉ nằm ngoài các tuyến của đường hầm, tạo ra sự lẫn lộn giữa thành công và hết thời gian. So địa chỉ trả về với tiền tố trong bản ghi của bạn; nếu khác nhau, vùng riêng đang trả lời bằng địa chỉ công cộng hoặc thay thế và tuyến khớp được không phải tuyến bạn thiết kế.

Bước 5: Kiểm tra bộ lọc, danh tính và cổng của chính ứng dụng

Bộ lọc lưu lượng giới hạn giao thức và cổng nào được dùng đường hầm thiết bị, và một tập hợp hẹp có thể chặn tài nguyên mà tuyến đường lẽ ra mang được. Hồ sơ gán kết nối cho một nhóm, nhưng tài nguyên có sự cho phép riêng: người dùng kết nối được không đương nhiên được máy chủ tệp chấp nhận.

Thay đổi hồ sơ được quản lý thông qua chủ sở hữu của nó, dù là Intune, một lần triển khai ProfileXML hay một script vận hành, rồi thử lại sau khi kết nối lại bình thường và sau khi khởi động lại: lỗi thường gặp là một tuyến cục bộ cũ hoặc một hồ sơ chỉ được áp dụng một lần. Lưu phiên bản hồ sơ bên cạnh kết quả kiểm tra.