WSL2: Ghid avansat pentru configurarea rețelei și modurile NAT și mirrored

Informatec Digital » Recursos » WSL2: Ghid avansat pentru configurarea rețelei și modurile NAT și mirrored

WSL2 a schimbat complet modul în care Linux se integrează cu WindowsMai ales în tot ceea ce ține de rețea: acum avem o mașină virtuală ușoară, cu propria stivă de rețea, propria adresă IP și reguli de acces separate. Acest lucru deschide o mulțime de posibilități pentru dezvoltare, testare, containere și medii de auto-găzduire, dar ridică și îngrijorări atunci când serviciile devin inaccesibile, așa cum s-a întâmplat cu WSL1.

Înțelegerea configurației rețelei WSL2, a modurilor NAT și mirrored, a utilizării fișierelor .wslconfig și wsl.conf și a modului în care acestea interacționează cu firewall-uri, VPN-uri, Docker sau instrumente precum Tailscale Acest lucru este esențial pentru a evita durerile de cap. Să vedem pas cu pas cum funcționează întreaga configurație, cum să expunem serviciile către Windows și LAN, ce comenzi să folosim pentru a obține adresele IP corecte și ce opțiuni de configurare avansate avem pentru a regla fin mediul, făcându-l stabil și, mai presus de toate, sigur.

Cum funcționează de fapt rețeaua în WSL2

WSL2 nu mai partajează stiva de rețea gazdă precum WSL1În schimb, rulează fiecare distribuție Linux într-o mică mașină virtuală gestionată de Hyper-V. Acea mașină virtuală are propriul adaptor virtual (de obicei eth0) și o adresă IP privată atribuită de un switch virtual intern.

În modul implicit, WSL2 utilizează o arhitectură bazată pe NAT (Network Address Translation - Traducerea adreselor de rețea). Windows acționează ca router/gazdă, iar distribuția Linux se află pe o subrețea privată, de obicei în intervalul respectiv. 172.16.0.0/12Această subrețea se poate schimba după reporniri sau reporniri WSL, lucru care a înnebunit mai mult de o persoană la configurarea regulilor statice de firewall.

Din punct de vedere practic, aceasta înseamnă că adresa IP a distribuției WSL2 nu este nici stabilă, nici direct accesibilă din LAN. Ca și în cazul WSL1: în mod implicit, există conectivitate între Windows și WSL2 doar prin reguli de redirecționare și NAT, iar expunerea la rețeaua locală necesită pași suplimentari sau utilizarea modului oglindit.

Pe lângă această arhitectură de bază, Windows 11 22H2 și versiunile ulterioare adaugă noi capabilități de rețea. (modul în oglindă, dnsTunneling, autoProxy, firewall Hyper-V etc.) care sunt controlate din fișierul global .wslconfigîn timp ce anumite opțiuni din Linux sunt gestionate cu /etc/wsl.conf.

Identificați adresele IP în WSL2

Lucrul cu WSL2 implică o distincție clară între două scenarii IP: când aveți nevoie de adresa IP a distribuției Linux și când aveți nevoie de adresa IP a gazdei Windows vizualizată din Linux. Fiecare se rezolvă cu o comandă diferită.

Scenariul 1: Din Windows doriți să aflați adresa IP a distribuției WSL2 Pentru a permite unei aplicații de pe gazdă (de exemplu, un client, un browser sau un instrument de testare) să se conecteze la un serviciu care rulează în Linux. Pentru a face acest lucru, puteți executa următoarele comenzi în Windows (folosind CMD sau PowerShell):

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

Dacă doriți să utilizați distribuția implicită, puteți omite parametrul de distribuție. și pur și simplu sunați wsl.exe hostname -iÎn fundal, această comandă se lansează în Linux hostname --ip-addresses și returnează adresa IP a instanței. Un rezultat tipic ar putea arăta cam așa:

172.30.98.229

Scenariul 2: Din distribuția Linux trebuie să cunoașteți adresa IP a gazdei WindowsDe exemplu, pentru a conecta o aplicație WSL2 la un server care rulează nativ pe Windows (Node.js, SQL Server, Caddy etc.). În shell-ul Linux, puteți utiliza:

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

Rezultatul va fi gateway-ul implicit al mașinii virtuale WSL2, care corespunde adresei IP a gazdei Windows așa cum se vede din Linux, ceva de genul:

172.30.96.1

Valoarea respectivă (de exemplu, 172.30.96.1) este adresa la care ar trebui să indice clienții tăi Linux când doriți să accesați servicii care rulează pe gazda Windows în modul NAT clasic.

Mod NAT: comportamentul implicit al rețelei WSL2

WSL2 funcționează în modul NAT din fabrică, iar pentru multe medii de dezvoltare simple, acest lucru este mai mult decât suficient.Important este să înțelegi ce funcționează „de la sine” și ce nu, pentru a nu pierde timpul urmărind fantome.

Accesarea serviciilor Linux din Windows folosind localhostDacă rulați o aplicație de rețea (de exemplu, un server Node.js, un server Flask, un server SQL pe Linux) pe distribuția WSL2, o puteți accesa din Windows folosind localhost:puertoWindows redirecționează automat conexiunile primite către adresa IP internă a mașinii virtuale WSL2.

Accesarea serviciilor care rulează pe Windows din LinuxAici se schimbă lucrurile. Pentru a accesa o aplicație de rețea de pe gazdă (cum ar fi un server Node.js, SQL Server sau Caddy pe Windows) din WSL2, trebuie să utilizați adresa IP a gazdei așa cum se vede din Linux, obținută cu comanda default route:

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

Cu acea adresă IP te poți conecta din Linux la orice serviciu de pe gazdă.de exemplu http://172.30.96.1:3000 dacă serverul Windows ascultă pe portul 3000 pe toate interfețele.

Când vă conectați folosind IP-uri la distanță (nu localhost), aplicațiile le văd ca conexiuni LAN.Aceasta înseamnă că multe servere trebuie configurate să asculte 0.0.0.0 în loc de 127.0.0.1De exemplu, cu Flask ai putea lansa:

app.run(host='0.0.0.0')

Această schimbare îmbunătățește accesibilitatea, dar necesită o concentrare asupra securității.deoarece permiteți conexiuni din rețeaua locală, nu doar de la computerul în sine.

Accesarea WSL2 din rețeaua locală (LAN) folosind NAT

Una dintre cele mai enervante schimbări la trecerea de la WSL1 la WSL2 este că distribuțiile nu mai sunt accesibile direct din LAN.În WSL1, dacă Windows-ul era vizibil în rețea, serviciile distribuției moșteneau acea expunere aproape fără efort.

În WSL2, mașina virtuală are propria adresă IP privată și nu este anunțată automat în LAN.Pentru a obține ceva similar cu vechiul comportament, în modul NAT trebuie să creați un proxy de port în Windows, așa cum ați face cu orice mașină virtuală Hyper-V.

Windows include un instrument clasic pentru asta: netsh interface portproxyO comandă tipică pentru redirecționarea unui port gazdă către adresa IP/portul WSL2 ar fi:

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

În practică, ați înlocui markerii cu valori specifice., de exemplu:

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

Aici listenaddress=0.0.0.0 Aceasta indică faptul că Windows va asculta toate adresele IPv4 ale gazdei.și va redirecționa ce intră prin portul 4000 către 192.168.101.100:4000care ar fi adresa IP WSL2 obținută cu:

• wsl hostname -I Îți oferă adresa IP a distribuției Linux din interiorul mașinii virtuale WSL2
• cat /etc/resolv.conf Dezvăluie adresa IP a gazdei Windows Vista din WSL2.

Cu această tehnică puteți face un serviciu care rulează pe WSL2 accesibil de pe orice computer din LAN.cu condiția ca firewall-ul Windows să permită acest lucru și să fie clar că expuneți un serviciu al unei mașini virtuale, nu direct al gazdei.

IPv6 și funcții moderne de rețea

WSL2 poate funcționa și cu IPv6, ceea ce este relevant în special în mediile moderne, VPN-uri și rețele corporative.Pentru a gestiona adresele, comenzile de bază din Linux sunt echivalente cu cele din IPv4:

• wsl hostname -i Din Windows pentru a vizualiza adresa IP a distribuției WSL2
• ip route show | grep -i default | awk '{ print $3 }' din Linux pentru a obține adresa IP a gazdei Windows

Unde saltul de calitate în ceea ce privește suportul IPv6 și VPN este cu adevărat vizibil este în modul de rețea oglindită., disponibil în Windows 11 22H2 și versiunile ulterioare, pe care le vom vedea în detaliu mai târziu.

Mod de rețea oglindită: oglindirea interfețelor Windows în Linux

Pe computerele cu Windows 11 22H2 sau o versiune ulterioară, puteți activa modul de rețea „în oglindă”. În WSL2, modelul se schimbă complet: în loc de NAT clasic, Linux „vede” interfețele de rețea Windows reflectate.

Pentru a o activa, trebuie să editați fișierul .wslconfig utilizatorului dvs., care este în %UserProfile%\.wslconfigDin PowerShell cu privilegii de administrator, îl puteți deschide cu:

notepad $env:USERPROFILE\.wslconfig

În interior, adăugați (sau modificați) secțiunea [wsl2] pentru a activa modul oglindit:

[wsl2]
networkingMode=mirrored

După ce fișierul este salvat, trebuie să reporniți WSL2 pentru ca acesta să aibă efect.De exemplu, cu:

wsl --shutdown

Când îl reporniți, WSL va utiliza noua arhitectură de rețea în oglindă.ceea ce aduce câteva avantaje foarte puternice:

• Suport nativ IPv6 și integrare îmbunătățită cu rețelele corporative și VPN-urile
• Posibilitatea de a se conecta la serviciile Windows din Linux folosind 127.0.0.1 direct (deși nu este permis) ::1 (cum ar fi loopback-ul IPv6 pentru aceasta)
• Suport multicast îmbunătățit în cadrul integrării Windows-Linux
• Acces direct la WSL din LAN fără a fi nevoie de netsh portproxyfolosind adresa IP a mașinii Windows în sine

Activarea acestui mod rezolvă multe dintre problemele clasice ale WSL2 NAT și este opțiunea recomandată în majoritatea mediilor moderne de dezvoltare și de auto-găzduire, unde puteți utiliza o versiune actualizată de Windows 11.

Tunelarea DNS și utilizarea proxy-urilor în WSL2

În Windows 11 22H2 și versiunile ulterioare, rezoluția numelor din WSL2 a suferit, de asemenea, o revizuire semnificativă.Cheia constă în două funcționalități definite în .wslconfig: dnsTunneling y autoProxy.

Opțiunea dnsTunneling Este activat în mod implicit în secțiunea [wsl2]. Acest lucru permite ca cererile DNS Linux să fie gestionate printr-o funcție de virtualizare, în loc să fie trimise ca pachete de rețea normale. Acest lucru îmbunătățește considerabil compatibilitatea cu VPN-urile și configurațiile complexe de rețea de pe gazdă.

La rândul său, autoProxy=true forțează WSL să utilizeze setările proxy HTTP WindowsDacă gazda se află în spatele unui proxy corporativ sau de securitate, WSL2 îl moștenește automat fără a fi nevoie să vă luptați manual cu variabilele de mediu.

Ai putea avea, de exemplu, ceva de genul acesta în .wslconfig:

[wsl2]
dnsTunneling=true
autoProxy=true

Acest lucru asigură că rețeaua WSL2 se comportă în mod consecvent cu configurația gazdă., util în special în companiile cu politici stricte de rețea și filtrare.

Firewall Hyper-V și expunere securizată a serviciilor

În mediile moderne, rețeaua WSL2 trece și printr-un firewall dedicat.Începând cu WSL 2.0.9 pe Windows 11 22H2, funcția de paravan de protecție Hyper-V este activată în mod implicit, adăugând un strat suplimentar de filtrare pentru traficul mașinilor virtuale (inclusiv traficul WSL2).

Dacă lucrați în modul oglindit și doriți să expuneți permanent serviciile WSL2 la rețeaua LAN (de exemplu, API-uri, tablouri de bord sau servicii de auto-găzduire), trebuie să vă asigurați că regulile firewall-ului permit acest lucru.

O abordare rezonabilă din partea PowerShell cu privilegii de administrator este crearea unei reguli Hyper-V pentru rețele private.:

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

Dacă, din orice motiv, doriți să dezactivați protecția Hyper-V specifică (ceva mai puțin recomandat), ai putea folosi:

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

Ideea este să mențineți firewall-ul activ ori de câte ori este posibil.limitarea regulilor la rețele private și doar la porturile de care aveți cu adevărat nevoie și rezervarea oricărei dezactivări în masă ca ultimă soluție și întotdeauna cu scopul de a consolida din nou configurația imediat ce totul funcționează.

Arhitectura rețelei WSL2, intervalele X11 și 172.16.0.0/12

Un caz clasic care dezvăluie detalii despre rețeaua WSL2 este utilizarea aplicațiilor grafice prin intermediul X11De exemplu, lansarea Xming pe Windows și trimiterea aplicațiilor Linux prin DISPLAY.

La actualizarea de la WSL1 la WSL2, mulți utilizatori constată că X nu mai funcționează. deoarece rețeaua încetează să mai fie „partajată” și devine o rețea NAT virtuală cu intervale precum 172.16.0.0/12care se poate schimba și după fiecare repornire a Windows sau WSL.

Pentru a face X să funcționeze din nou cu Xming din WSL2, trucul obișnuit este să obțineți adresa IP Windows pe care o vede Linux. folosind:

ENS

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

În paralel, este necesar să ajustați firewall-ul Windows pentru a permite traficul X11 din acea subrețea NAT.O abordare tipică este editarea regulii Xming prin adăugarea intervalului 172.16.0.0/12 în TCP+UDP 6000.

Mulți ajung să dezactiveze autentificarea Xming cu opțiunea -acPractic, acest lucru „deschide ușa” oricărui client X care sosește din acea rețea. Funcționează, dar din punct de vedere al securității este destul de discutabilă, așa că merită să luați în considerare soluții mai limitate sau să utilizați WSLg (aplicații GUI integrate) în Windows 11.

wsl.conf și .wslconfig: configurare WSL2 avansată

WSL oferă două fișiere de configurare cheie care controlează atât comportamentul mașinii virtuale, cât și pe cel al fiecărei distribuții.: /etc/wsl.conf (de distribuție) și %UserProfile%\.wslconfig (global pentru toate distribuțiile WSL2).

wsl.conf trăiește în cadrul distribuției Linux, în /etc/wsl.confEste folosit pentru a configura opțiunile locale pentru distribuția respectivă: montări automate, generare de hosts y resolv.confinteroperabilitate cu Windows, utilizatorul implicit, systemd etc.

.wslconfig Este salvat în afara Linuxului, în profilul de utilizator Windows. (C:\Users\<Usuario>\.wslconfig) și controlează parametrii globali ai mașinii virtuale care alimentează WSL2: memorie, procesoare, kernel, mod de rețea, firewall, DNS, dimensiunea discului virtual, suport GUI etc.

Un detaliu curios este „regula celor 8 secunde” la schimbarea setărilor.Când modificați oricare dintre aceste fișiere, trebuie să vă asigurați că mașina virtuală WSL este complet închisă. Chiar dacă închideți fereastra distribuției, aceasta poate rămâne în memorie pentru câteva secunde.

Pentru a forța o repornire a subsistemului, puteți utiliza:

• wsl --list --running pentru a verifica dacă există distribuții active
• wsl --shutdown a închide toate distribuțiile deodată
• wsl --terminate <distroName> pentru a opri o anumită distribuție

Modificările de configurație se aplică efectiv doar atunci când WSL este oprit și repornit.Ceva ce mulți trec cu vederea și cred că ajustările lor „nu funcționează”.

Opțiuni principale wsl.conf pe secțiuni

Dosarul wsl.conf Este inspirat de formatul clasic .ini, cu secțiuni și cheiSecțiunile principale sunt [automount], [network], [interop], [user], [boot], [gpu] y [time].

En [automount] Tu controlezi modul în care sunt montate unitățile Windows în Linux (de obicei scăzut) /mnt):

• enabled (bool, implicit true)Dacă este adevărat, C:/, D:/ etc. sunt montate automat în /mnt/c, /mnt/d...
• mountFsTab (bool)dacă este adevărat, este procesat /etc/fstab la pornirea distribuției.
• root (lanţ)directorul rădăcină unde vor fi montate unitățile, de exemplu /windir/ a avea /windir/c.
• options (listă separată prin virgulă)Parametri specifici DrvFs, cum ar fi metadata, uid, gid, umask, fmask, dmask o case.

DrvFs este sistemul de fișiere care face legătura între Windows și Linux., conceput pentru a accesa NTFS din WSL cu control al permisiunilor, metadate și sensibilitate la majuscule/minuscule.

În secțiune [network] Ajustați generarea automată a fișierelor de rețea:

• generateHosts: dacă este adevărat, WSL generează automat /etc/hosts.
• generateResolvConfDacă este adevărat, WSL creează /etc/resolv.conf cu DNS-ul vechi.
• hostname: numele de gazdă pe care îl va folosi distribuția.

secțiune [interop] controlează interoperabilitatea cu Windows:

• enabledActivează sau dezactivează posibilitatea de a lansa procese Windows din WSL.
• appendWindowsPath: decide dacă să adauge căi Windows la $PATH Linux.

En [user] Puteți specifica utilizatorul care va fi utilizat în mod implicit la pornirea distribuției:

• default: nume de utilizator care va fi pornit în mod implicit în WSL.

secțiune [boot] Este deosebit de util în Windows 11 și Server 2022 pentru a lansa automat servicii, cum ar fi Docker în cadrul WSL:

• command: șir de comandă de executat la pornirea WSL, de exemplu service docker start.
• protectBinfmt: protejează generarea unităților systemd atunci când systemd este activat.

De asemenea, aveți secțiuni precum [gpu] (activează accesul la GPU-ul Windows din Linux) și [time] pentru a sincroniza fusul orar cu WindowsAcest lucru previne problemele atunci când treceți la ora de vară sau călătoriți.

.wslconfig: Controlul mașinii virtuale WSL2

În timp ce wsl.conf ajustează fin comportamentul fiecărei distribuții, .wslconfig vă permite să reglați fin mașina virtuală partajată de toate distribuțiile WSL2.Acest fișier este luat în considerare doar de distribuțiile care rulează ca WSL2, nu ca WSL1.

În .wslconfig secțiunea principală este [wsl2]unde definiți parametrii cheie:

• kernel y kernelModules: căi absolute de la Windows către un kernel Linux personalizat și modulele sale.
• memoryLimită de memorie VM (implicit 50% din memoria RAM a gazdei), de exemplu 4GB.
• processors: numărul de procesoare logice alocate mașinii virtuale.
• localhostForwardingpermite accesul porturilor deschise în WSL2 din Windows folosind localhost.
• swap y swapFile: dimensiunea și calea fișierului swap pentru VM.
• guiApplications: activează sau dezactivează suportul pentru aplicații GUI (WSLg).
• dnsProxyCând vă aflați în modul NAT, acesta decide dacă serverul DNS Linux va fi instanța NAT a gazdei sau o copie a DNS-ului Windows.
• networkingModeAici alegi între none, nat, bridged (învechit), mirrored o virtioproxy.
• firewall, dnsTunneling y autoProxy: opțiuni pe care le-am discutat pentru a integra mai bine rețeaua WSL cu politicile Windows.
• defaultVhdSize: dimensiunea maximă a VHD-ului unde este stocat sistemul de fișiere al distribuției (implicit 1 TB).

Există și o secțiune [experimental] unde sunt activate funcțiile în timpul testării ca:

• autoMemoryReclaim: setări de recuperare automată a memoriei (dezactivat, treptat, dropCache).
• sparseVhd: crearea de discuri virtuale disperse pentru a economisi spațiu.
• bestEffortDnsParsing y dnsTunnelingIpAddress: reglare fină pentru tunelarea DNS.
• ignoredPorts: porturi pe care aplicațiile Linux le pot utiliza chiar dacă sunt utilizate pe Windows atunci când vă aflați în modul oglindire.
• hostAddressLoopback: permite gazdei și containerului să se conecteze folosind adresele IP locale ale gazdei în modul oglindit.

Configurarea corectă a fișierului .wslconfig face diferența dintre o mașină virtuală care consumă multă resurse și un mediu optimizat care funcționează bine cu sistemul și rețeaua Windows.mai ales dacă lucrați cu sarcini de lucru mari, containere sau mai multe distribuții simultane.

WSL2, Docker și rețele pentru auto-găzduire cu Tailscale

Un exemplu foarte practic este utilizarea WSL2 pe servere Windows (chiar și Windows Server 2025) ca platformă de auto-găzduire., combinând Ubuntu pe WSL2, Docker Engine (fără Docker Desktop), Tailscale și un proxy invers precum Caddy pentru a expune servicii precum n8n sau Supabase.

Ideea este de a avea un mediu Docker stabil în cadrul WSL2, evitând problemele legate de Docker Desktop pe servere.Când se instalează Docker Engine direct pe Ubuntu (WSL2), rețeaua de containere se bazează pe rețeaua WSL2, care la rândul ei depinde de modul NAT sau mirrored definit în .wslconfig.

Cu Tailscale instalat pe WSL2, puteți publica serviciile pe o rețea VPN mesh. fără a deschide porturi pe router și folosind Caddy ca proxy invers pentru a centraliza certificatele TLS, rutele și echilibrarea ușoară a încărcării între containere.

Pentru a menține o rețea curată, previzibilă și sigură, este recomandabil:

• Alegeți un singur mod de rețea coerent (NAT sau oglindit) și documentați-l
• Evitați conflictele de porturi între Windows și WSL2, bazându-se pe ignoredPorts dacă folosești oglindă
• Controlați expunerea la service doar prin Tailscale sau Caddyîn loc să deschidă porturile „implicit” în firewall
• Automatizați pornirea Docker, Tailscale și Caddy din [boot] în wsl.conf să avem un mediu mai apropiat de producție

Cu această arhitectură, WSL2 încetează să mai fie doar un instrument de dezvoltare și poate deveni o platformă de auto-găzduire destul de serioasă.cu condiția să acceptați limitările sale (virtualizarea prin Hyper-V, stratul de rețea suplimentar etc.) și să îl configurați cu atenție.

Cele mai bune practici pentru crearea de rețele WSL2 pentru dezvoltare și testare

Pe lângă reglajele fine, există o serie de instrucțiuni care vă ajută să lucrați confortabil cu rețeaua WSL2. fără a te lupta constant cu IP-uri, porturi și firewall-uri.

Pentru serviciile de dezvoltare, utilizați porturi înalte (peste 1024) și evitați porturile privilegiate sau intens utilizate; acest lucru minimizează conflictele și elimină necesitatea unor privilegii suplimentare.

Asigurați-vă că codul și datele se află în sistemul de fișiere Linux. (ta ~/ sau rute interne) în loc să lucreze direct pe /mnt/cdeoarece accesarea NTFS din WSL este mai lentă și poate penaliza serviciile care necesită multe I/O.

Automatizați setările de rețea și regulile de redirecționare cu scripturi În PowerShell și Bash: de exemplu, un script care configurează WSL2 la pornire. netsh portproxy (dacă continuați cu NAT) sau verificați regulile firewall-ului atunci când utilizați mirroring-ul.

Evitați să vă bazați pe schimbarea IP-urilor generat de comutatorul virtual intern. Ori de câte ori este posibil, lucrați cu localhost, nume de gazdă sau intrări în /etc/hosts pentru serviciile dumneavoastră, astfel încât o modificare a adresei IP să nu afecteze jumătate din infrastructura de testare.

În mediile profesionale sau de semi-producție, este recomandat să nu vă bazați orbește pe redirecționarea automată a WSL.Configurați explicit porturile, proxy-urile și regulile firewall-ului pentru a ști exact ce este expus și unde.

Atunci când este configurat corect, WSL2 oferă o rețea izolată, dar flexibilă, perfectă pentru dezvoltare avansată, testare API, lucrul cu containere și simularea mediilor distribuite.Cheia este să stăpânești modurile de rețea (NAT vs. mirrored), fișierele wsl.conf și .wslconfig, precum și interacțiunea cu firewall-ul și instrumentele din stivă (Docker, Tailscale, reverse proxy), astfel încât Windows și Linux să poată rula pe aceeași mașină fără suprapunere de porturi sau compromitere a securității.