WSL2: Udhëzues i avancuar për konfigurimin e rrjetit dhe NAT dhe modalitetet e pasqyruara

Informatec Digital » Burime » WSL2: Udhëzues i avancuar për konfigurimin e rrjetit dhe NAT dhe modalitetet e pasqyruara

WSL2 ka ndryshuar plotësisht mënyrën se si Linux integrohet me Windows , veçanërisht në gjithçka që lidhet me rrjetëzimin: tani kemi një makinë virtuale të lehtë me rrjetin e vet, adresën IP dhe rregulla të veçanta aksesi. Kjo hap shumë mundësi për zhvillim, testim, kontejnerë dhe mjedise vetë-strehimi, por gjithashtu ngre shqetësime kur shërbimet bëhen të paarritshme, siç ishte rasti me WSL1.

Të kuptuarit e konfigurimit të rrjetit të WSL2, modaliteteve të tij NAT dhe të pasqyruara, përdorimit të .wslconfig dhe wsl.conf, dhe mënyrës se si ato bashkëveprojnë me firewall-et, VPN-të, Docker dhe mjete si Tailscale është çelësi për të shmangur problemet. Do të shohim hap pas hapi se si funksionon i gjithë ky konfigurim, si t'i ekspozojmë shërbimet ndaj Windows dhe LAN-it, cilat komanda duhet të përdoren për të marrë IP-të e sakta dhe cilat opsione të avancuara konfigurimi keni për të përshtatur mjedisin tuaj, duke e bërë atë të qëndrueshëm dhe, mbi të gjitha, të sigurt.

Si funksionon rrjeti në të vërtetë në WSL2

WSL2 nuk e ndan më pirgun e rrjetit pritës si WSL1Në vend të kësaj, ai ekzekuton çdo shpërndarje Linux brenda një makine të vogël virtuale të menaxhuar nga Hyper-V. Kjo VM ka përshtatësin e vet virtual (zakonisht eth0) dhe një adresë IP private të caktuar nga një switch virtual i brendshëm.

Në modalitetin e tij të paracaktuar, WSL2 përdor një arkitekturë të bazuar në NAT. (Përkthimi i Adresës së Rrjetit). Windows vepron si router/host, dhe shpërndarja e Linux ndodhet në një nënrrjet privat, zakonisht brenda diapazonit. 172.16.0.0/12Ky nënrrjet mund të ndryshojë pas rinisjeve ose rinisjeve të WSL, diçka që ka çmendur më shumë se një person gjatë konfigurimit të rregullave statike të firewall-it.

Nga një këndvështrim praktik, kjo do të thotë që adresa IP e shpërndarjes suaj WSL2 nuk është e qëndrueshme ose e arritshme drejtpërdrejt nga LAN-i, siç ishte rasti me WSL1: si parazgjedhje, ekziston vetëm lidhje midis Windows dhe WSL2 përmes rregullave të ridrejtimit dhe NAT, dhe ekspozimi ndaj rrjetit lokal kërkon hapa shtesë ose përdorimin e modalitetit të pasqyruar.

Përveç kësaj arkitekture bazë, Windows 11 22H2 dhe versionet e mëvonshme shtojnë aftësi të reja rrjetëzimi. (modaliteti i pasqyruar, dnsTunneling, autoProxy, firewall Hyper-V, etj.) që kontrollohen nga skedari global .wslconfigndërsa disa opsione brenda Linux-it menaxhohen me /etc/wsl.conf.

Identifikoni adresat IP në WSL2

Puna me WSL2 përfshin dallimin e qartë midis dy skenarëve IP : kur ju nevojitet adresa IP e shpërndarjes Linux dhe kur ju nevojitet adresa IP e hostit të Windows siç shihet nga Linux. Secili trajtohet me një komandë të ndryshme.

Skenari 1: Nga Windows, ju doni të dini adresën IP të shpërndarjes WSL2 në mënyrë që një aplikacion në host (për shembull, një klient, shfletues ose mjet testimi) të mund të lidhet me një shërbim që funksionon brenda Linux. Për ta bërë këtë, mund të ekzekutoni komandat e mëposhtme në Windows (CMD ose PowerShell):

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

Nëse dëshironi të përdorni shpërndarjen e parazgjedhur, mund ta hiqni parametrin e shpërndarjes. dhe thjesht telefononi wsl.exe hostname -iNë sfond, kjo komandë ekzekutohet në Linux. hostname --ip-addresses dhe kthen adresën IP të instancës. Një rezultat tipik mund të duket diçka si kjo:

172.30.98.229

Skenari 2: Nga shpërndarja Linux, duhet të dini adresën IP të hostit të Windows , për shembull, në mënyrë që një aplikacion WSL2 të mund të lidhet me një server që funksionon në mënyrë native në Windows (Node.js, SQL Server, Caddy, etj.). Brenda shell-it Linux, mund të përdorni:

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

Dalja do të jetë porta hyrëse e parazgjedhur e WSL2 VM , e cila korrespondon me adresën IP të hostit të Windows siç shihet nga Linux, diçka si:

172.30.96.1

Kjo vlerë (për shembull, 172.30.96.1) është adresa drejt së cilës duhet të tregojnë klientët tuaj Linux kur dëshironi të hyni në shërbimet që funksionojnë në hostin e Windows ndërsa jeni në modalitetin klasik NAT.

Modaliteti NAT: sjellja e parazgjedhur e rrjetit WSL2

Që në momentin e parë, WSL2 funksionon në modalitetin NAT, dhe për shumë mjedise të thjeshta zhvillimi, kjo është më se e mjaftueshme . Gjëja e rëndësishme është të kuptoni se çfarë funksionon "vetëm" dhe çfarë jo, në mënyrë që të mos humbni kohë duke ndjekur fantazma.

Qasja në shërbimet Linux nga Windows duke përdorur localhostNëse ekzekutoni një aplikacion rrjeti (për shembull, një server Node.js, një server Flask, një SQL Server në Linux) në shpërndarjen tuaj WSL2, mund ta qaseni atë nga Windows duke përdorur localhost:puertoWindows automatikisht i përcjell lidhjet hyrëse në adresën e brendshme IP të WSL2 VM.

Qasja në shërbimet që funksionojnë në Windows nga Linux : gjërat ndryshojnë këtu. Për të arritur një aplikacion rrjeti në host (siç është një server Node.js, SQL Server ose Caddy në Windows) nga WSL2, duhet të përdorni adresën IP të hostit siç shihet nga Linux, e marrë me komandën e parazgjedhur të shtegut:

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

Me atë adresë IP mund të lidheni nga Linux me çdo shërbim në host., për shembull http://172.30.96.1:3000 nëse serveri juaj i Windows dëgjon në portin 3000 në të gjitha ndërfaqet.

Kur lidheni duke përdorur IP të largëta (jo localhost), aplikacionet i shohin ato si lidhje LAN.Kjo do të thotë që shumë servera duhet të konfigurohen për të dëgjuar 0.0.0.0 në vend të 127.0.0.1Për shembull, me Flask mund të lançoni:

app.run(host='0.0.0.0')

Ky ndryshim përmirëson aksesueshmërinë, por kërkon vëmendje të kujdesshme ndaj sigurisë , sepse po lejoni lidhje nga rrjeti juaj lokal, jo vetëm nga vetë pajisja.

Qasja në WSL2 nga rrjeti lokal (LAN) duke përdorur NAT

Një nga ndryshimet më bezdisëse gjatë kalimit nga WSL1 në WSL2 është se shpërndarjet nuk janë më të arritshme drejtpërdrejt nga LAN-i . Në WSL1, nëse sistemi juaj Windows ishte i dukshëm në rrjet, shërbimet e shpërndarjes e trashëgonin atë ekspozim pothuajse pa mundim.

Në WSL2, makina virtuale ka adresën e vet private IP dhe nuk reklamohet automatikisht në rrjetin lokal (LAN) . Për të arritur diçka të ngjashme me sjelljen e vjetër, në modalitetin NAT duhet të krijoni një server proxy porte në Windows, njësoj siç do të bënit me çdo makinë virtuale Hyper-V.

Windows përfshin një mjet klasik për këtë: netsh interface portproxyNjë komandë tipike për të ridrejtuar një port pritës në IP/portin WSL2 do të ishte:

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

Në praktikë, do t'i zëvendësonit shënuesit me vlera specifike , për shembull:

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

Këtu listenaddress=0.0.0.0 Kjo tregon që Windows do të dëgjojë të gjitha adresat IPv4 të hostit.dhe do të përcjellë atë që vjen përmes portit 4000 te 192.168.101.100:4000e cila do të ishte adresa IP e WSL2 e marrë me:

• wsl hostname -I Ju jep adresën IP të shpërndarjes Linux brenda WSL2 VM.
• cat /etc/resolv.conf Ai zbulon adresën IP të hostit të Windows Vista nga WSL2.

Me këtë teknikë, ju mund ta bëni një shërbim që funksionon në WSL2 të aksesueshëm nga çdo kompjuter në rrjetin lokal (LAN) , për sa kohë që firewall-i i Windows e lejon këtë dhe jeni të qartë se po ekspozoni një shërbim të një VM-je, jo direkt të host-it.

IPv6 dhe veçoritë moderne të rrjetëzimit

WSL2 mund të funksionojë gjithashtu me IPv6, gjë që është veçanërisht e rëndësishme në mjediset moderne, VPN-të dhe rrjetet e korporatave . Për të menaxhuar adresat, komandat bazë në Linux janë ekuivalente me ato për IPv4:

• wsl hostname -i Nga Windows për të parë adresën IP të shpërndarjes WSL2
• ip route show | grep -i default | awk '{ print $3 }' nga Linux për të marrë adresën IP të hostit të Windows

Rritja e vërtetë në cilësi në mbështetjen për IPv6 dhe VPN është në modalitetin e rrjetit të pasqyruar , i disponueshëm në Windows 11 22H2 dhe versionet e mëvonshme, të cilat do t'i shohim në detaje më vonë.

Modaliteti i rrjetit të pasqyruar: pasqyrimi i ndërfaqeve të Windows në Linux

Në kompjuterët me Windows 11 22H2 ose më të lartë, mund të aktivizoni modalitetin e rrjetit "të pasqyruar" në WSL2, i cili e ndryshon plotësisht modelin: në vend të NAT klasik, Linux "sheh" ndërfaqet e rrjetit të Windows të reflektuara.

Për ta aktivizuar, duhet të modifikoni skedarin .wslconfig e përdoruesit tuaj, e cila është në %UserProfile%\.wslconfigNga PowerShell me privilegje administratori, mund ta hapni atë me:

notepad $env:USERPROFILE\.wslconfig

Brenda, shtoni (ose modifikoni) seksionin [wsl2] për të aktivizuar modalitetin e pasqyruar :

[wsl2]
networkingMode=mirrored

Pasi të ruhet skedari, duhet të rinisni WSL2 që të hyjë në fuqi , për shembull me:

wsl --shutdown

Kur ta rinisni, WSL do të përdorë arkitekturën e re të rrjetit të pasqyruar , e cila sjell disa përparësi të fuqishme:

• Mbështetje native për IPv6 dhe integrim i përmirësuar me rrjetet dhe VPN-të e korporatave
• Mundësia për t'u lidhur me shërbimet e Windows nga Linux duke përdorur 127.0.0.1 direkt (edhe pse nuk lejohet) ::1 (si p.sh. IPv6 loopback për këtë)
• Mbështetje e përmirësuar multicast brenda integrimit Windows-Linux
• Qasje direkte në WSL nga LAN pa pasur nevojë për netsh portproxyduke përdorur adresën IP të vetë makinës Windows

Aktivizimi i këtij modaliteti zgjidh shumë nga problemet klasike të WSL2 NAT dhe është opsioni i rekomanduar në shumicën e mjediseve moderne të zhvillimit dhe vetë-pritjes ku mund të përdorni një Windows 11 të përditësuar.

Tuneli DNS dhe përdorimi i proxy-ve në WSL2

Në Windows 11 22H2 dhe versionet e mëvonshme, zgjidhja e emrit nga WSL2 ka marrë gjithashtu një rishikim të rëndësishëm.Çelësi qëndron në dy funksionalitete të përcaktuara në .wslconfig: dnsTunneling y autoProxy.

Opsioni dnsTunneling Aktivizohet si parazgjedhje në seksionin [wsl2]. Kjo lejon që kërkesat DNS të Linux të trajtohen përmes një funksioni virtualizimi, në vend që të dërgohen si paketa normale rrjeti. Kjo përmirëson shumë përputhshmërinë me VPN-të dhe konfigurimet komplekse të rrjetit në host.

Nga ana e saj, autoProxy=true detyron WSL të përdorë cilësimet e proxy-t HTTP të WindowsNëse hosti ndodhet pas një proxy të korporatës ose të sigurisë, WSL2 e trashëgon automatikisht atë pa pasur nevojë të merreni manualisht me variablat e mjedisit.

Mund të kesh, për shembull, diçka të tillë në faqen tënde .wslconfig:

[wsl2]
dnsTunneling=true
autoProxy=true

Kjo siguron që rrjeti WSL2 të sillet në mënyrë konsistente me konfigurimin e hostit , gjë që është veçanërisht e dobishme në kompanitë me politika të rrepta të rrjetit dhe filtrimit.

Firewall Hyper-V dhe Ekspozimi i Shërbimit të Sigurt

Në mjediset moderne, rrjeti WSL2 kalon gjithashtu përmes një firewall-i të dedikuar . Duke filluar me WSL 2.0.9 në Windows 11 22H2, funksioni i firewall-it Hyper-V aktivizohet si parazgjedhje, duke shtuar një shtresë shtesë filtrimi për trafikun e VM-së (duke përfshirë trafikun WSL2).

Nëse po punoni në modalitetin e pasqyruar dhe dëshironi të ekspozoni përgjithmonë shërbimet WSL2 në LAN (p.sh., API-të, panelet e kontrollit ose shërbimet vetë-strehuese), duhet të siguroheni që rregullat e firewall-it e lejojnë këtë.

Një qasje e arsyeshme nga PowerShell me privilegje administratori është krijimi i një rregulli Hyper-V për rrjetet private :

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

Nëse për ndonjë arsye doni të çaktivizoni atë mbrojtje specifike Hyper-V (e cila është më pak e rekomanduar), mund të përdorni:

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

Ideja është që muri i zjarrit të mbahet aktiv sa herë që të jetë e mundur , duke i kufizuar rregullat në rrjetet private dhe vetëm në portet që ju nevojiten vërtet, dhe duke e rezervuar çdo çaktivizim masiv si zgjidhjen e fundit dhe gjithmonë me qëllim forcimin e konfigurimit përsëri sapo gjithçka të funksionojë.

Arkitektura e rrjetit WSL2, diapazoni X11 dhe 172.16.0.0/12

Një rast klasik që zbulon detaje të rrjetit WSL2 është përdorimi i aplikacioneve grafike nëpërmjet X11 , për shembull, nisja e Xming në Windows dhe dërgimi i aplikacioneve Linux nëpërmjet DISPLAY.

Kur përditësohet nga WSL1 në WSL2, shumë përdorues zbulojnë se X ndalon së punuari. sepse rrjeti pushon së qeni i "ndarë" dhe bëhet një rrjet virtual NAT me diapazone të tilla si 172.16.0.0/12të cilat gjithashtu mund të ndryshojnë pas çdo rinisjeje të Windows ose WSL.

Për ta bërë X të punojë përsëri me Xming nga WSL2, truku i zakonshëm është të merrni adresën IP të Windows që Linux e sheh duke përdorur:

ens

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

Paralelisht, është e nevojshme të konfiguroni firewall-in e Windows për të lejuar trafikun X11 nga ai nënrrjet NAT.Një qasje tipike është të modifikoni rregullin Xming duke shtuar diapazonin 172.16.0.0/12 në TCP+UDP 6000.

Shumë përfundojnë duke çaktivizuar vërtetimin Xming me opsionin -acKjo në fakt "hap derën" për çdo klient X që vjen nga ai rrjet. Funksionon, por nga pikëpamja e sigurisë është mjaft e dyshimtë, kështu që ia vlen të merren në konsideratë zgjidhje më të kufizuara ose të përdoret WSLg (aplikacione të integruara GUI) në Windows 11.

wsl.conf dhe .wslconfig: konfigurim i avancuar i WSL2

WSL ofron dy skedarë konfigurimi kyç që kontrollojnë si sjelljen e VM-së ashtu edhe atë të secilës shpërndarje.: /etc/wsl.conf (nga distro) dhe %UserProfile%\.wslconfig (globale për të gjitha shpërndarjet WSL2).

wsl.conf jeton brenda shpërndarjes Linux, në /etc/wsl.confPërdoret për të konfiguruar opsionet lokale për atë shpërndarje: montime automatike, gjenerim i hosts y resolv.confndërveprimi me Windows, përdoruesin e parazgjedhur, systemd, etj.

.wslconfig Ruhet jashtë Linux-it, në profilin e përdoruesit të Windows-it. (C:\Users\<Usuario>\.wslconfig) dhe kontrollon parametrat globalë të VM-së që fuqizon WSL2: memoria, CPU-të, bërthama, modaliteti i rrjetit, firewall-i, DNS, madhësia e diskut virtual, mbështetja e GUI-t, etj.

Një detaj interesant është "rregulli i 8 sekondave" kur ndryshoni cilësimet : kur modifikoni ndonjë nga këto skedarë, duhet të siguroheni që WSL VM të fiket vërtet. Edhe nëse e mbyllni dritaren e shpërndarjes, ajo mund të mbetet në memorie për disa sekonda.

Për të detyruar një rinisje të nënsistemit, mund të përdorni :

• wsl --list --running për të kontrolluar nëse ka ndonjë shpërndarje aktive
• wsl --shutdown për të mbyllur të gjitha shpërndarjet menjëherë
• wsl --terminate <distroName> për të ndaluar një shpërndarje specifike

Vetëm kur WSL fiket dhe riniset, ndryshimet e konfigurimit zbatohen në të vërtetë , diçka që shumë e anashkalojnë dhe mendojnë se cilësimet e tyre "nuk funksionojnë".

Opsionet kryesore të wsl.conf sipas seksionit

Dosja wsl.conf Është i frymëzuar nga formati klasik .ini, me seksione dhe çelësa.Seksionet kryesore janë [automount], [network], [interop], [user], [boot], [gpu] y [time].

En [automount] Ju kontrolloni se si montohen disqet e Windows brenda Linux-it (zakonisht i ulët) /mnt):

• enabled (bool, parazgjedhja është e vërtetë)Nëse është e vërtetë, C:/, D:/, etj. montohen automatikisht në /mnt/c, /mnt/d...
• mountFsTab (bull): nëse është e vërtetë, përpunohet /etc/fstab kur fillon shpërndarja.
• root (zinxhir): direktoria rrënjë ku do të montohen disqet, për shembull /windir/ të ketë /windir/c.
• options (listë e ndarë me presje)Parametrat specifikë të DrvFs, siç janë metadata, uid, gid, umask, fmask, dmask o case.

DrvFs është sistemi i skedarëve urë lidhës midis Windows dhe Linux , i projektuar për të aksesuar NTFS nga WSL me kontroll lejesh, metadata dhe ndjeshmëri ndaj shkronjave të mëdha dhe të vogla.

Në pjesën [network] Ju rregulloni gjenerimin automatik të skedarëve të rrjetit:

• generateHostsNëse është e vërtetë, WSL gjeneron automatikisht /etc/hosts.
• generateResolvConfNëse është e vërtetë, WSL krijon /etc/resolv.conf me DNS të trashëguar.
• hostname: emri i hostit që do të përdorë shpërndarja.

seksion [interop] kontrollon ndërveprimin me Windows:

• enabledAktivizon ose çaktivizon mundësinë për të nisur proceset e Windows nga WSL.
• appendWindowsPath: vendos nëse do të shtohen shtigjet e Windows-it në $PATH Linux.

En [user] Mund të specifikoni përdoruesin që do të përdoret si parazgjedhje kur të filloni shpërndarjen.:

• default: emër përdoruesi që do të niset si parazgjedhje në WSL.

seksion [boot] Është veçanërisht i dobishëm në Windows 11 dhe Server 2022 për të nisur automatikisht shërbime, të tilla si Docker brenda WSL:

• command: varg komandash për t'u ekzekutuar kur nis WSL, për shembull service docker start.
• protectBinfmt: mbron gjenerimin e njësive systemd kur systemd është i aktivizuar.

Ju gjithashtu keni seksione si [gpu] (aktivizoni qasjen në GPU-në e Windows nga Linux), dhe [time] për të sinkronizuar zonën kohore me WindowsKjo parandalon problemet kur kaloni në orën e verës ose udhëtoni.

.wslconfig: Kontroll i makinës virtuale WSL2

Ndërsa wsl.conf rregullon imët sjelljen e secilës shpërndarje, .wslconfig ju lejon të rregulloni imët VM-në e përbashkët nga të gjitha shpërndarjet WSL2 . Ky skedar është i rëndësishëm vetëm për shpërndarjet që funksionojnë si WSL2, jo si WSL1.

brenda .wslconfig seksioni kryesor është [wsl2]ku përcaktoni parametrat kryesorë:

• kernel y kernelModules: shtigje absolute nga Windows në një kernel të personalizuar Linux dhe modulet e tij.
• memoryLimiti i memories VM (parazgjedhur 50% e RAM-it të hostit), për shembull 4GB.
• processors: numri i procesorëve logjikë të caktuar për VM-në.
• localhostForwarding: lejon që portat e hapura në WSL2 të jenë të arritshme nga Windows duke përdorur localhost.
• swap y swapFile: madhësia dhe shtegu i skedarit swap për VM-në.
• guiApplications: aktivizon ose çaktivizon mbështetjen e aplikacioneve GUI (WSLg).
• dnsProxyKur jeni në modalitetin NAT, ai vendos nëse serveri DNS i Linux do të jetë instanca NAT e hostit apo një kopje e DNS-së së Windows.
• networkingModeKëtu ju zgjidhni midis none, nat, bridged (i vjetëruar), mirrored o virtioproxy.
• firewall, dnsTunneling y autoProxyOpsionet që kemi diskutuar për të integruar më mirë rrjetin WSL me politikat e Windows.
• defaultVhdSize: madhësia maksimale e VHD-së ku ruhet sistemi i skedarëve të shpërndarjes (parazgjedhja 1 TB).

Ekziston edhe një seksion [experimental] ku aktivizohen veçoritë gjatë testimit si:

• autoMemoryReclaimCilësimet e rikuperimit automatik të kujtesës (çaktivizuar, gradual, dropCache).
• sparseVhd: krijimi i disqeve virtuale të rralla për të kursyer hapësirë.
• bestEffortDnsParsing y dnsTunnelingIpAddress: rregullim i imët për tunelimin DNS.
• ignoredPortsportat që aplikacionet Linux mund të përdorin edhe nëse janë në përdorim në Windows kur jeni në modalitetin e pasqyruar.
• hostAddressLoopback: lejon që hosti dhe kontejneri të lidhen duke përdorur adresat IP lokale të hostit në modalitetin e pasqyruar.

Konfigurimi i duhur i .wslconfig bën diferencën midis një VM që konsumon shumë burime dhe një mjedisi të optimizuar që funksionon mirë me Windows dhe rrjetin tuaj , veçanërisht nëse punoni me ngarkesa të rënda pune, kontejnerë ose shpërndarje të shumëfishta të njëkohshme.

WSL2, Docker dhe rrjetëzimi për vetë-hostim me Tailscale

Një rast shumë praktik është përdorimi i WSL2 në serverat Windows (madje edhe Windows Server 2025) si një platformë vetë-strehuese , duke kombinuar Ubuntu në WSL2, Docker Engine (pa Docker Desktop), Tailscale dhe një proxy të kundërt si Caddy për të ekspozuar shërbime si n8n ose Supabase.

Qëllimi është të kemi një mjedis të qëndrueshëm Docker brenda WSL2, duke shmangur problemet e Docker Desktop në servera . Duke instaluar Docker Engine direkt në Ubuntu (WSL2), rrjeti i kontejnerëve mbështetet në rrjetin WSL2, i cili nga ana tjetër varet nga NAT ose modaliteti i pasqyruar i përcaktuar në .wslconfig.

Me Tailscale të instaluar në WSL2, ju mund të publikoni shërbimet tuaja në një VPN mesh pa hapur porta në router dhe të përdorni Caddy si një proxy të kundërt për të centralizuar certifikatat TLS, rrugët dhe balancimin e lehtë të ngarkesës midis kontejnerëve.

Për të ruajtur një rrjet të pastër, të parashikueshëm dhe të sigurt, këshillohet që :

• Zgjidhni një modalitet të vetëm të rrjetit koherent (NAT ose të pasqyruar) dhe dokumentojeni atë.
• Shmangni konfliktet e porteve midis Windows dhe WSL2, duke u mbështetur në ignoredPorts nëse përdorni pasqyrë
• Kontrolloni ekspozimin e shërbimit vetëm nëpërmjet Tailscale ose Caddynë vend të hapjes së portave "sipas parazgjedhjes" në firewall
• Automatizoni nisjen e Docker, Tailscale dhe Caddy nga [boot] në wsl.conf për të pasur një mjedis më afër prodhimit

Me këtë arkitekturë, WSL2 pushon së qeni thjesht një mjet zhvillimi dhe mund të bëhet një platformë mjaft serioze vetë-pritëse , me kusht që të pranoni kufizimet e saj (virtualizimi mbi Hyper-V, shtresa shtesë e rrjetit, etj.) dhe ta konfiguroni me kujdes.

Praktikat më të mira për rrjetëzimin WSL2 për zhvillim dhe testim

Përveç rregullimit të hollësishëm, ekzistojnë një numër udhëzimesh që ju ndihmojnë të punoni rehat me rrjetin WSL2 pa u përballur vazhdimisht me IP-të, portet dhe firewall-et.

Për shërbimet e zhvillimit, përdorni porta të larta (mbi 1024) dhe shmangni portat e sistemit me privilegje ose me përdorim të lartë; kjo minimizon konfliktet dhe eliminon nevojën për privilegje shtesë.

Sigurohuni që kodi dhe të dhënat të jenë brenda sistemit të skedarëve Linux. (ju ~/ ose rrugë të brendshme) në vend që të punojnë direkt në /mnt/csepse qasja në NTFS nga WSL është më e ngadaltë dhe mund të penalizojë shërbimet që kërkojnë shumë I/O.

Automatizoni cilësimet e rrjetit dhe rregullat e ridrejtimit me skripte Në PowerShell dhe Bash: për shembull, një skript që konfiguron WSL2 kur fillon. netsh portproxy (nëse vazhdoni me NAT) ose kontrolloni rregullat e firewall-it kur përdorni pasqyrimin.

Shmangni mbështetjen në ndryshimin e IP-ve gjeneruar nga ndërprerësi virtual i brendshëm. Sa herë që është e mundur, punoni me localhost, emrat e hosteve ose hyrjet në /etc/hosts për shërbimet tuaja, në mënyrë që një ndryshim i IP-së të mos prishë gjysmën e infrastrukturës suaj të testimit.

Në mjedise profesionale ose gjysmë-prodhuese, është më mirë të mos mbështeteni verbërisht në ridrejtimin automatik të WSL . Konfiguroni në mënyrë të qartë portet, proxy-t dhe rregullat e firewall-it për të ditur saktësisht se çfarë është e ekspozuar dhe ku.

Kur konfigurohet siç duhet, WSL2 ofron një rrjet të izoluar por fleksibël, perfekt për zhvillim të avancuar, testim API, punë me kontejnerë dhe simulim të mjediseve të shpërndara . Çelësi qëndron në zotërimin e modaliteteve të rrjetit (NAT kundrejt të pasqyruara), skedarëve wsl.conf dhe .wslconfig, si dhe ndërveprimit me firewall-in tuaj dhe mjetet në stack-un tuaj (Docker, Tailscale, reverse proxy), në mënyrë që Windows dhe Linux të mund të funksionojnë në të njëjtën makinë pa konflikte portash ose pa kompromentuar sigurinë.