WSL2 không thừa hưởng VPN doanh nghiệp, và đó chính là lỗi

Wiki nội bộ mở trong Edge, trong khi git clone bên trong bản phân phối bị hết thời gian chờ. Quan sát duy nhất đó thường được đọc là «VPN đang chặn WSL2», và giờ tiếp theo dành cho việc sửa /etc/resolv.conf. Cách đọc hữu ích hơn là WSL2 chưa bao giờ có đường mạng của máy chủ ngay từ đầu: nó chạy trong một VM tiện ích với bộ điều hợp riêng, tuyến riêng và tệp resolver do Windows tạo cho nó. Mọi thứ sau đó phụ thuộc vào việc bạn thực sự thiếu cái nào trong ba thứ đó.

VM có chồng giao thức, số đo và resolver riêng

Ở chế độ NAT mặc định, bản phân phối nằm sau một switch ảo và ra internet qua máy chủ, nhưng không thấy các bộ điều hợp của máy chủ. ip addr hiển thị một giao diện với địa chỉ riêng, ip route hiển thị tuyến mặc định qua switch đó, và /etc/resolv.conf là một tệp được tạo trỏ tới stub resolver do Windows chọn. Không điều nào trong số này thay đổi vì một ứng dụng khách VPN đã khởi động ở phía Windows.

Đó là lý do «trình duyệt hoạt động» chứng minh quá ít. Trình duyệt dùng chồng giao thức của máy chủ, đường hầm và chính sách resolver của máy chủ. Shell của bạn dùng một chồng khác tình cờ chia sẻ card mạng vật lý. Chúng khớp nhau trong trường hợp tốt và tách ra đúng lúc VPN cài bộ lọc, viết lại danh sách DNS hoặc thêm tuyến cho subnet của switch ảo.

Hai phép thử quyết định bạn đang ở thế giới nào, và chúng phải chạy bên trong bản phân phối:

getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.conf

Tên thất bại trong khi địa chỉ theo nghĩa đen vẫn trả lời là vấn đề resolver. Tên và địa chỉ cùng thất bại là vấn đề đường đi, và không mức chỉnh resolver nào chạm tới được. Tiếp theo là bằng chứng từ phía Windows: Get-NetAdapter | Get-DnsClientServerAddress và route print -4 cho biết đường hầm đã chiếm subnet nơi VM của bạn sống hay chưa.

Lầm tưởng thứ nhất: máy chủ DNS doanh nghiệp sửa được

Sửa tệp resolver là lời khuyên cổ điển, và nó đúng khoảng một nửa thời gian. Khi đúng, nó đúng vì một lý do cụ thể: tệp được tạo trỏ tới resolver chỉ biết tên công khai, nên truy vấn cho intranet.example.internal trả về như không tồn tại dù đường đi vẫn ổn.

Ghim máy chủ của VPN nghĩa là ngăn Windows tạo lại tệp, vì bất kỳ tệp nào bạn viết tay đều bị thay thế ở lần khởi động tiếp theo:

[network]
generateResolvConf = false

Lưu đó thành /etc/wsl.conf, chạy wsl --shutdown từ Windows, sau đó khởi động bản phân phối và viết /etc/resolv.conf với máy chủ của đường hầm trước và resolver công khai chỉ làm dự phòng. Đây là thay đổi lâu dài với chi phí bảo trì: tệp không còn theo máy chủ, nên khi địa chỉ DNS doanh nghiệp thay đổi bản phân phối vẫn hỏi những địa chỉ cũ. Phải có người sở hữu tệp đó.

Nó cũng không làm gì khi lỗi rộng hơn. Nếu curl tới 1.1.1.1 hết thời gian chờ, ứng dụng khách đường hầm đang lọc switch ảo hoặc đang đưa subnet của VM vào đường hầm, và resolver đúng chỉ cho bạn những tên vẫn chưa thể tới.

Lầm tưởng thứ hai: thay đổi số đo giữ được lâu

Khi tên phân giải được nhưng lưu lượng đi ra qua bộ điều hợp vật lý, đòn bẩy là số đo giao diện. Cho bộ điều hợp VPN chi phí cao và switch WSL chi phí thấp:

Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1

Sau đó nhớ rằng trong nhiều bản dựng ứng dụng khách, bộ điều hợp đường hầm được tạo lại ở mỗi lần kết nối và số đo quay về mặc định. Một lệnh chạy một lần là bản sửa lặng lẽ hết hạn, thường là qua một cuối tuần, và phiếu yêu cầu quay lại với «tuần trước nó vẫn chạy». Một tác vụ được lên lịch kích hoạt bởi sự kiện VPN, hoặc một script người dùng chạy sau khi kết nối, là phiên bản trung thực của bản sửa này.

Cùng thời hạn đó áp dụng cho các tuyến máy chủ được thêm cho một tiền tố cứng đầu. Chúng có giá trị như chẩn đoán, vì cho biết vấn đề là một đích hay toàn bộ đường đi, nhưng chúng không phải kiến trúc.

Lầm tưởng thứ ba: một bản sửa phủ mọi bản dựng Windows

wsl-vpnkit là mẫu sidecar: một bản phân phối nhỏ sở hữu đường đi phía máy chủ và chuyển tiếp cho các bản phân phối khác qua một socket ảo, nên lưu lượng ứng dụng thôi phụ thuộc vào switch đã bị lọc. Nó cần đường đi chuẩn hoạt động, nghĩa là gỡ các ghi đè networkingMode và dnsTunneling khỏi %UserProfile%\.wslconfig, khôi phục generateResolvConf = true trong mọi bản phân phối đang chạy và khởi động dịch vụ khi đăng nhập.

Chế độ gương là lựa chọn thay thế tích hợp trên Windows 11 22H2 và mới hơn, và nó là một cài đặt cộng một lần tắt:

[wsl2]
networkingMode=mirrored

Bên trong bản phân phối ip addr sau đó liệt kê các bộ điều hợp của máy chủ, đường hầm có thể xuất hiện trong số đó, và đường hầm DNS chuyển tiếp các truy vấn qua resolver của Windows ngay cả khi ứng dụng khách viết lại danh sách DNS. Nó không phổ quát: một số trình điều khiển lọc vẫn bỏ đường đi gương, và các quy tắc tường lửa Hyper-V có thể cần sự cho phép rõ ràng. Hướng dẫn mạng WSL của Microsoft là trang cần đối chiếu với bản dựng của bạn trước khi áp dụng một công thức viết cho bản mới hơn.

Kiểm tra ba thứ sau mỗi thay đổi

Chọn một cơ chế cho mỗi máy và ghi lại, vì hai cái kết hợp kém. Một sidecar trên chế độ gương nhân đôi việc chuyển tiếp, và một máy chủ gương với mục sidecar cũ trong .wslconfig có xu hướng hỏng sau khi nâng cấp chứ không phải trước đó.

Dù bạn chọn gì, phép thử chấp nhận là cùng ba yêu cầu bên trong bản phân phối: một tên nội bộ, một tên công khai và một địa chỉ thô. Sau đó lặp lại chúng sau khi ngắt và kết nối lại đường hầm, và sau wsl --shutdown. Chỉ tên nội bộ thất bại là chính sách resolver; tên nội bộ và công khai cùng thất bại trong khi địa chỉ vẫn hoạt động vẫn là chính sách resolver; mọi thứ thất bại là đường đi.

Nếu một máy chủ nội bộ thất bại trong khi phần còn lại hoạt động, hãy ngừng nhìn resolver và tìm tuyến còn thiếu cho tiền tố đó. Nếu mọi thứ hoạt động đến lần kết nối lại tiếp theo, bạn đã tìm ra một bản sửa phụ thuộc trạng thái lúc chạy, và nó phải được áp dụng lại tự động hoặc thay bằng một trong hai cơ chế ở trên.