Vì sao WSL mất tên máy chủ công việc khi VPN kết nối?

Windows phân giải máy chủ nội bộ mà không có bất kỳ phàn nàn nào, còn cùng tên đó lại thất bại bên trong WSL ngay tại thời điểm đường hầm hoạt động. Cách sửa thông thường là ghi một trình phân giải công cộng vào bản phân phối, điều này khôi phục duyệt web thông thường và khiến tên máy chủ công việc không thể phân giải được. Điều đó đổi một lỗi này lấy một lỗi khác, và che giấu lớp thực sự bị hỏng. Trước khi thêm hoặc bớt bất kỳ dòng trình phân giải nào, hãy xác định lớp nào trong ba lớp đang thất bại.

Trước hết hãy loại trừ lỗi định tuyến

Hỏi cùng một tên đủ điều kiện hoàn toàn ở cả hai phía, không phải hai tên trông giống nhau. Thành công trong Windows và thất bại trong WSL cho cùng một chuỗi là chữ ký của hai đường phân giải, và ít thứ khác tạo ra mô hình đó sạch đến vậy. Nếu WSL cũng không tới được dịch vụ ở địa chỉ số đã biết của nó, thì cũng có vấn đề định tuyến hoặc lọc. Trong trường hợp đó công việc DNS sẽ không phát hiện ra, và buổi chiều đi vào lớp sai.

Ba triệu chứng bao phủ phần lớn các trường hợp này, và mỗi triệu chứng chỉ về một nơi khác. Đọc dòng phù hợp trước khi mở tệp cấu hình:

Dòng giữa là dòng mọi người đọc sai, vì thay đổi đã làm hỏng nó được thực hiện từ nhiều tuần trước và lúc đó trông có vẻ thành công. Dòng thứ ba là dòng mọi người chẩn đoán sai, vì một cái tên phân giải được có cảm giác như bằng chứng mạng khỏe mạnh. Cả hai dòng đều đưa bạn tới một mục khác bên dưới.

Đường hầm DNS có mức sàn phiên bản

Microsoft ghi lại một chế độ mạng của WSL dẫn các yêu cầu DNS tới trình phân giải của Windows qua một kênh ảo hóa. Trên các bản dựng Windows 11 được hỗ trợ, chế độ này được bật mặc định, vì thế hai máy trên cùng một mạng doanh nghiệp lại hành xử khác nhau. Biến số là số bản dựng, không phải chính sách doanh nghiệp.

Hướng dẫn mạng của WSL mô tả chế độ đó và các phiên bản hỗ trợ nó. Tính năng này quan trọng vì chính sách DNS doanh nghiệp thường sống trong trình phân giải của Windows, và một bản phân phối thừa hưởng đường đi của Windows cũng thừa hưởng chính sách đó. Một bản phân phối hỏi trình phân giải công cộng không có đường nào tới tên riêng, dù cấu hình của nó có gọn gàng đến đâu. Chính cơ chế đó giải thích toàn bộ triệu chứng, và giải thích vì sao cách lách bằng trình phân giải công cộng thất bại.

Đọc bản dựng trước khi sửa bất cứ thứ gì. Một thiết lập sao chép từ bản cài đặt mới hơn không phải bằng chứng rằng bản cũ hơn triển khai nó. Ghi số bản dựng bên cạnh thay đổi, vì khác biệt giữa hai máy gần như luôn là phiên bản chứ không phải chính sách.

Các ghi đè cũ sống lâu hơn vấn đề mà chúng đã giải quyết

Các công thức cũ hơn tắt các tệp trình phân giải được tạo ra, mã hóa cứng máy chủ tên hoặc khóa tệp bằng thuộc tính bất biến. Những thay đổi đó vẫn nằm nguyên chỗ cũ rất lâu sau khi vấn đề kết nối đã gây ra chúng biến mất, và thường chúng là lý do khiến một thiết lập mới hơn có vẻ không làm gì cả. Chúng cũng sống sót qua lần cài lại bản phân phối dưới dạng một hồ sơ shell viết lại tệp ở mỗi lần đăng nhập. Cái cuối cùng khó tìm nhất, vì nó vô hình từ tệp mà mọi người kiểm tra.

Tìm một tệp trình phân giải viết tay, thuộc tính bất biến trên nó và một script khởi động viết lại nó. Kiểm tra cờ bất biến trước khi sửa, vì ghi vào tệp bị khóa thất bại theo cách đọc như vấn đề quyền. Sau đó kiểm tra hồ sơ shell, vì script ở đó khôi phục nội dung cũ trong vài giây sau khi bạn sửa.

Việc xóa một ghi đè có hậu quả, nên hãy ghi lại bạn đã xóa gì và vì sao. Một bản phân phối thực sự cần trình phân giải tĩnh cho mục đích khác sẽ hỏng khi tệp được tạo quay trở lại.

Hai tệp, hai vai trò khác nhau

Hai tệp cấu hình sống ở hai nơi khác nhau và kiểm soát những thứ khác nhau, và nhầm lẫn giữa chúng tạo ra các chỉnh sửa áp dụng vào lớp sai. Tệp phía Windows đặt thuộc tính của máy ảo, còn tệp phía bản phân phối đặt cách bản phân phối đó xây dựng cấu hình trình phân giải của riêng nó. Không cái nào ghi đè cái kia, vì thế cả hai phải khớp nhau.

Với một bản cài đặt hỗ trợ tính năng này, đoạn cấu hình phía Windows rất ngắn. Đó là toàn bộ thay đổi ở phía đó:

[wsl2]
dnsTunneling=true

Đoạn đó thuộc hồ sơ người dùng Windows và áp dụng cho máy ảo chứ không cho một bản phân phối. Đường hầm cũng yêu cầu bản phân phối chưa tắt việc tạo trình phân giải, nên tệp phía bản phân phối phải để yên hành vi đó. Đổi một cái mà không đổi cái kia thì chế độ lặng lẽ không làm gì, và đây là cách phổ biến nhất mà bản sửa này bị báo là hỏng. Kiểm tra cả hai tệp trong cùng một phiên, vì hai chỉnh sửa cách nhau hàng tuần là hai chỉnh sửa không ai có thể quy cho nhau.

Khởi động lại, rồi truy vấn từ cả hai phía

Những thiết lập này được đọc khi môi trường khởi động, nên một shell mới bên trong bản phân phối đang chạy sẽ không nạp lại chúng. Hãy tắt môi trường thay vì khởi động lại shell, và lưu công việc đang chạy trước vì mọi bản phân phối đều dừng theo nó. Chỉ riêng sự thiếu sót đó giải thích phần lớn báo cáo rằng một thay đổi không có tác dụng.

Sau đó hỏi cùng một câu ở cả hai phía. Kết quả cũng cho thấy bản phân phối thực sự kết thúc với trình phân giải nào:

wsl.exe --shutdown
wsl.exe -e sh -c 'cat /etc/resolv.conf'
wsl.exe -e sh -c 'getent hosts files.corp.example'
wsl.exe -e powershell -Command 'Resolve-DnsName files.corp.example'

Lệnh đầu tiên kết thúc môi trường, lệnh thứ hai cho thấy trình phân giải mà bản phân phối đang dùng, và hai lệnh cuối đặt cùng câu hỏi cho mỗi phía. So sánh câu trả lời chứ không phải trạng thái thiết lập. Một truy vấn vẫn thất bại sau khi khởi động lại sạch với cả hai tệp đúng chỉ ra chính sách trình phân giải doanh nghiệp, và cuộc trò chuyện đó có chủ khác.