WSL2 không tới được mạng con VPN: đọc tuyến của máy chủ

Từ bên trong bản phân phối, ping tới một máy chủ nội bộ hết thời gian chờ trong khi cùng địa chỉ đó trả lời từ Windows. VPN đã kết nối và tuyến Windows đúng, nên khoảng trống là ranh giới WSL. Đi theo đường từ lệnh thất bại trở lại giao diện của máy chủ. Cách khắc phục không phải một CIDR cố định trong tệp cấu hình; mà là đọc địa chỉ hiện tại và thêm nó vào nơi bản phân phối có thể dùng.

Xác nhận tuyến dừng ở đâu

Chạy cùng một phép thử ở cả hai phía: phân giải và kết nối tới một máy chủ nội bộ từ Windows, rồi lặp lại trong bản phân phối. Thành công ở Windows cộng với hết thời gian chờ trong bản phân phối cho thấy lỗi nằm giữa hai bên, không phải ở ứng dụng VPN hay máy chủ nội bộ. Làm việc này trước khi đổi bất kỳ tuyến nào, để hai kết quả mô tả cùng một đích.

Trong bản phân phối, ip -4 addr hiển thị một bộ điều hợp ảo với địa chỉ thuộc dải NAT của WSL, và ip route hiển thị tuyến mặc định trỏ tới cổng WSL. Không có tuyến cho tiền tố công ty, vì bộ điều hợp đường hầm của máy chủ không có bản tương ứng bên trong bản phân phối. Cổng mặc định dẫn tới NAT của WSL, không phải mạng công ty.

Thêm tuyến công ty mà không thêm địa chỉ cục bộ trên một liên kết tiếp cận được trước sẽ tạo ra hết thời gian chờ hoặc lỗi mạng không tiếp cận được. Địa chỉ là phần làm cho tuyến dùng được, nên hãy đọc nó trước và coi tuyến là bước thứ hai.

Chọn mạng phản chiếu hoặc tuyến bằng script

Mạng phản chiếu trao cho bản phân phối chính các giao diện của máy chủ, nên đường hầm và các tuyến của nó xuất hiện mà không cần sao chép. Tính năng phụ thuộc vào bản dựng Windows gần đây và vào networkingMode=mirrored trong .wslconfig, và việc bật nó thay đổi hành vi không liên quan như chuyển tiếp localhost. Hãy coi đó là thay đổi nền tảng, không phải tinh chỉnh tuyến. Nếu bản dựng hỗ trợ và tác dụng phụ chấp nhận được, đây là đường ngắn nhất.

Cách hẹp hơn giữ NAT mặc định và sao chép địa chỉ cùng tuyến của đường hầm vào bản phân phối mỗi khi đường hầm dựng lên. Nó hoạt động trên nhiều bản dựng hơn, không đổi hành vi localhost, và thất bại thấy rõ khi VPN tắt. Cái giá là một script nhỏ phải chạy mỗi lần kết nối.

Chọn một và ghi lại. Trộn cấu hình phản chiếu với tuyến thủ công tạo ra bản phân phối có hai đường tới cùng tiền tố và không có chủ rõ ràng cho cả hai. Một phương pháp được ghi chép dễ gỡ lỗi hơn hai phương pháp nửa cấu hình.

Lấy chi tiết đường hầm hiện tại từ máy chủ

Khớp bộ điều hợp theo địa chỉ MAC thay vì tên, vì tên thay đổi theo ứng dụng VPN và thứ tự kết nối. Liệt kê các bộ điều hợp một lần, ghi lại MAC của bộ điều hợp đường hầm, rồi hỏi địa chỉ và tiền tố của nó. MAC ở lại với bộ điều hợp ảo giữa các lần kết nối lại, còn tên và chỉ số giao diện thì không:

powershell.exe 'Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" } | Get-NetIPAddress -AddressFamily IPv4 | Select-Object IPAddress, PrefixLength'

Cổng đến từ cấu hình giao diện. Lấy chỉ số giao diện trước, rồi đọc bước nhảy tiếp theo. Chỉ số có thể thay đổi sau khi khởi động lại hoặc đặt lại bộ điều hợp, nên script phải đọc nó thay vì lưu lại:

powershell.exe '(Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" }).InterfaceIndex'
powershell.exe '(Get-NetIPConfiguration -InterfaceIndex 27).IPv4DefaultGateway.NextHop'

Đưa đầu ra qua tr -d '\r' trước khi gán cho biến. PowerShell kết thúc dòng bằng ký tự xuống dòng, và nếu không loại bỏ, trường cuối mang một ký tự ẩn khiến lệnh tuyến thất bại với lỗi phân tích khó hiểu.

Áp dụng địa chỉ và tuyến bên trong bản phân phối

Cài địa chỉ đường hầm như một địa chỉ có tiền tố trên giao diện của bản phân phối, rồi định tuyến khối công ty qua cổng của máy chủ:

sudo ip addr add 172.20.14.37/22 dev vpn
sudo ip route add 172.20.0.0/16 via 172.20.12.1 dev vpn

NetworkManager bỏ địa chỉ được cấu hình thủ công khi kết nối quay vòng, và không ứng dụng DHCP nào yêu cầu thay thế. Đặt phương thức thành tự động để mỗi lần kết nối lại làm mới địa chỉ, rồi dựng kết nối lên lại. Phương thức thủ công trông ổn định cho tới lần kết nối lại đầu tiên:

nmcli con show vpn
sudo nmcli con mod vpn ipv4.method auto
sudo nmcli con up vpn

Chạy cả hai bước từ hook khởi động VPN, không phải từ shell tương tác. Một script đọc địa chỉ, thêm nó, thêm tuyến và ghi lại các giá trị biến việc sửa thủ công lặp lại thành việc có thể lặp lại, và nhật ký là thứ đầu tiên cần đọc khi tiền tố thay đổi.

Ghim tên và chứng minh đường đi

Nhân hệ điều hành có thể đổi tên giao diện của bản phân phối giữa eth1 và eth2 sau khi chuyển mạng, và một script viết theo tên sẽ sửa nhầm thiết bị. Một quy tắc udev gắn với MAC cho giao diện một nhãn ổn định:

SUBSYSTEM=="net", ACTION=="add", ATTRS{address}=="3c:52:82:0a:1b:7c", NAME="vpn"

Sau đó xác minh bằng địa chỉ, tuyến và một kết nối TCP thật: ip -4 addr show dev vpn, ip route get 172.20.4.10 và kết nối tới một cổng nội bộ đã biết. Tra cứu tuyến phải nêu thiết bị vpn và địa chỉ nguồn bạn đã thêm.

Nếu cả ba đều qua bên trong bản phân phối mà kết nối vẫn hỏng, gói tin đang rời WSL và bị bỏ ở phía Windows. Kiểm tra tường lửa của máy chủ và bộ lọc riêng của ứng dụng VPN trước khi sửa script, vì một lần sửa tuyến nữa sẽ không chữa được gói tin đã tới máy chủ.