WSL2 tidak menjangkau subnet VPN: baca rute host

Distribusi berada di balik NAT-nya sendiri dan tidak pernah melihat terowongan Windows. Baca alamat dan prefiks saat ini dari host, lalu tambahkan di dalam WSL.

Dari dalam distribusi, ping ke server internal habis waktu sementara alamat yang sama menjawab dari Windows. VPN terhubung dan rute Windows benar, jadi celahnya adalah batas WSL. Telusuri jalur dari perintah yang gagal kembali ke antarmuka host. Perbaikannya bukan CIDR tetap di berkas konfigurasi; perbaikannya adalah membaca alamat saat ini dan menambahkannya di tempat distribusi dapat memakainya.

Pastikan di mana jalur berhenti

Jalankan uji yang sama di kedua sisi: selesaikan dan sambungkan ke satu host internal dari Windows, lalu ulangi di distribusi. Keberhasilan di Windows ditambah batas waktu di distribusi menempatkan kegagalan di antara keduanya, bukan di klien VPN atau server internal. Lakukan ini sebelum mengubah rute apa pun, agar kedua hasil menggambarkan tujuan yang sama.

Di dalam distribusi, ip -4 addr menampilkan adaptor virtual dengan alamat dari rentang NAT WSL, dan ip route menampilkan rute bawaan menuju gateway WSL. Tidak ada rute untuk prefiks korporat, karena adaptor terowongan host tidak punya padanan di dalam distribusi. Gateway bawaan menuju NAT WSL, bukan ke jaringan korporat.

Menambahkan rute korporat tanpa lebih dulu menambahkan alamat lokal pada tautan yang dapat dijangkau menghasilkan batas waktu atau galat jaringan tidak terjangkau. Alamat adalah bagian yang membuat rute dapat dipakai, jadi bacalah lebih dulu dan perlakukan rute sebagai langkah kedua.

Pilih jaringan cermin atau rute berskrip

Jaringan cermin memberikan antarmuka host sendiri kepada distribusi, sehingga terowongan dan rutenya muncul tanpa penyalinan. Fitur ini bergantung pada build Windows terbaru dan pada networkingMode=mirrored di .wslconfig, dan mengaktifkannya mengubah perilaku tak terkait seperti penerusan localhost. Perlakukan sebagai perubahan platform, bukan penyetelan rute. Jika build mendukungnya dan efek sampingnya dapat diterima, itu jalur terpendek.

Pendekatan yang lebih sempit mempertahankan NAT bawaan dan menyalin alamat serta rute terowongan ke distribusi setiap kali terowongan naik. Ini bekerja pada lebih banyak build, tidak mengubah perilaku localhost, dan gagal secara terlihat saat VPN mati. Biayanya adalah skrip kecil yang harus dijalankan pada setiap koneksi.

Pilih satu dan tuliskan. Mencampur konfigurasi cermin dengan rute manual menghasilkan distribusi dengan dua jalur ke prefiks yang sama dan tanpa pemilik yang jelas untuk keduanya. Satu metode terdokumentasi lebih mudah di-debug daripada dua yang setengah terkonfigurasi.

Tarik detail terowongan saat ini dari host

Cocokkan adaptor berdasarkan alamat MAC, bukan nama, karena nama berubah mengikuti klien VPN dan urutan koneksi. Daftar adaptor sekali, catat MAC adaptor terowongan, lalu tanyakan alamat dan prefiksnya. MAC tetap bersama adaptor virtual di antara sambungan ulang, sedangkan nama dan indeks antarmuka tidak:

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

Gateway berasal dari konfigurasi antarmuka. Ambil indeks antarmuka lebih dulu, lalu baca hop berikutnya. Indeks dapat berubah setelah reboot atau reset adaptor, karena itu skrip harus membacanya alih-alih menyimpannya:

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

Lewatkan keluaran melalui tr -d '\r' sebelum menetapkannya ke variabel. PowerShell mengakhiri baris dengan carriage return, dan tanpa pembersihan bidang terakhir membawa karakter tersembunyi yang membuat perintah rute gagal dengan galat parsing yang membingungkan.

Terapkan alamat dan rute di dalam distribusi

Pasang alamat terowongan sebagai alamat berprefiks pada antarmuka distribusi, lalu rutekan blok korporat melalui gateway host:

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 manual saat koneksi berputar, dan tidak ada klien DHCP yang meminta pengganti. Setel metode ke otomatis agar setiap sambungan ulang menyegarkan alamat, lalu naikkan koneksi lagi. Metode manual tampak stabil sampai sambungan ulang pertama:

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

Jalankan kedua langkah dari hook yang memulai VPN, bukan dari shell interaktif. Skrip yang membaca alamat, menambahkannya, menambahkan rute, dan mencatat nilainya mengubah perbaikan manual berulang menjadi dapat diulang, dan log adalah hal pertama yang dibaca saat prefiks berubah.

Sematkan nama dan buktikan jalurnya

Kernel dapat mengganti nama antarmuka distribusi antara eth1 dan eth2 setelah pergantian jaringan, dan skrip yang ditulis untuk sebuah nama lalu menyunting perangkat yang salah. Aturan udev yang dikunci ke MAC memberi antarmuka label yang stabil:

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

Lalu verifikasi dengan alamat, rute, dan koneksi TCP nyata: ip -4 addr show dev vpn, ip route get 172.20.4.10 dan koneksi ke porta internal yang dikenal. Pencarian rute seharusnya menyebut perangkat vpn dan alamat sumber yang Anda tambahkan.

Jika ketiganya lolos di dalam distribusi dan koneksi tetap gagal, paket meninggalkan WSL dan dibuang di sisi Windows. Periksa firewall host dan penyaringan klien VPN itu sendiri sebelum mengubah skrip, karena suntingan rute lain tidak akan memperbaiki paket yang sudah mencapai host.

Artikel terkait