VPN chiếm DNS và làm hỏng tên nội bộ: sửa lại danh sách

Đường hầm dựng lên, intranet tải được, và tên máy in không còn được phân giải. Hoặc ngược lại: tên nội bộ vẫn hoạt động trong khi mọi thứ bên trong mạng doanh nghiệp hết thời gian chờ. Cả hai triệu chứng đến từ cùng một chỗ, một danh sách trình phân giải mà ứng dụng khách VPN đã ghi lại khi kết nối.

Sửa danh sách một cách có chủ đích, rồi xử lý cơ chế push riêng. Các tuyến là chủ đề thứ ba và không phải thứ đang được sửa ở đây.

Danh sách nào ứng dụng thực sự dùng

Windows phân giải qua thiết lập ở cấp giao diện chứ không qua những gì hộp thoại hiển thị, nên hãy bắt đầu bằng danh sách hiệu lực của từng giao diện. Bí danh quan trọng hơn tên hiển thị, vì mọi lệnh bên dưới đều nhắm tới một giao diện. Nhầm bí danh là bản sửa sẽ rơi vào bộ điều hợp sai. Nó sẽ có vẻ hoạt động cho đến lần kết nối lại tiếp theo, khi mục của chính đường hầm quay lại.

Câu hỏi là máy chủ nào lên trước, và chúng đến dưới dạng mục tĩnh hay dưới dạng thuê DHCP. Cả hai sự thật quyết định bản sửa nào bạn có.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Đọc đầu ra cho bộ điều hợp đường hầm và cho bộ điều hợp vật lý, và ghi lại mọi địa chỉ trên từng cái. Mục tĩnh có thể bị xóa bằng chính sách hoặc tập lệnh; mục do DHCP cấp bị ràng buộc với hợp đồng thuê và sẽ quay lại, điều này thay đổi bản sửa bạn nên chọn. Tên trong mạng từ xa do trình phân giải được quảng bá phân giải, tên trên LAN cục bộ do bộ điều hợp vật lý, và truy vấn đi tới danh sách được tra trước.

Xóa các máy chủ bị đẩy vào, hoặc xếp chúng thấp hơn

Xóa các máy chủ bị đẩy vào khi không có gì bên trong đường hầm cần chúng, vì trình phân giải của chính bộ điều hợp vật lý tiếp quản trở lại. Chỉ giữ chúng nếu mạng từ xa có vùng mà chỉ máy chủ của nó trả lời được, và trong trường hợp đó hãy đặt một trình phân giải cục bộ lên trước. Hai lệnh bên dưới bao trùm cả hai lựa chọn, nên hãy chọn cái phù hợp với tình huống thay vì chạy cả hai.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

Chỉ mục 1 được tra trước, nên các địa chỉ bị đẩy vào vẫn dùng được nhưng không còn là câu trả lời mặc định cho mọi truy vấn. Cờ validate=no bỏ qua một phép thử khả năng tiếp cận thường thất bại khi đường hầm còn đang ổn định, nên hãy xác nhận kết quả bằng lệnh show thay vì tin mã thoát.

Nên biết hai giới hạn trước khi dựa vào điều này. Windows sẽ không xóa các máy chủ đến qua DHCP thông qua netsh, và những giá trị đó tồn tại dưới dạng DhcpNameServer bên dưới khóa đăng ký của giao diện, nên sửa đăng ký là biện pháp cuối phải kiểm tra lại sau hợp đồng thuê tiếp theo. Thứ tự liên kết bộ điều hợp cũng không phải cơ chế xếp hạng đáng tin, vì ứng dụng khách VPN có thể chèn mục của chính nó lên đầu danh sách.

Nơi có thể lọc push

Một bản sửa tốt hơn loại bỏ tùy chọn trước khi nó được áp dụng. Ứng dụng khách Community OpenVPN có thể lọc một chỉ thị bị đẩy vào theo tên, điều này để nguyên cấu hình của máy chủ.

pull-filter ignore "dhcp-option DNS "

Khoảng trắng ở cuối thuộc về phép so khớp và bộ lọc nêu tên tùy chọn chứ không phải địa chỉ máy chủ. Nếu hồ sơ cũng chứa chỉ thị block-outside-dns, việc xóa nó thay đổi bảo vệ chống rò rỉ chứ không phải phân giải tên, nên hãy quyết định riêng thay vì gộp hai chỉnh sửa.

Với một tên máy chủ cứng đầu, một dòng trong tệp hosts của Windows ổn định hơn việc sắp xếp lại trình phân giải cho toàn máy. Nó cũng vô hình với người tiếp theo, nên hãy ghi lại ở nơi cấu hình của máy được tài liệu hóa.

Làm cho bản sửa tồn tại qua lần kết nối lại

Phân giải tên phải được kiểm tra hai lần, một lần với máy chủ đã chọn và một lần ở dạng mà ứng dụng dùng. Cặp đó tách vấn đề thứ tự trình phân giải khỏi một máy chủ không trả lời gì cả. Bỏ qua lần kiểm tra đầu tiên sẽ để hai nguyên nhân rối vào nhau.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Kết nối lại đường hầm và lặp lại cả hai lệnh. Những gì bạn sửa bằng tay chỉ tồn tại đến lần kết nối tiếp theo, vì ứng dụng khách dựng lại trạng thái trình phân giải khi nâng bộ điều hợp. Đặt các dòng netsh vào tập lệnh kết nối được hỗ trợ của ứng dụng khách, để tập lệnh đó kết thúc thành công, và thêm một khoảng chờ ngắn trước khi nó chạy. Ứng dụng khách áp dụng DNS sau tập lệnh sẽ ghi đè kết quả dù thế nào.

Nếu tên công cộng phân giải được mà tên nội bộ vẫn thất bại sau bản sửa, danh sách trình phân giải không còn là nghi phạm. Truy vấn có lẽ không tới được máy chủ, điều này chỉ ra định tuyến hoặc một quy tắc tường lửa chứ không phải một thiết lập DNS khác. Ghi lại bí danh giao diện và các địa chỉ bạn đã chốt, vì cả hai khác nhau giữa các máy và không cái nào tự sống sót qua lần dựng lại.