Đường hầm chia tách của bạn đến được ứng dụng nhưng không đến máy chủ DNS của nó
Một đường hầm chia tách có thể định tuyến subnet của ứng dụng mà vẫn bỏ rơi bộ phân giải bên cạnh. Thêm tuyến máy chủ, rồi kiểm tra máy chủ nào Windows thực sự chọn.
Định tuyến subnet của ứng dụng là phần hiển nhiên của đường hầm chia tách, và đó không phải toàn bộ công việc. Bộ phân giải thường nằm ở địa chỉ khác với ứng dụng mà nó phục vụ, nên một đường hầm hoạt động vẫn có thể để truy vấn ở bên ngoài. Một hồ sơ chỉ mang 10.80.0.0/16 và không gì khác sẽ gửi truy vấn cho 10.90.0.53 qua giao diện cục bộ, nơi không có vùng riêng nào. Thêm tuyến đến bộ phân giải, rồi xem nửa còn lại của vấn đề: máy chủ nào mà máy khách thực sự chọn.
Huyền thoại: một tuyến bao phủ toàn bộ dịch vụ
Đường hầm chia tách là danh sách các đích đi qua kết nối, không phải mô tả của một dịch vụ. Subnet của ứng dụng và địa chỉ bộ phân giải là hai đích, và một hồ sơ có thể mang cái này mà không có cái kia. Khi điều đó xảy ra, ứng dụng truy cập được bằng địa chỉ nhưng tên của nó thất bại, trông giống lỗi DNS hơn là lỗ hổng định tuyến.
Subnet xung quanh bộ phân giải cũng không được che tự động. Một tuyến máy chủ đến một địa chỉ là đủ cho bộ phân giải đó và không mở các hàng xóm của nó. Đó chính là ý nghĩa của tuyến máy chủ: hẹp theo thiết kế, và dễ quên khi dịch vụ tiếp theo xuất hiện trên cùng subnet.
Ba điều phải đúng để truy vấn hoạt động: máy khách định tuyến địa chỉ bộ phân giải qua đường hầm, cổng nhận và chuyển tiếp yêu cầu đó, và bộ phân giải chấp nhận nguồn mà nó nhận được. Câu trả lời cũng phải quay về theo đường đã thỏa thuận. Thiếu một điều trong số đó thì triệu chứng giống hệt nhau, vì vậy nên viết bảng địa chỉ trước khi chạm vào cấu hình.
Xác định hồ sơ phải mang những địa chỉ nào
Liệt kê các đích theo thứ tự: mạng của ứng dụng, địa chỉ bộ phân giải và điểm cuối công khai kết thúc chính đường hầm. Cái thứ ba không bao giờ được định tuyến vào đường hầm, vì kết nối bên ngoài cần một đường tồn tại trước đường hầm.
| Destination | Coverage this example needs |
|---|---|
| Application network | 10.80.0.0/16 through the VPN |
| Private resolver | 10.90.0.53/32 through the VPN |
| Public VPN endpoint | Normal internet path, outside the tunnel |
Bao gồm cả UDP và TCP cho DNS, vì các triển khai được kỳ vọng hỗ trợ TCP bên cạnh UDP, và đường TCP bị chặn tạo ra lỗi chậm, từng phần thay vì sạch sẽ. Nếu vùng riêng cũng được phục vụ qua IPv6, ngoại lệ máy chủ tương đương dùng địa chỉ và tiền tố IPv6 và là một mục riêng.
Ghi lại những gì hồ sơ đã bao phủ trước khi thêm bất cứ thứ gì. Tuyến trùng lặp là vô hại, nhưng một tuyến hiện có bất ngờ cho bạn biết hồ sơ được thiết kế cho một kế hoạch địa chỉ khác với cái bạn được giao.
Thêm tuyến máy chủ thông qua chủ sở hữu kết nối
Với hồ sơ Windows gốc được quản lý cục bộ, tuyến thuộc về kết nối chứ không phải bảng định tuyến toàn cục của máy. Xem trước việc thêm trước, rồi áp dụng nó với cùng phạm vi mà hồ sơ sử dụng.
Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes
Lệnh thứ nhất xem trước thay đổi mà không cài đặt gì, và lệnh thứ hai liệt kê các tuyến mà hồ sơ đang mang. Tài liệu tham chiếu Add-VpnConnectionRoute của Microsoft ghi lại các phạm vi theo từng người dùng và cho tất cả người dùng; hồ sơ cho tất cả người dùng cần tham số phạm vi riêng, và lệnh theo từng người dùng đối với hồ sơ cho tất cả người dùng sẽ thất bại hoặc rơi vào sai chỗ.
Khi hồ sơ được quản lý hoặc đến từ ứng dụng khách của nhà cung cấp, thay đổi thuộc về chủ sở hữu đó. Chồng một tuyến hệ thống vĩnh viễn lên chính sách kết nối chỉ hoạt động cho đến khi chính sách được áp dụng lại và tuyến biến mất, điều thường xảy ra trong một cuộc gọi hỗ trợ chứ không phải khi kiểm thử. Lỗi đó im lặng: tuyến biến mất, tên ngừng phân giải và không ai liên hệ hai sự kiện. Đặt thay đổi vào bản ghi riêng của chủ sở hữu để lần áp dụng lại tiếp theo mang nó đi thay vì xóa nó.
Sau khi áp dụng, hãy kết nối lại hồ sơ thay vì giả định tuyến đã có hiệu lực. Các thay đổi tuyến trên kết nối đang hoạt động không phải lúc nào cũng được tiếp nhận, và việc kết nối lại cũng tái tạo trạng thái mà người dùng của bạn thực sự sẽ gặp.
Kiểm tra bộ phân giải nào mà máy khách thực sự đã dùng
Một tuyến kiểm soát các gói được gửi đến bộ phân giải. Nó không quyết định tên nào sẽ được gửi đến đó, và việc chọn lựa đó là một cơ chế riêng. Trên Windows, các quy tắc không gian tên có hiệu lực có thể chọn bộ phân giải theo từng miền, trong khi cài đặt DNS của hồ sơ cung cấp giá trị mặc định. Hai lớp đó có thể không khớp nhau mà không tạo ra lỗi nào, vì vậy một truy vấn trực tiếp chỉ là một nửa bằng chứng.
Get-DnsClientNrptPolicy Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A
Lệnh thứ nhất in chính sách không gian tên đang có hiệu lực, và lệnh thứ hai hỏi trực tiếp bộ phân giải riêng về tên của ứng dụng. Câu trả lời trực tiếp chứng minh đường đi và bộ phân giải hoạt động; nó không chứng minh rằng truy vấn của chính ứng dụng đã chọn máy chủ đó. So sánh nó với một truy vấn bình thường của cùng tên và với câu trả lời mà ứng dụng nhận được.
Hãy tính đến bộ nhớ đệm và DNS an toàn ở cấp trình duyệt, thứ có thể bỏ qua hoàn toàn bộ phân giải của hệ thống đối với những tên người dùng đã gõ. Hậu tố tìm kiếm là một manh mối gây nhầm lẫn khác: nó mở rộng một tên ngắn thành tên đủ điều kiện và không liên quan gì đến việc máy chủ nào trả lời.
Kết thúc bằng việc kết nối lại và lặp lại truy vấn bình thường, rồi xác nhận rằng duyệt web thông thường vẫn tuân theo chính sách đã được phê duyệt. Thay bộ phân giải riêng bằng một bộ công khai để một cái tên không liên quan phân giải được không phải là sửa chữa, và nó lặng lẽ chuyển các truy vấn riêng tư đến nơi chúng không bao giờ nên đến.