Đặt DNS trên bộ điều hợp VPN của Windows bằng PowerShell rồi kiểm chứng

Một kết nối VPN trên Windows không lưu máy chủ DNS trong hồ sơ mà bạn chỉnh trong Cài đặt. Khi đường hầm được thiết lập, máy khách thương lượng cấu hình IP với cổng, cổng gửi một danh sách bộ phân giải và Windows áp dụng nó lên bộ điều hợp đường hầm. Bộ điều hợp đó là một giao diện riêng biệt với Wi-Fi hay Ethernet của bạn, và danh sách thuộc về giao diện chứ không thuộc về hồ sơ. Khi đã biết đối tượng nào sở hữu giá trị, ghi đè nó trong PowerShell chỉ là một lệnh; làm cho phần ghi đè sống sót qua lần kết nối lại mới là phần cần một quyết định.

Đối tượng nào sở hữu địa chỉ

RAS tạo bộ điều hợp đường hầm khi kết nối thành công và gỡ bỏ nó khi kết nối rớt. Các máy chủ DNS bạn thấy trong ipconfig /all xuất hiện trong lần trao đổi cấu hình đó, bên cạnh địa chỉ IPv4, IPv6 và các tuyến. Vì giá trị gắn với giao diện, Set-DnsClientServerAddress ghi vào thứ chỉ tồn tại chừng nào kết nối còn tồn tại.

Chỉ một sự thật đó giải thích phần lớn sự nhầm lẫn quanh DNS của VPN. Có thể xem hồ sơ khi đang ngắt kết nối, nhưng không có giao diện nào để chỉ vào, nên một tập lệnh đăng nhập gọi lệnh cmdlet nhắm vào bí danh VPN sẽ thất bại trước khi ai đó kết nối. Nó cũng giải thích một thay đổi có vẻ bị hoàn tác: không có gì bị hoàn tác, giao diện bị phá hủy và dựng lại với các giá trị cổng đã đẩy xuống.

Tìm bí danh trước khi chạm vào DNS

Tên hồ sơ và bí danh giao diện thường là cùng một chuỗi, nhưng chúng không phải cùng một đối tượng. Get-VpnConnection liệt kê hồ sơ; Get-NetAdapter liệt kê những giao diện mà Windows thực sự có. Các cmdlet DNS cần cái thứ hai, và hai thứ này lệch nhau thường xuyên hơn người ta tưởng, nhất là khi máy khách thêm một mô tả như "(RAS)" vào tên bộ điều hợp.

Nếu hồ sơ chưa tồn tại, PowerShell có thể tạo một mục gốc. Loại đường hầm và phương thức xác thực phải khớp với những gì cổng cung cấp, vì sự không khớp lộ ra lúc kết nối chứ không phải lúc tạo:

Add-VpnConnection -Name "Corporate" -ServerAddress vpn.example.net `
  -TunnelType Ikev2 -EncryptionLevel Required `
  -AuthenticationMethod Eap -AllUserConnection

Kết nối một lần, rồi đọc bí danh thật trước khi viết bất kỳ lệnh DNS nào:

rasdial.exe "Corporate"
Get-NetAdapter | Where-Object InterfaceDescription -like "*VPN*"
Get-DnsClientServerAddress -InterfaceAlias "Corporate"

Áp dụng phần ghi đè theo đúng thứ tự

Thứ tự quan trọng hơn cú pháp. Bộ điều hợp phải được bật, bí danh phải phân giải được và tài khoản phải được phép thay đổi thiết đặt giao diện. Kết nối theo từng người dùng thường chấp nhận thay đổi từ người dùng đã đăng nhập; kết nối cho mọi người dùng tạo bằng -AllUserConnection thường cần một shell có quyền cao.

Bản thân cmdlet là một dòng, được ghi trong tài liệu tham chiếu Set-DnsClientServerAddress của Microsoft:

Set-DnsClientServerAddress -InterfaceAlias "Corporate" -ServerAddresses 10.20.0.53,10.20.0.54
Get-DnsClientServerAddress -InterfaceAlias "Corporate" -AddressFamily IPv4

Hai kiểu hỏng đáng nhận ra ngay từ cái nhìn đầu. Một bí danh sai tạo ra lỗi từ cmdlet, và đó là kết quả tốt, vì im lặng sẽ tệ hơn. Một cmdlet đúng mà không có hiệu ứng thấy được thường có nghĩa là bạn đang nhìn nhầm bộ điều hợp: một bộ điều hợp đường hầm còn sót lại từ máy khách khác, một card mạng vật lý có mô tả tương tự, hoặc một bộ điều hợp ảo thứ hai do công cụ mạng chạy trong môi trường cách ly tạo ra.

Vì sao lần kết nối lại có thể hủy thay đổi

Phần ghi đè thuộc về một thực thể giao diện duy nhất. Khi máy khách tháo bộ điều hợp và dựng lại ở lần kết nối sau, các giá trị được đẩy xuống lại được áp dụng và danh sách của bạn biến mất. Một số máy khách tạo lại giao diện ở mỗi lần kết nối; số khác dùng lại nó suốt phiên. So sánh chỉ mục giao diện trong Get-NetAdapter giữa hai lần kết nối và bạn sẽ biết mình thuộc kiểu hành vi nào.

Có ba câu trả lời bền vững, và chồng chúng lên nhau lại sinh ra lỗi riêng. Một hậu tố DNS dành riêng cho kết nối cộng với một quy tắc NRPT chỉ gửi không gian tên nội bộ tới bộ phân giải nội bộ và để yên các tên công cộng. Một thiết đặt Chính sách nhóm hoặc MDM áp lên kết nối VPN đặt DNS ngay lúc kết nối mà không cần tập lệnh nào. Một tác vụ theo lịch phản ứng với sự kiện kết nối và chạy lại cmdlet là lựa chọn thô, nhưng nó chạy được và để lại nhật ký. Hãy chọn một chủ sở hữu duy nhất cho DNS và ghi lại đó là cái nào.

Các tên nội bộ một nhãn cũng cần danh sách tìm kiếm hậu tố. Set-DnsClientGlobalSetting -SuffixSearchList áp dụng cho toàn máy, nên nó thay đổi việc phân giải cho mọi bộ điều hợp trên máy, kể cả Ethernet. Hãy thử nó trên máy thí nghiệm trước khi đưa vào một ảnh hệ thống.

Kiểm chứng việc phân giải, không chỉ thiết đặt

Một bộ phân giải được liệt kê trên bộ điều hợp chỉ chứng minh rằng một giá trị đã được ghi. Hãy hỏi thẳng máy chủ dự định, rồi hỏi qua đường đi bình thường:

Resolve-DnsName server01.corp.example -Server 10.20.0.53
Resolve-DnsName server01.corp.example

Sự tách biệt cho bạn biết lỗi nằm ở đâu. Truy vấn trực tiếp trả lời còn truy vấn thường thất bại: thiết đặt của bộ điều hợp hoặc danh sách hậu tố chưa có hiệu lực. Cả hai đều thất bại: không thể tới bộ phân giải qua đường hầm, nên hãy xem tuyến và quy tắc tường lửa trước khi động vào DNS lần nữa. Truy vấn trực tiếp thất bại trong khi truy vấn thường trả lời từ nơi khác: DNS chia tách bị cấu hình sai và một tên nội bộ đang được bộ phân giải công cộng trả lời, đó là vấn đề chính sách trước khi là vấn đề kết nối.

Chạy thử hai lần, một lần ngay sau khi kết nối và một lần sau khi ngắt rồi kết nối lại, và so sánh đầu ra của Get-DnsClientServerAddress trong cả hai lần. Nếu giá trị được đẩy xuống quay lại ở lần kết nối thứ hai, phần ghi đè đã sống và chết cùng bộ điều hợp, và chỉ có quy tắc NRPT hoặc tuyến chính sách ở phần trước mới trụ được. Hãy lưu cả hai bản ghi và dấu thời gian kết nối; chúng giải quyết câu hỏi có giữ được hay không nhanh hơn một vòng chỉnh sửa nữa.