Máy chủ DNS sai trong VPN Windows: metric, thứ tự liên kết hay hậu tố

Một máy khách Windows có thể có đường hầm hoạt động, mang theo trình phân giải của công ty và vẫn gửi các tên nội bộ đến router tại nhà. Ba cơ chế khác nhau quyết định máy chủ nào trả lời, và chúng thất bại theo những cách khác nhau. Không cần sửa cả ba: triệu chứng cho biết cơ chế nào đang tham gia. Cây quyết định dưới đây mất vài phút và ngăn kết cục quen thuộc, khi thay đổi metric, sắp xếp lại registry và quy tắc NRPT đến cùng lúc và không ai biết cái nào đã làm gì.

Ba cơ chế quyết định, và thường một cái là sai

Metric của giao diện sắp xếp các bộ điều hợp cho một họ địa chỉ nhất định. Thứ tự liên kết dưới Tcpip\Linkage là danh sách cấp máy các định danh giao diện mà các đường mã cũ vẫn tra cứu. Bảng chính sách phân giải tên (NRPT) ràng buộc một không gian tên với các máy chủ cụ thể, và danh sách hậu tố quyết định liệu tên ngắn có được mở rộng hay không. Chúng độc lập, nên trình phân giải đúng trên bộ điều hợp VPN thua một tùy chọn cũ ở nơi khác.

Không cơ chế nào trong số này là phía bên kia của đường hầm. Nếu máy chủ mà VPN đẩy xuống không phân giải được tên, mọi thiết lập phía máy khách chỉ là trang trí, nên quyết định đầu tiên là liệu bản thân trình phân giải có trả lời được khi hỏi trực tiếp hay không.

Quyết định một: trình phân giải được đẩy xuống có trả lời được không?

Hỏi máy chủ một cách rõ ràng và so sánh với một tra cứu thông thường. Khoảng cách giữa hai câu trả lời tách vấn đề chọn lựa khỏi vấn đề khả năng tiếp cận, và đây là chỗ rẽ nhanh nhất:

Resolve-DnsName intranet.corp.example -Server 10.20.0.10 -Type A
Resolve-DnsName intranet.corp.example -Type A

Nếu cái đầu thành công và cái thứ hai thất bại, trình phân giải truy cập được và Windows chọn sai; hãy đi đến các quyết định về không gian tên và thứ tự bên dưới. Nếu cái đầu cũng thất bại, không gì trên máy khách giúp được: kiểm tra xem UDP và TCP 53 có đến được máy chủ qua đường hầm không, tường lửa của máy chủ có bỏ nhóm địa chỉ không, và các bộ chuyển tiếp của chính máy chủ có khỏe mạnh không.

Dừng ở chỗ rẽ này. Áp dụng quy tắc NRPT cho một trình phân giải không thể tiếp cận tạo ra cùng lỗi với nhiều cấu hình phải hoàn tác hơn, và che lỗi thật phía sau một quy tắc trông có thẩm quyền.

Quyết định hai: một không gian tên hay mọi truy vấn?

Phạm vi quyết định công cụ. Khi chỉ tên công ty thất bại, hãy ràng buộc không gian tên thay vì sắp xếp lại máy: quy tắc NRPT gửi hậu tố đó đến trình phân giải của đường hầm và để yên mọi thứ khác. Khi mọi tra cứu bị ảnh hưởng, vấn đề là tùy chọn bộ điều hợp toàn cục, và metric là nơi nên bắt đầu vì nó không đổi thiết lập máy chủ nào.

Đặt metric cho từng họ địa chỉ, trên cả hai giao diện, rồi xác nhận thứ tự:

Get-NetIPInterface | Select-Object ifIndex, InterfaceAlias, AddressFamily, InterfaceMetric
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 1 -AddressFamily IPv6

Thay 11 bằng ifIndex của bộ điều hợp đường hầm từ dòng trên; nếu 11 là bộ điều hợp LAN, cùng lệnh đó hạ thấp sai đường. Nâng bộ điều hợp LAN thay vào đó đạt cùng thứ tự từ phía bên kia: netsh int ip set interface interface="Ethernet" metric=15, và netsh int ipv6 set interface interface="Ethernet" metric=15 cho họ thứ hai, vì int ip chỉ chạm IPv4.

Thứ tự liên kết là phương án cuối cùng chứ không phải bước đầu. HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage chứa danh sách Bind định danh thiết bị, và việc đưa định danh đường hầm lên trước thực sự thay đổi bộ điều hợp nào được hỏi trước, nhưng đó là giá trị registry cấp máy không có phạm vi theo từng không gian tên. Xuất nó trước khi sửa và sau đó kết nối lại đường hầm, để thứ tự có hiệu lực trong trạng thái mà máy khách mong đợi.

Với một không gian tên duy nhất, hãy chọn công cụ hẹp hơn:

Add-DnsClientNrptRule -Namespace ".corp.example" -NameServers 10.20.0.10
Get-DnsClientNrptRule | Select-Object Namespace, NameServers

Quyết định ba: bản sửa có sống qua lần kết nối lại không?

Một metric chỉ có tác dụng đến lần kết nối quay số tiếp theo thì chưa bao giờ được lưu. L2TP/IPsec và các hồ sơ kết nối khác được tạo lại khi kết nối bắt đầu, nên giá trị đã lưu sống trong mục sổ điện thoại dưới dạng IpInterfaceMetric, không chỉ trên giao diện đang hoạt động. Một số môi trường viết script cho trường đó chính vì lý do này; những nơi khác đẩy tùy chọn từ chính sách quản lý và để yên điểm cuối.

Bộ nhớ đệm và đăng ký là một lớp riêng. Chạy chúng sau khi đường hầm lên sẽ sửa các mục cũ và đăng ký lại máy khách, nhưng không cái nào sắp xếp lại bộ điều hợp:

ipconfig /registerdns
ipconfig /flushdns

Có một công tắc tắt trong cùng lớp đó. Tắt đăng ký động trên bộ điều hợp vật lý ngăn máy khách quảng bá địa chỉ phía VPN của nó dưới tên sai, và đó là cách sửa khác với lần làm mới ở trên.

IPv6 xứng đáng có dòng riêng trong quyết định. Nếu bộ điều hợp vật lý có địa chỉ IPv6 toàn cầu trong khi đường hầm chỉ mang IPv4, Windows có thể ưu tiên đường không qua đường hầm cho việc phân giải tên. Kiểm tra họ đó riêng, vì một metric đặt cho IPv4 không nói gì về nó:

Get-NetIPInterface -AddressFamily IPv6 | Select-Object ifIndex, InterfaceAlias, InterfaceMetric

Tắt IPv6 trên bộ điều hợp LAN loại bỏ đường đó cùng với giao thức; thay đổi metric trên giao diện IPv6, hoặc quy tắc NRPT cho không gian tên công ty, giữ lại họ và sửa tùy chọn. Chọn cái hẹp hơn, trừ khi bạn đã quyết định rằng liên kết đó không nên có IPv6.

Xác minh với nguồn được nêu tên, và giữ một chủ sở hữu

Xác minh bằng các công cụ báo cáo nguồn nào đang có hiệu lực, không chỉ là trang có tải được hay không:

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName fileserver.corp.example -Server 10.20.0.10 -Type A

Sau đó tách việc lọc khỏi việc chọn, vì từ bên trong một ứng dụng chúng trông giống hệt nhau. block-outside-dns của OpenVPN chặn cổng 53 trên các bộ điều hợp khác; nó không chọn trình phân giải. Nếu giờ mọi truy vấn đều thất bại, một bộ lọc có thể đang chặn máy chủ duy nhất tiếp cận được; nếu trình phân giải đã cấu hình bị bỏ qua, thứ tự hoặc quy tắc không gian tên là sai. Thay đổi cả hai cùng lúc khiến một truy vấn bị chặn và một truy vấn bị bỏ qua không thể phân biệt.

Giữ một chủ sở hữu cho chính sách DNS: hồ sơ VPN, một chính sách quản lý hoặc một quy tắc NRPT, không phải hai trong số đó. Trước khi đóng lại:

• Trình phân giải được đẩy xuống trả lời khi được nêu tên rõ ràng, và một tra cứu thông thường dùng nó.
• Quy tắc hoặc metric bạn đã thay đổi bao phủ họ địa chỉ thực sự mang các truy vấn.
• Thiết lập sống qua lần ngắt và kết nối lại, hoặc bạn đã chuyển nó vào hồ sơ đã lưu.
• Đúng một cơ chế có thẩm quyền, và các cơ chế khác được để như cũ.

Coi thứ tự là trạng thái của môi trường chứ không phải việc để hoàn tất. Kiểm tra lại sau khi kết nối lại và sau bản cập nhật Windows chạm vào ngăn xếp mạng, vì bất kỳ điều nào trong hai cũng có thể đưa bộ điều hợp vật lý trở lại phía trước.