WSL2 tidak sampai ke subnet VPN: baca laluan hos

Distro duduk di belakang NAT sendiri dan tidak pernah melihat terowong Windows. Baca alamat dan awalan semasa daripada hos, kemudian tambahkannya di dalam WSL.

Dari dalam distro, ping ke pelayan dalaman tamat masa manakala alamat yang sama menjawab dari Windows. VPN bersambung dan laluan Windows betul, jadi jurangnya ialah sempadan WSL. Ikut laluan dari arahan yang gagal kembali ke antara muka hos. Pembaikan bukan CIDR tetap dalam fail konfigurasi; ia membaca alamat semasa dan menambahnya di tempat distro boleh menggunakannya.

Sahkan di mana laluan berhenti

Jalankan ujian yang sama pada kedua-dua belah: selesaikan dan sambung ke satu hos dalaman dari Windows, kemudian ulangi di distro. Kejayaan di Windows ditambah tamat masa di distro menunjukkan kegagalan berada di antara keduanya, bukan pada klien VPN atau pelayan dalaman. Lakukan ini sebelum menukar mana-mana laluan, supaya kedua-dua keputusan menerangkan destinasi yang sama.

Di dalam distro, ip -4 addr menunjukkan penyesuai maya dengan alamat daripada julat NAT WSL, dan ip route menunjukkan laluan lalai menuju get laluan WSL. Tiada laluan untuk awalan korporat, kerana penyesuai terowong hos tiada pasangan di dalam distro. Get laluan lalai menuju NAT WSL, bukan rangkaian korporat.

Menambah laluan korporat tanpa menambah alamat tempatan pada pautan yang boleh dicapai terlebih dahulu menghasilkan tamat masa atau ralat rangkaian tidak boleh dicapai. Alamat ialah bahagian yang menjadikan laluan boleh digunakan, jadi bacanya dahulu dan anggap laluan sebagai langkah kedua.

Pilih rangkaian cermin atau laluan berskrip

Rangkaian cermin memberikan distro antara muka hos sendiri, jadi terowong dan laluannya muncul tanpa penyalinan. Ciri ini bergantung pada binaan Windows terkini dan pada networkingMode=mirrored dalam .wslconfig, dan mendayakannya mengubah tingkah laku tidak berkaitan seperti pemajuan localhost. Anggapnya sebagai perubahan platform, bukan pelarasan laluan. Jika binaan menyokongnya dan kesan sampingan boleh diterima, itulah jalan terpendek.

Pendekatan lebih sempit mengekalkan NAT lalai dan menyalin alamat serta laluan terowong ke dalam distro setiap kali terowong naik. Ia berfungsi pada lebih banyak binaan, tidak mengubah tingkah laku localhost, dan gagal secara kelihatan apabila VPN dimatikan. Kosnya ialah skrip kecil yang mesti dijalankan pada setiap sambungan.

Pilih satu dan tuliskan. Mencampur konfigurasi cermin dengan laluan manual menghasilkan distro dengan dua laluan ke awalan yang sama dan tanpa pemilik yang jelas untuk kedua-duanya. Satu kaedah terdokumen lebih mudah dinyahpepijat daripada dua yang separuh dikonfigurasi.

Tarik butiran terowong semasa daripada hos

Padankan penyesuai mengikut alamat MAC dan bukan nama, kerana nama berubah dengan klien VPN dan susunan sambungan. Senaraikan penyesuai sekali, catat MAC penyesuai terowong, kemudian tanyakan alamat dan awalannya. MAC kekal dengan penyesuai maya antara sambungan semula, manakala nama dan indeks antara muka tidak:

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

Get laluan datang daripada konfigurasi antara muka. Dapatkan indeks antara muka dahulu, kemudian baca hop seterusnya. Indeks boleh berubah selepas but semula atau set semula penyesuai, sebab itu skrip harus membacanya dan bukannya menyimpannya:

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

Salurkan output melalui tr -d '\r' sebelum menetapkannya kepada pemboleh ubah. PowerShell menamatkan baris dengan carriage return, dan tanpa penyingkiran medan terakhir membawa aksara tersembunyi yang membuat arahan laluan gagal dengan ralat penghuraian yang mengelirukan.

Gunakan alamat dan laluan di dalam distro

Pasang alamat terowong sebagai alamat berawalan pada antara muka distro, kemudian halakan blok korporat melalui get laluan hos:

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 membuang alamat yang dikonfigurasi secara manual apabila sambungan berputar, dan tiada klien DHCP meminta pengganti. Tetapkan kaedah kepada automatik supaya setiap sambungan semula menyegarkan alamat, kemudian naikkan sambungan semula. Kaedah manual kelihatan stabil sehingga sambungan semula pertama:

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

Jalankan kedua-dua langkah dari cangkuk yang memulakan VPN, bukan dari shell interaktif. Skrip yang membaca alamat, menambahnya, menambah laluan dan merekod nilai menjadikan pembaikan manual berulang menjadi boleh diulang, dan log ialah perkara pertama yang perlu dibaca apabila awalan berubah.

Pin nama dan buktikan laluan

Kernel boleh menamakan semula antara muka distro antara eth1 dan eth2 selepas pertukaran rangkaian, dan skrip yang ditulis mengikut nama kemudian menyunting peranti yang salah. Peraturan udev yang dikunci pada MAC memberi antara muka label yang stabil:

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

Kemudian sahkan dengan alamat, laluan dan sambungan TCP sebenar: ip -4 addr show dev vpn, ip route get 172.20.4.10 dan sambungan ke port dalaman yang diketahui. Carian laluan sepatutnya menamakan peranti vpn dan alamat sumber yang anda tambah.

Jika ketiga-tiganya lulus di dalam distro dan sambungan masih gagal, paket itu meninggalkan WSL dan digugurkan di sebelah Windows. Periksa tembok api hos dan penapisan klien VPN itu sendiri sebelum menukar skrip, kerana suntingan laluan lain tidak akan membaiki paket yang sudah sampai ke hos.

Artikel berkaitan