WSL2 mất DNS sau khi kết nối VPN? Hai nguyên nhân
Một tệp resolver cũ và một số liệu tuyến đường cạnh tranh tạo ra cùng một triệu chứng bên trong WSL2. Ghi lại cả hai phía, rồi sửa phía thực sự hỏng.
Ping theo địa chỉ hoạt động bên trong bản phân phối, cài đặt gói và tải git thì không, và lỗi xuất hiện ngay sau khi đường hầm kết nối. Chỉ tên miền ngừng phân giải, điều này chỉ về DNS chứ không phải kết nối. Cài lại gói là bước đầu sai phổ biến nhất ở đây. WSL2 có hai cách độc lập để tạo ra đúng triệu chứng đó, và chúng cần cách sửa khác nhau.
Vì sao bản phân phối giữ resolver riêng
Ứng dụng khách DNS của Windows không được dùng bên trong bản phân phối. WSL2 dựng tệp resolver riêng khi khởi động, trỏ tới một địa chỉ stub mà Windows công bố trên bộ chuyển mạch ảo cho máy ảo phụ trợ.
Cách sắp xếp đó ổn định qua những thay đổi mạng thông thường vì nó được ghi một lần và dùng lại. Cách sắp xếp mất tính đúng khi ứng dụng khách đường hầm ghi lại danh sách bộ điều hợp của máy chủ sau khi máy ảo phụ trợ đã khởi động.
Không có gì bên trong bản phân phối theo dõi thay đổi đó, nên tệp tiếp tục trỏ tới một địa chỉ có thể không còn trên đường đi. Lần tra cứu tiếp theo sau đó chờ, hết thời gian, hoặc nhận câu trả lời từ máy chủ chưa từng nghe về vùng nội bộ. Từ bên trong, resolver chỉ đơn giản ngừng trả lời, và mọi tên đều hỏng cùng lúc.
Trước tiên hãy thu thập bằng chứng ở cả hai phía
Ghi lại những gì bản phân phối thấy, rồi những gì Windows thấy, trước khi thay đổi bất kỳ bên nào. Chính hai góc nhìn cùng nhau mới phân biệt được các kiểu hỏng.
Bên trong bản phân phối, in tệp resolver, bảng tuyến đường và một tra cứu nội bộ cùng một tra cứu công khai:
ip -4 route
cat /etc/resolv.conf
getent hosts intranet.corp.example
getent hosts example.comTrên Windows, liệt kê máy chủ DNS theo từng bộ điều hợp và bảng IPv4 kèm số liệu. Ứng dụng khách VPN thường cài một tuyến cho mạng con WSL2, và số liệu của nó quyết định lưu lượng đó ra khỏi đường hầm hay ở lại cục bộ.
Get-NetAdapter | Get-DnsClientServerAddress
route print -4
Số liệu tuyến hay tệp cũ
Lỗi đầu tiên là tệp cũ. Resolver được viết cho trạng thái bộ điều hợp lúc khởi động, và đường hầm đã thay đổi trạng thái đó. Địa chỉ stub của nó giờ có thể không tới được, hoặc có thể nêu tên một máy chủ không biết gì về vùng nội bộ.
Lỗi thứ hai là vấn đề định tuyến. Khi VPN thêm một tuyến bao trùm mạng con WSL2 với số liệu thấp hơn tuyến liên kết của máy chủ, các gói tin gửi tới máy ảo phụ trợ sẽ đi vào đường hầm. Khi đó mọi dịch vụ WSL2 đều hết thời gian, không chỉ DNS.
Phép thử phân biệt chỉ tốn một dòng. Nếu một địa chỉ số như resolver công khai vẫn trả lời ping trong khi tên miền hỏng, đường đi còn nguyên và vấn đề là DNS. Đây là trường hợp thay đổi resolver là chính đáng, và trường hợp không chính đáng cũng trở nên rõ ràng. Nếu phép thử số cũng hỏng, máy ảo phụ trợ đã mất tuyến của nó và không tệp resolver nào sửa được điều đó.
Với trường hợp định tuyến, bỏ số liệu tự động trên bộ điều hợp đường hầm và gán cho nó một số cao hơn tuyến liên kết WSL2:
Get-NetAdapter | Where-Object InterfaceDescription -Match VPN | Set-NetIPInterface -InterfaceMetric 5500
wsl.exe --shutdown
Việc tắt máy quan trọng. Đổi số liệu không ghi lại máy ảo phụ trợ đang chạy, nên bản phân phối phải được dựng lại trước khi thay đổi hiển thị.
Hãy tiếp nhận tệp, một cách có chủ đích
Nếu định tuyến đúng và chỉ tên nội bộ hỏng, resolver là thủ phạm và bạn có thể dừng bộ sinh. Đây là thay đổi có chủ đích với chi phí bảo trì, không phải cách lách để áp dụng qua loa.
Tạo /etc/wsl.conf bên trong bản phân phối với phần mạng vô hiệu hóa việc sinh, rồi tự viết tệp resolver, máy chủ công ty trước và một máy chủ công khai dự phòng sau:
[network]
generateResolvConf = falsesearch corp.example
nameserver 10.88.4.53
nameserver 9.9.9.9
Thứ tự quan trọng. Resolver công khai không thể trả lời tên nội bộ, và bản dự phòng chỉ tồn tại cho tra cứu internet. Một khi tệp là của bạn, không gì tái sinh nó, nên resolver công ty chuyển chỗ trở thành sự cố mà chính bạn phải nhận ra.
Kiểm tra tên, rồi kiểm tra gói
Xác minh một tên nội bộ và một tên công khai bằng resolver của hệ thống, rồi lặp lại thao tác đã hỏng. Trình quản lý gói đôi khi dùng resolver riêng, vì thế getent đang chạy được có thể cùng tồn tại với bản cài hỏng.
Nếu bạn tự động hóa việc ghi lại, hãy làm nó idempotent: khi không có đường hầm, giữ tệp đã có thay vì ghi danh sách máy chủ rỗng.
getent hosts intranet.corp.example
resolvectl status | head -20
getent hosts example.com
Một tra cứu nội bộ chạy được và một tra cứu công khai chạy được, từ bên trong bản phân phối, là kết quả đáng ghi lại. Biểu tượng VPN xanh trên máy chủ không chứng minh cả hai.