Duyệt web bên trong bản phân phối vẫn hoạt động, và tên máy chủ nội bộ đầu tiên thất bại ngay khi đường hầm được dựng lên. Phản xạ là thêm một bộ phân giải công cộng, điều này khôi phục internet và khiến tên doanh nghiệp không thể truy cập trong phần còn lại của ngày. Trên WSL 2, /etc/resolv.conf là đầu ra được tạo chứ không phải cấu hình, và đó chính là cơ chế đáng hiểu. Cách sửa không phải bộ phân giải tốt hơn, mà là quyền sở hữu tệp.

Tệp được tạo, không được cấu hình

WSL 2 ghi tệp lúc khởi động từ các bộ điều hợp Windows mà nó thấy tại thời điểm đó, và in một chú thích ở đầu nói điều đó. Khi một ứng dụng VPN thêm hoặc ghi đè bộ điều hợp sau đó, bản phân phối không nhất thiết tạo lại bất cứ thứ gì, và tệp tiếp tục mô tả một mạng không còn tồn tại.

Chế độ hỏng thứ hai kín đáo hơn: WSL có thể chỉ sao chép máy chủ từ một số bộ điều hợp. Nếu bộ điều hợp vật lý đã có bộ phân giải IPv6, các máy chủ IPv4 do bộ điều hợp VPN cung cấp có thể bị bỏ thay vì được thêm vào, và tệp trông đầy đủ trong khi bỏ sót đúng cái trả lời tên nội bộ.

So sánh góc nhìn từ Windows với góc nhìn từ Linux

Đọc cả hai phía trước khi sửa. Bên trong bản phân phối, xem tệp chứa gì và nó là tệp thường hay liên kết. Trên Windows, liệt kê bộ phân giải cho từng bộ điều hợp, kể cả bộ do VPN tạo:

ls -l /etc/resolv.conf
cat /etc/resolv.conf
Get-DnsClientServerAddress -AddressFamily IPv4
Get-NetAdapter | Where-Object Status -eq 'Up'

Khi bộ điều hợp VPN hiển thị máy chủ doanh nghiệp còn Linux hiển thị thứ khác, sự khác biệt nằm ở việc tạo chứ không ở khả năng tiếp cận. So sánh cả danh sách bộ điều hợp lẫn địa chỉ, vì một bộ điều hợp thiếu giải thích một máy chủ thiếu. Sự phân biệt đó quyết định bạn đang sửa WSL hay một tường lửa, và hai thứ đó không có gì chung.

Tắt việc tạo lại và tự viết tệp của bạn

Một thiết lập được tài liệu hóa ngăn WSL ghi lại tệp, và nó nằm trong /etc/wsl.conf. Thêm một phần mạng vào tệp đó:

[network]
generateResolvConf = false

Sau đó dừng bản phân phối từ Windows bằng wsl --shutdown và khởi động lại. Nếu đường dẫn là liên kết tượng trưng chứ không phải tệp thường, hãy xóa liên kết trước khi ghi nội dung của bạn, vì ghi qua liên kết có thể tạo lại đích được tạo ở lần khởi động sau. Từ thời điểm đó tệp là của bạn và không gì ghi đè nó.

nameserver 172.28.4.10
nameserver 172.28.4.11
search site.corp.example
options timeout:1 attempts:2 rotate

Không có miền tìm kiếm, một tên máy chủ chưa đủ điều kiện được bổ sung bằng gốc công cộng và trả về là không có miền như vậy. timeout ngăn máy chủ đầu tiên đã chết chặn mọi truy vấn, attempts giới hạn số lần thử một truy vấn tiêu tốn, và rotate phân tán các lần thử lại thay vì luôn bắt đầu từ trên cùng. Cái giá là tệp không còn theo một VPN có địa chỉ bộ phân giải thay đổi giữa các phiên.

Xử lý bộ phân giải di chuyển, rồi xác minh

Một số ứng dụng cung cấp bộ phân giải riêng cho phiên, nên một tệp tĩnh sẽ hỏng ở lần kết nối tiếp theo. Hai cách tiếp cận là có thể bảo vệ. Ghi tệp từ một script nhỏ mỗi khi địa chỉ thay đổi, hoặc để việc tạo lại bật và bảo đảm bộ điều hợp mà WSL sao chép từ đó mang máy chủ doanh nghiệp. Cách thứ hai không cần móc nối và thất bại mỗi khi việc tạo lại bỏ qua bộ điều hợp VPN; cả hai vẫn đòi hỏi giải quyết xung đột IPv6 trước.

Windows cũng áp dụng các chính sách tên riêng, như danh sách tìm kiếm hậu tố hoặc chính sách phân giải cho các miền cụ thể, và việc sao chép địa chỉ bộ điều hợp không tái tạo các quy tắc đó. Nếu một tên phân giải được trên Windows mà không phân giải được trong bản phân phối với cùng máy chủ, hãy so sánh cách xử lý hậu tố trước khi đổ lỗi cho đường hầm.

Kiểm tra bằng tên chứ không bằng gói: getent hosts sensor-access0.corp.example đi qua ngăn xếp bộ phân giải, trong khi ping có thể thành công với một địa chỉ đã lưu trong bộ nhớ đệm hoặc nguyên văn. Sau đó lặp lại sau khi ngắt và kết nối lại, vì một thiết lập hoạt động một lần và bị tạo lại khi tiếp tục thì chưa bao giờ được sửa. Lưu nội dung trước đó và ghi lại thành phần nào sở hữu đường dẫn trên máy đó, để thay đổi tiếp theo bắt đầu bằng bằng chứng.

Bài viết liên quan