WSL2: Panduan lanjutan untuk konfigurasi rangkaian dan NAT serta mod cermin

Informatec Digital » Sumber » WSL2: Panduan lanjutan untuk konfigurasi rangkaian dan NAT serta mod cermin

WSL2 telah mengubah sepenuhnya cara Linux berintegrasi dengan Windows , terutamanya dalam semua perkara yang berkaitan dengan rangkaian: kini kita mempunyai mesin maya yang ringan dengan susunan rangkaian, alamat IP dan peraturan akses berasingannya sendiri. Ini membuka banyak kemungkinan untuk pembangunan, pengujian, kontena dan persekitaran pengehosan kendiri, tetapi ia juga menimbulkan kebimbangan apabila perkhidmatan menjadi tidak dapat diakses, seperti yang berlaku dengan WSL1.

Memahami konfigurasi rangkaian WSL2, NAT dan mod cerminannya, penggunaan .wslconfig dan wsl.conf, dan bagaimana ia berinteraksi dengan tembok api, VPN, Docker dan alatan seperti Tailscale adalah kunci untuk mengelakkan masalah. Kita akan melihat langkah demi langkah bagaimana keseluruhan persediaan ini berfungsi, cara mendedahkan perkhidmatan kepada Windows dan LAN, arahan yang perlu digunakan untuk mendapatkan IP yang betul, dan pilihan konfigurasi lanjutan yang anda ada untuk memperhalusi persekitaran anda, menjadikannya stabil dan, yang paling penting, selamat.

Bagaimana rangkaian sebenarnya berfungsi dalam WSL2

WSL2 tidak lagi berkongsi susunan rangkaian hos seperti WSL1Sebaliknya, ia menjalankan setiap pengedaran Linux dalam mesin maya kecil yang diuruskan oleh Hyper-V. VM itu mempunyai penyesuai maya sendiri (biasanya eth0) dan alamat IP peribadi yang diberikan oleh suis maya dalaman.

Dalam mod lalainya, WSL2 menggunakan seni bina berasaskan NAT (Terjemahan Alamat Rangkaian). Windows bertindak sebagai penghala/hos, dan pengedaran Linux berada pada subnet peribadi, biasanya dalam julat tersebut. 172.16.0.0/12Subnet ini boleh berubah selepas but semula atau WSL dimulakan semula, sesuatu yang telah membuatkan lebih daripada seorang menjadi gila apabila mengkonfigurasi peraturan firewall statik.

Dari sudut pandangan praktikal, ini bermakna alamat IP distro WSL2 anda tidak stabil atau boleh diakses secara langsung dari LAN seperti yang berlaku dengan WSL1: secara lalai, hanya terdapat sambungan antara Windows dan WSL2 melalui peraturan pengalihan dan NAT, dan pendedahan kepada rangkaian tempatan memerlukan langkah tambahan atau penggunaan mod cermin.

Selain seni bina asas ini, Windows 11 22H2 dan versi yang lebih baharu menambah keupayaan rangkaian baharu (mod cermin, dnsTunneling, autoProxy, tembok api Hyper-V, dll.) yang dikawal daripada fail global .wslconfigmanakala pilihan tertentu dalam Linux diuruskan dengan /etc/wsl.conf.

Kenal pasti alamat IP dalam WSL2

Bekerja dengan WSL2 melibatkan perbezaan yang jelas antara dua senario IP : apabila anda memerlukan alamat IP pengedaran Linux dan apabila anda memerlukan alamat IP hos Windows seperti yang dilihat dari Linux. Setiap satu dikendalikan dengan arahan yang berbeza.

Senario 1: Dari Windows, anda ingin mengetahui alamat IP pengedaran WSL2 supaya aplikasi pada hos (contohnya, klien, pelayar atau alat pengujian) boleh bersambung ke perkhidmatan yang berjalan dalam Linux. Untuk melakukan ini, anda boleh menjalankan arahan berikut dalam Windows (CMD atau PowerShell):

wsl.exe --distribution <DistroName> hostname -i

Jika anda ingin menggunakan distro lalai, anda boleh meninggalkan parameter pengedaran. dan hanya hubungi wsl.exe hostname -iDi latar belakang, arahan ini dilancarkan dalam Linux hostname --ip-addresses dan mengembalikan alamat IP tika tersebut. Hasil tipikal mungkin kelihatan seperti ini:

172.30.98.229

Senario 2: Daripada pengedaran Linux, anda perlu mengetahui alamat IP hos Windows , contohnya, supaya aplikasi WSL2 boleh bersambung ke pelayan yang berjalan secara natif pada Windows (Node.js, SQL Server, Caddy, dll.). Dalam shell Linux, anda boleh menggunakan:

ip route show | grep -i default | awk '{ print $3 }'

Output akan menjadi get laluan lalai bagi WSL2 VM , yang sepadan dengan alamat IP hos Windows seperti yang dilihat dari Linux, seperti:

172.30.96.1

Nilai itu (contohnya, 172.30.96.1) ialah alamat yang harus ditunjukkan oleh klien Linux anda apabila anda ingin mengakses perkhidmatan yang berjalan pada hos Windows semasa dalam mod NAT klasik.

Mod NAT: tingkah laku lalai rangkaian WSL2

WSL2 berfungsi dalam mod NAT secara automatik, dan untuk kebanyakan persekitaran pembangunan mudah, itu sudah lebih daripada cukup . Perkara penting ialah memahami apa yang berfungsi "dengan sendirinya" dan apa yang tidak, supaya anda tidak membuang masa mengejar hantu.

Mengakses perkhidmatan Linux daripada Windows menggunakan localhostJika anda menjalankan aplikasi rangkaian (contohnya, pelayan Node.js, pelayan Flask, Pelayan SQL pada Linux) pada distro WSL2 anda, anda boleh mengaksesnya daripada Windows menggunakan localhost:puertoWindows secara automatik menghantar sambungan masuk ke alamat IP dalaman VM WSL2.

Mengakses perkhidmatan yang berjalan pada Windows dari Linux : keadaan berubah di sini. Untuk mencapai aplikasi rangkaian pada hos (seperti pelayan Node.js, SQL Server atau Caddy pada Windows) dari WSL2, anda perlu menggunakan alamat IP hos seperti yang dilihat dari Linux, yang diperoleh dengan arahan laluan lalai:

ip route show | grep -i default | awk '{ print $3 }'

Dengan alamat IP itu, anda boleh menyambung dari Linux ke mana-mana perkhidmatan pada hos, sebagai contoh http://172.30.96.1:3000 jika pelayan Windows anda mendengar pada port 3000 pada semua antara muka.

Apabila anda bersambung menggunakan IP jauh (bukan localhost), aplikasi melihatnya sebagai sambungan LAN.Ini bermakna banyak pelayan mesti dikonfigurasikan untuk mendengar 0.0.0.0 sebaliknya 127.0.0.1Contohnya, dengan Flask anda boleh melancarkan:

app.run(host='0.0.0.0')

Perubahan ini meningkatkan kebolehcapaian tetapi memerlukan perhatian yang teliti terhadap keselamatan , kerana anda membenarkan sambungan daripada rangkaian setempat anda, bukan sahaja daripada peranti itu sendiri.

Mengakses WSL2 daripada rangkaian kawasan setempat (LAN) menggunakan NAT

Salah satu perubahan paling menjengkelkan apabila beralih dari WSL1 ke WSL2 ialah pengedaran tidak lagi boleh diakses secara langsung dari LAN . Dalam WSL1, jika sistem Windows anda kelihatan pada rangkaian, perkhidmatan pengedaran mewarisi pendedahan itu dengan hampir tanpa sebarang masalah.

Dalam WSL2, VM mempunyai alamat IP peribadinya sendiri dan tidak diiklankan secara automatik di LAN . Untuk mencapai sesuatu yang serupa dengan tingkah laku lama, dalam mod NAT anda perlu mencipta proksi port dalam Windows, sama seperti yang anda lakukan dengan mana-mana mesin maya Hyper-V.

Windows termasuk alat klasik untuk ini: netsh interface portproxyPerintah biasa untuk mengalihkan port hos ke IP/port WSL2 ialah:

netsh interface portproxy add v4tov4 listenport=<puertoHost> listenaddress=0.0.0.0 connectport=<puertoWSL> connectaddress=(wsl hostname -I)

Dalam praktiknya, anda akan menggantikan penanda dengan nilai tertentu , contohnya:

netsh interface portproxy add v4tov4 listenport=4000 listenaddress=0.0.0.0 connectport=4000 connectaddress=192.168.101.100

di sini listenaddress=0.0.0.0 Ini menunjukkan bahawa Windows akan mendengar semua alamat IPv4 hos.dan akan meneruskan apa yang masuk melalui port 4000 ke 192.168.101.100:4000yang manakah alamat IP WSL2 yang diperoleh dengan:

• wsl hostname -I Ia memberi anda alamat IP distro Linux di dalam VM WSL2
• cat /etc/resolv.conf Ia mendedahkan alamat IP hos Windows Vista daripada WSL2.

Dengan teknik ini, anda boleh menjadikan perkhidmatan yang berjalan pada WSL2 boleh diakses dari mana-mana komputer pada LAN , selagi tembok api Windows membenarkannya dan anda jelas bahawa anda mendedahkan perkhidmatan VM, bukan hos secara langsung.

IPv6 dan ciri-ciri rangkaian moden

WSL2 juga boleh berfungsi dengan IPv6, yang amat relevan dalam persekitaran moden, VPN dan rangkaian korporat . Untuk mengurus alamat, arahan asas dalam Linux adalah setara dengan arahan untuk IPv4:

• wsl hostname -i Dari Windows untuk melihat alamat IP pengedaran WSL2
• ip route show | grep -i default | awk '{ print $3 }' dari Linux untuk mendapatkan alamat IP hos Windows

Lonjakan sebenar dalam kualiti sokongan IPv6 dan VPN adalah dalam mod rangkaian cermin , tersedia dalam Windows 11 22H2 dan versi yang lebih baharu, yang akan kita lihat secara terperinci kemudian.

Mod rangkaian cermin: mencerminkan antara muka Windows dalam Linux

Pada komputer dengan Windows 11 22H2 atau lebih tinggi, anda boleh mengaktifkan mod rangkaian "dicerminkan" dalam WSL2, yang mengubah sepenuhnya model: Linux "melihat" antara muka rangkaian Windows yang dipantulkan dan bukannya NAT klasik.

Untuk mendayakannya, anda perlu mengedit fail tersebut .wslconfig pengguna anda, yang berada di %UserProfile%\.wslconfigDari PowerShell dengan keistimewaan pentadbir, anda boleh membukanya dengan:

notepad $env:USERPROFILE\.wslconfig

Di dalam, tambahkan (atau ubah suai) bahagian [wsl2] untuk mengaktifkan mod cermin :

[wsl2]
networkingMode=mirrored

Sebaik sahaja fail disimpan, anda perlu memulakan semula WSL2 agar ia berkuat kuasa , contohnya dengan:

wsl --shutdown

Apabila anda memulakannya semula, WSL akan menggunakan seni bina rangkaian cermin baharu , yang membawa beberapa kelebihan hebat:

• Sokongan IPv6 asli dan penyepaduan yang dipertingkatkan dengan rangkaian korporat dan VPN
• Keupayaan untuk menyambung ke perkhidmatan Windows dari Linux menggunakan 127.0.0.1 langsung (walaupun ia tidak dibenarkan) ::1 (seperti gelung balik IPv6 untuk ini)
• Sokongan multicast yang dipertingkatkan dalam integrasi Windows-Linux
• Akses terus ke WSL dari LAN tanpa memerlukan netsh portproxymenggunakan alamat IP mesin Windows itu sendiri

Mengaktifkan mod ini menyelesaikan banyak masalah NAT WSL2 klasik dan merupakan pilihan yang disyorkan dalam kebanyakan persekitaran pembangunan dan pengehosan kendiri moden di mana anda boleh menggunakan Windows 11 yang dikemas kini.

Terowong DNS dan penggunaan proksi dalam WSL2

Dalam Windows 11 22H2 dan versi yang lebih baharu, resolusi nama daripada WSL2 juga telah menerima rombakan yang ketara.Kuncinya terletak pada dua fungsi yang ditakrifkan dalam .wslconfig: dnsTunneling y autoProxy.

Pilihan dnsTunneling Ia diaktifkan secara lalai dalam bahagian [wsl2]. Ini membolehkan permintaan DNS Linux dikendalikan melalui ciri virtualisasi, dan bukannya dihantar sebagai paket rangkaian biasa. Ini meningkatkan keserasian dengan VPN dan konfigurasi rangkaian kompleks pada hos dengan ketara.

Bagi pihaknya, autoProxy=true memaksa WSL untuk menggunakan tetapan proksi HTTP WindowsJika hos berada di belakang proksi korporat atau keselamatan, WSL2 mewarisinya secara automatik tanpa anda perlu bergelut dengan pembolehubah persekitaran secara manual.

Anda boleh mempunyai, sebagai contoh, sesuatu seperti ini dalam .wslconfig:

[wsl2]
dnsTunneling=true
autoProxy=true

Ini memastikan rangkaian WSL2 bertindak secara konsisten dengan konfigurasi hos , yang amat berguna dalam syarikat yang mempunyai dasar rangkaian dan penapisan yang ketat.

Firewall Hyper-V dan Pendedahan Perkhidmatan Selamat

Dalam persekitaran moden, rangkaian WSL2 juga melalui tembok api khusus . Bermula dengan WSL 2.0.9 pada Windows 11 22H2, ciri tembok api Hyper-V diaktifkan secara lalai, menambah lapisan penapisan tambahan untuk trafik VM (termasuk trafik WSL2).

Jika anda bekerja dalam mod cermin dan ingin mendedahkan perkhidmatan WSL2 secara kekal ke LAN (cth., API, papan pemuka atau perkhidmatan pengehosan kendiri), anda perlu memastikan bahawa peraturan tembok api membenarkannya.

Pendekatan yang munasabah daripada PowerShell dengan keistimewaan pentadbir adalah untuk mencipta peraturan Hyper-V untuk rangkaian persendirian :

New-NetFirewallHyperVRule -DisplayName "WSLPrivateInboundRule" -Profiles Private -Direction Inbound -Action Allow -VMCreatorId ((Get-NetFirewallHyperVVMCreator).VMCreatorId)

Jika atas sebab tertentu anda ingin melumpuhkan perlindungan Hyper-V tertentu itu (yang kurang disyorkan), anda boleh menggunakan:

Set-NetFirewallHyperVVMSetting -Name ((Get-NetFirewallHyperVVMCreator).VMCreatorId) -Enabled False

Ideanya adalah untuk memastikan tembok api aktif bila-bila masa yang mungkin , mengehadkan peraturan kepada rangkaian persendirian dan hanya kepada port yang anda perlukan, dan menyimpan sebarang penyahaktifan besar-besaran sebagai pilihan terakhir dan sentiasa dengan tujuan untuk mengeraskan konfigurasi sekali lagi sebaik sahaja semuanya berfungsi.

Seni bina rangkaian WSL2, julat X11 dan 172.16.0.0/12

Satu kes klasik yang mendedahkan butiran rangkaian WSL2 ialah penggunaan aplikasi grafik melalui X11 , contohnya melancarkan Xming pada Windows dan menghantar aplikasi Linux melalui DISPLAY.

Apabila menaik taraf daripada WSL1 kepada WSL2, ramai pengguna mendapati bahawa X berhenti berfungsi. kerana rangkaian itu berhenti "dikongsi" dan menjadi rangkaian NAT maya dengan julat seperti 172.16.0.0/12yang juga boleh berubah selepas setiap permulaan semula Windows atau WSL.

Untuk memastikan X berfungsi semula dengan Xming daripada WSL2, cara biasa adalah untuk mendapatkan alamat IP Windows yang dilihat oleh Linux menggunakan:

ens

DISPLAY=$(grep nameserver /etc/resolv.conf | cut -d' ' -f2):0

Secara selari, adalah perlu untuk melaraskan tembok api Windows bagi membenarkan trafik X11 daripada subnet NAT tersebut.Pendekatan biasa adalah dengan mengedit peraturan Xming dengan menambah julat 172.16.0.0/12 dalam TCP+UDP 6000.

Ramai yang akhirnya melumpuhkan pengesahan Xming dengan pilihan tersebut -acIni berkesan "membuka pintu" kepada mana-mana klien X yang tiba dari rangkaian tersebut. Ia berfungsi, tetapi dari sudut keselamatan ia agak meragukan, jadi adalah wajar untuk mempertimbangkan penyelesaian yang lebih terhad atau menggunakan WSLg (aplikasi GUI bersepadu) dalam Windows 11.

wsl.conf dan .wslconfig: konfigurasi WSL2 lanjutan

WSL menawarkan dua fail konfigurasi utama yang mengawal kedua-dua tingkah laku VM dan setiap pengedaran.: /etc/wsl.conf (oleh distro) dan %UserProfile%\.wslconfig (global untuk semua distro WSL2).

wsl.conf berada dalam pengedaran Linux, dalam /etc/wsl.confIa digunakan untuk mengkonfigurasi pilihan setempat untuk distro tersebut: pemasangan automatik, penjanaan hosts y resolv.confkebolehkendalian dengan Windows, pengguna lalai, systemd, dsb.

.wslconfig Ia disimpan di luar Linux, dalam profil pengguna Windows. (C:\Users\<Usuario>\.wslconfig) dan mengawal parameter global VM yang menguasakan WSL2: memori, CPU, kernel, mod rangkaian, tembok api, DNS, saiz cakera maya, sokongan GUI, dsb.

Satu perincian yang menarik ialah "peraturan 8 saat" apabila menukar tetapan : apabila anda mengubah suai mana-mana fail ini, anda perlu memastikan bahawa WSL VM benar-benar dimatikan. Walaupun anda menutup tetingkap distro, ia mungkin kekal dalam ingatan selama beberapa saat.

Untuk memaksa subsistem dimulakan semula, anda boleh menggunakan :

• wsl --list --running untuk menyemak sama ada terdapat sebarang distro yang aktif
• wsl --shutdown untuk menutup semua pengedaran sekaligus
• wsl --terminate <distroName> untuk menghentikan distro tertentu

Hanya apabila WSL dimatikan dan dimulakan semula, barulah perubahan konfigurasi benar-benar digunakan , sesuatu yang ramai terlepas pandang dan berpendapat bahawa tetapan mereka "tidak berfungsi".

Pilihan wsl.conf utama mengikut bahagian

Fail ini wsl.conf Ia diinspirasikan oleh format .ini klasik, dengan bahagian dan kekunciBahagian-bahagian utama ialah [automount], [network], [interop], [user], [boot], [gpu] y [time].

En [automount] Anda mengawal cara pemacu Windows dipasang dalam Linux (biasanya rendah) /mnt):

• enabled (bool, lalai benar)Jika benar, C:/, D:/, dsb., akan dipasang secara automatik /mnt/c, /mnt/d...
• mountFsTab (bool): jika ia benar, ia akan diproses /etc/fstab semasa memulakan distro.
• root (rantai): direktori root tempat pemacu akan dipasang, contohnya /windir/ untuk mempunyai /windir/c.
• options (senarai dipisahkan koma)Parameter khusus DrvFs seperti metadata, uid, gid, umask, fmask, dmask o case.

DrvFs ialah sistem fail jambatan antara Windows dan Linux , yang direka untuk mengakses NTFS daripada WSL dengan kawalan kebenaran, metadata dan sensitiviti huruf besar/kecil.

Dalam bahagian ini [network] Anda melaraskan penjanaan fail rangkaian secara automatik:

• generateHostsJika benar, WSL menjana secara automatik /etc/hosts.
• generateResolvConfJika benar, WSL mencipta /etc/resolv.conf dengan DNS legasi.
• hostname: nama hos yang akan digunakan oleh pengedaran.

Seksyen [interop] mengawal kebolehkendalian dengan Windows:

• enabled: Membolehkan atau melumpuhkan keupayaan untuk melancarkan proses Windows daripada WSL.
• appendWindowsPath: memutuskan sama ada untuk menambah laluan Windows pada $PATH Linux.

En [user] Anda boleh menentukan pengguna yang akan digunakan secara lalai semasa memulakan distro:

• default: nama pengguna yang akan dimulakan secara lalai dalam WSL.

Seksyen [boot] Ia amat berguna dalam Windows 11 dan Server 2022 untuk melancarkan perkhidmatan secara automatik, seperti Docker dalam WSL:

• command: rentetan arahan untuk dilaksanakan semasa memulakan WSL, contohnya service docker start.
• protectBinfmt: melindungi penjanaan unit systemd apabila systemd diaktifkan.

Anda juga mempunyai bahagian seperti [gpu] (membolehkan akses kepada GPU Windows daripada Linux), dan [time] untuk menyegerakkan zon waktu dengan WindowsIni mengelakkan masalah apabila anda beralih ke musim panas atau melancong.

.wslconfig: Kawalan mesin maya WSL2

Walaupun wsl.conf memperhalusi tingkah laku setiap pengedaran, .wslconfig membolehkan anda memperhalusi VM yang dikongsi oleh semua pengedaran WSL2 . Fail ini hanya berkaitan dengan pengedaran yang berjalan sebagai WSL2, bukan WSL1.

Dalam .wslconfig bahagian utama ialah [wsl2]tempat anda menentukan parameter utama:

• kernel y kernelModules: laluan mutlak dari Windows ke kernel Linux tersuai dan modulnya.
• memory: Had memori VM (lalai 50% daripada RAM hos), contohnya 4GB.
• processors: bilangan pemproses logik yang ditugaskan kepada VM.
• localhostForwarding: membenarkan port terbuka dalam WSL2 boleh diakses daripada Windows menggunakan localhost.
• swap y swapFile: saiz dan laluan fail swap untuk VM.
• guiApplications: mendayakan atau melumpuhkan sokongan aplikasi GUI (WSLg).
• dnsProxyApabila anda berada dalam mod NAT, ia akan menentukan sama ada pelayan DNS Linux akan menjadi contoh NAT hos atau salinan DNS Windows.
• networkingModeDi sini anda pilih antara none, nat, bridged (usang), mirrored o virtioproxy.
• firewall, dnsTunneling y autoProxy: pilihan yang telah kita bincangkan untuk mengintegrasikan rangkaian WSL dengan dasar Windows dengan lebih baik.
• defaultVhdSize: saiz maksimum VHD tempat sistem fail distro disimpan (lalai 1 TB).

Terdapat juga bahagian [experimental] tempat ciri diaktifkan dalam pengujian sebagai:

• autoMemoryReclaim: tetapan pemulihan memori automatik (dilumpuhkan, beransur-ansur, dropCache).
• sparseVhd: penciptaan cakera maya yang jarang untuk menjimatkan ruang.
• bestEffortDnsParsing y dnsTunnelingIpAddress: penalaan halus untuk penerowongan DNS.
• ignoredPorts: port yang boleh digunakan oleh aplikasi Linux walaupun ia sedang digunakan pada Windows apabila anda berada dalam mod cermin.
• hostAddressLoopback: membolehkan hos dan kontena bersambung menggunakan alamat IP tempatan hos dalam mod cermin.

Mengkonfigurasi .wslconfig dengan betul membezakan antara VM yang menggunakan sumber dan persekitaran yang dioptimumkan yang berfungsi dengan baik dengan Windows dan rangkaian anda , terutamanya jika anda bekerja dengan beban kerja yang berat, kontena atau berbilang pengedaran serentak.

WSL2, Docker dan rangkaian untuk pengehosan kendiri dengan Tailscale

Satu kes yang sangat praktikal ialah menggunakan WSL2 pada pelayan Windows (walaupun Windows Server 2025) sebagai platform pengehosan kendiri , menggabungkan Ubuntu pada WSL2, Docker Engine (tanpa Docker Desktop), Tailscale dan proksi terbalik seperti Caddy untuk mendedahkan perkhidmatan seperti n8n atau Supabase.

Matlamatnya adalah untuk mempunyai persekitaran Docker yang stabil dalam WSL2, mengelakkan masalah Docker Desktop pada pelayan . Dengan memasang Docker Engine secara langsung pada Ubuntu (WSL2), rangkaian kontena bergantung pada rangkaian WSL2, yang seterusnya bergantung pada NAT atau mod cermin yang ditakrifkan dalam .wslconfig.

Dengan Tailscale dipasang pada WSL2, anda boleh menerbitkan perkhidmatan anda pada VPN jejaring tanpa membuka port pada penghala dan menggunakan Caddy sebagai proksi terbalik untuk memusatkan sijil TLS, laluan dan pengimbangan beban ringan antara kontena.

Untuk mengekalkan rangkaian yang bersih, boleh diramal dan selamat, adalah dinasihatkan untuk :

• Pilih mod rangkaian koheren tunggal (NAT atau cermin) dan dokumentasikannya
• Elakkan konflik port antara Windows dan WSL2, bergantung pada ignoredPorts jika anda menggunakan cermin
• Kawal pendedahan perkhidmatan hanya melalui Tailscale atau Caddybukannya membuka port "secara lalai" dalam firewall
• Automatikkan permulaan Docker, Tailscale dan Caddy daripada [boot] dalam wsl.conf untuk mempunyai persekitaran yang lebih dekat dengan pengeluaran

Dengan seni bina ini, WSL2 tidak lagi menjadi sekadar alat pembangunan dan boleh menjadi platform pengehosan kendiri yang agak serius , dengan syarat anda menerima batasannya (virtualisasi melalui Hyper-V, lapisan rangkaian tambahan, dll.) dan mengkonfigurasinya dengan teliti.

Amalan terbaik untuk rangkaian WSL2 untuk pembangunan dan pengujian

Selain daripada penalaan halus, terdapat beberapa garis panduan yang membantu anda bekerja dengan selesa dengan rangkaian WSL2 tanpa sentiasa bergelut dengan IP, port dan tembok api.

Untuk perkhidmatan pembangunan, gunakan port tinggi (melebihi 1024) dan elakkan port sistem istimewa atau banyak digunakan; ini meminimumkan konflik dan menghapuskan keperluan untuk keistimewaan tambahan.

Pastikan kod dan data berada dalam sistem fail Linux. (anda ~/ atau laluan dalaman) dan bukannya bekerja secara langsung pada /mnt/ckerana mengakses NTFS daripada WSL adalah lebih perlahan dan boleh menghukum perkhidmatan intensif I/O.

Automatikkan tetapan rangkaian dan peraturan pengalihan semula dengan skrip Dalam PowerShell dan Bash: contohnya, skrip yang mengkonfigurasi WSL2 apabila ia bermula. netsh portproxy (jika anda meneruskan dengan NAT) atau semak peraturan tembok api semasa menggunakan pencerminan.

Elakkan bergantung pada perubahan IP dijana oleh suis maya dalaman. Bila-bila masa yang boleh, bekerjasama dengan localhost, nama hos atau entri dalam /etc/hosts untuk perkhidmatan anda, supaya perubahan IP tidak menjejaskan separuh infrastruktur pengujian anda.

Dalam persekitaran profesional atau separa pengeluaran, adalah lebih baik untuk tidak bergantung secara membuta tuli pada pemajuan automatik WSL . Konfigurasikan port, proksi dan peraturan tembok api secara eksplisit untuk mengetahui dengan tepat apa yang terdedah dan di mana.

Apabila dikonfigurasikan dengan betul, WSL2 menawarkan rangkaian terpencil namun fleksibel, sesuai untuk pembangunan lanjutan, pengujian API, kerja kontena dan simulasi persekitaran teragih . Kuncinya terletak pada penguasaan mod rangkaian (NAT vs. cermin), fail wsl.conf dan .wslconfig dan interaksi dengan tembok api anda dan alat dalam tindanan anda (Docker, Tailscale, proksi terbalik), supaya Windows dan Linux boleh berjalan pada mesin yang sama tanpa konflik port atau menjejaskan keselamatan.