WSL2: Geavanceerde handleiding voor netwerkconfiguratie, NAT en mirrored modes

Informatic Digital » Middelen » WSL2: Geavanceerde handleiding voor netwerkconfiguratie, NAT en mirrored modes

WSL2 heeft de manier waarop Linux met Windows integreert volledig veranderd , met name op het gebied van netwerken: we hebben nu een lichtgewicht virtuele machine met een eigen netwerkstack, IP-adres en aparte toegangsregels. Dit biedt veel mogelijkheden voor ontwikkeling, testen, containers en zelfhostingomgevingen, maar het roept ook zorgen op wanneer services ontoegankelijk worden, zoals het geval was bij WSL1.

Inzicht in de netwerkconfiguratie van WSL2, de NAT- en mirrored-modi, het gebruik van .wslconfig en wsl.conf, en hoe deze samenwerken met firewalls, VPN's, Docker en tools zoals Tailscale, is essentieel om problemen te voorkomen. We zullen stap voor stap bekijken hoe deze hele configuratie werkt, hoe je services beschikbaar maakt voor Windows en het LAN, welke commando's je moet gebruiken om de juiste IP-adressen te verkrijgen en welke geavanceerde configuratieopties je hebt om je omgeving te optimaliseren, zodat deze stabiel en vooral veilig is.

Hoe het netwerk in WSL2 daadwerkelijk werkt.

WSL2 deelt de netwerkstack van de host niet langer zoals WSL1 dat wel deed.In plaats daarvan draait het elke Linux-distributie in een kleine virtuele machine die wordt beheerd door Hyper-V. Die VM heeft zijn eigen virtuele netwerkadapter (meestal eth0) en een privé-IP-adres dat is toegewezen door een interne virtuele switch.

In de standaardmodus maakt WSL2 gebruik van een NAT-gebaseerde architectuur. (Network Address Translation). Windows fungeert als router/host en de Linux-distributie bevindt zich op een privé-subnet, doorgaans binnen het opgegeven bereik. 172.16.0.0/12Dit subnet kan veranderen na herstarts of WSL-herstarts, iets wat al menig gebruiker tot wanhoop heeft gedreven bij het configureren van statische firewallregels.

In de praktijk betekent dit dat het IP-adres van uw WSL2-distributie niet stabiel is en niet direct toegankelijk vanuit het LAN, zoals dat wel het geval was bij WSL1: standaard is er alleen connectiviteit tussen Windows en WSL2 via omleidingsregels en NAT, en toegang tot het lokale netwerk vereist extra stappen of het gebruik van de gespiegelde modus.

Naast deze basisarchitectuur voegen Windows 11 22H2 en latere versies nieuwe netwerkmogelijkheden toe. (gespiegelde modus, dnsTunneling, autoProxy, Hyper-V firewall, enz.) die worden beheerd vanuit het globale bestand .wslconfigterwijl bepaalde opties binnen Linux worden beheerd met /etc/wsl.conf.

Identificeer IP-adressen in WSL2

Bij het werken met WSL2 is het belangrijk om duidelijk onderscheid te maken tussen twee IP-scenario's : wanneer je het IP-adres van de Linux-distributie nodig hebt en wanneer je het IP-adres van de Windows-host nodig hebt, zoals gezien vanuit Linux. Elk scenario wordt afgehandeld met een ander commando.

Scenario 1: Vanuit Windows wilt u het IP-adres van de WSL2-distributie weten, zodat een applicatie op de host (bijvoorbeeld een client, browser of testtool) verbinding kan maken met een service die in Linux draait. Hiervoor kunt u de volgende opdrachten uitvoeren in Windows (CMD of PowerShell):

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

Als je de standaarddistributie wilt gebruiken, kun je de parameter voor de distributie weglaten. en bel gewoon wsl.exe hostname -iOp de achtergrond wordt dit commando in Linux uitgevoerd. hostname --ip-addresses en retourneert het IP-adres van de instantie. Een typisch resultaat zou er bijvoorbeeld zo uit kunnen zien:

172.30.98.229

Scenario 2: Vanuit de Linux-distributie moet je bijvoorbeeld het IP-adres van de Windows-host weten , zodat een WSL2-applicatie verbinding kan maken met een server die native op Windows draait (Node.js, SQL Server, Caddy, enz.). Binnen de Linux-shell kun je het volgende gebruiken:

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

De uitvoer is de standaardgateway van de WSL2 VM , die overeenkomt met het IP-adres van de Windows-host zoals gezien vanuit Linux, zoiets als:

172.30.96.1

Die waarde (bijvoorbeeld, 172.30.96.1) is het adres waarnaar uw Linux-clients moeten verwijzen. Wanneer u toegang wilt krijgen tot services die op de Windows-host draaien terwijl u zich in de klassieke NAT-modus bevindt.

NAT-modus: standaardgedrag van het WSL2-netwerk

Standaard werkt WSL2 in NAT-modus, en voor veel eenvoudige ontwikkelomgevingen is dat meer dan voldoende . Het belangrijkste is om te begrijpen wat "vanzelf" werkt en wat niet, zodat je geen tijd verspilt aan het zoeken naar oplossingen die niet werken.

Linux-services vanuit Windows benaderen via localhostAls je een netwerkapplicatie (bijvoorbeeld een Node.js-server, een Flask-server of een SQL Server op Linux) op je WSL2-distributie uitvoert, kun je deze vanuit Windows benaderen met localhost:puertoWindows stuurt inkomende verbindingen automatisch door naar het interne IP-adres van de WSL2 VM.

Toegang tot services die op Windows draaien vanuit Linux : hier is het anders. Om vanuit WSL2 een netwerkapplicatie op de host te bereiken (zoals een Node.js-server, SQL Server of Caddy op Windows), moet je het IP-adres van de host gebruiken zoals dat vanuit Linux wordt gezien, verkregen met het standaard padcommando:

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

Met dat IP-adres kunt u vanuit Linux verbinding maken met elke service op de host.bijvoorbeeld http://172.30.96.1:3000 als uw Windows-server op alle interfaces luistert op poort 3000.

Wanneer je verbinding maakt via externe IP-adressen (niet via localhost), beschouwen applicaties deze als LAN-verbindingen.Dit betekent dat veel servers geconfigureerd moeten worden om te luisteren naar 0.0.0.0 in plaats van 127.0.0.1Met Flask kun je bijvoorbeeld het volgende uitvoeren:

app.run(host='0.0.0.0')

Deze wijziging verbetert de toegankelijkheid, maar vereist wel zorgvuldige aandacht voor de beveiliging , omdat u verbindingen vanuit uw lokale netwerk toestaat, en niet alleen vanaf het apparaat zelf.

Toegang tot WSL2 vanuit het lokale netwerk (LAN) via NAT.

Een van de meest irritante veranderingen bij de overstap van WSL1 naar WSL2 is dat distributies niet langer rechtstreeks toegankelijk zijn vanuit het LAN . In WSL1 erfden de services van de distributie vrijwel moeiteloos de zichtbaarheid van je Windows-systeem op het netwerk.

In WSL2 heeft de VM een eigen privé-IP-adres en wordt deze niet automatisch op het LAN geadverteerd . Om iets vergelijkbaars te bereiken als in de oude modus, moet u in NAT-modus een poortproxy in Windows aanmaken, net zoals u dat zou doen met elke andere Hyper-V virtuele machine.

Windows bevat hiervoor een klassiek hulpmiddel: netsh interface portproxyEen typisch commando om een ​​hostpoort door te sturen naar het WSL2 IP-adres/poortnummer zou er als volgt uitzien:

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

In de praktijk vervang je de markeringen door specifieke waarden , bijvoorbeeld:

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

Hier listenaddress=0.0.0.0 Dit betekent dat Windows zal luisteren naar alle IPv4-adressen van de host.en zal alles wat via poort 4000 binnenkomt doorsturen naar 192.168.101.100:4000Dit zou het WSL2 IP-adres zijn dat verkregen wordt met:

• wsl hostname -I Het geeft je het IP-adres van de Linux-distributie in de WSL2 VM.
• cat /etc/resolv.conf Het onthult het IP-adres van de Windows Vista-host vanuit WSL2.

Met deze techniek kunt u een service die op WSL2 draait, toegankelijk maken vanaf elke computer in het LAN , zolang de Windows-firewall dit toestaat en u duidelijk maakt dat u een service van een virtuele machine beschikbaar stelt en niet rechtstreeks de host.

IPv6 en moderne netwerkfuncties

WSL2 kan ook met IPv6 werken, wat vooral relevant is in moderne omgevingen, VPN's en bedrijfsnetwerken . Om adressen te beheren, zijn de basiscommando's in Linux gelijk aan die voor IPv4:

• wsl hostname -i Vanuit Windows kunt u het IP-adres van de WSL2-distributie bekijken.
• ip route show | grep -i default | awk '{ print $3 }' vanuit Linux het IP-adres van de Windows-host verkrijgen

De echte kwaliteitsverbetering in IPv6- en VPN-ondersteuning zit in de gespiegelde netwerkmodus , beschikbaar in Windows 11 22H2 en latere versies, die we later in detail zullen bespreken.

Gespiegelde netwerkmodus: Windows-interfaces spiegelen in Linux

Op computers met Windows 11 22H2 of hoger kunt u de "gespiegelde" netwerkmodus in WSL2 activeren, waardoor het model volledig verandert: in plaats van klassieke NAT "ziet" Linux de Windows-netwerkinterfaces gespiegeld.

Om dit in te schakelen, moet je het bestand bewerken. .wslconfig van uw gebruiker, dat is in %UserProfile%\.wslconfigVanuit PowerShell met beheerdersrechten kunt u het openen met:

notepad $env:USERPROFILE\.wslconfig

Voeg binnenin de sectie [wsl2] toe (of wijzig deze) om de gespiegelde modus te activeren :

[wsl2]
networkingMode=mirrored

Nadat het bestand is opgeslagen, moet u WSL2 opnieuw opstarten om de wijzigingen door te voeren , bijvoorbeeld met:

wsl --shutdown

Wanneer je WSL opnieuw opstart, zal het de nieuwe gespiegelde netwerkarchitectuur gebruiken , die verschillende krachtige voordelen biedt:

• Native IPv6-ondersteuning en verbeterde integratie met bedrijfsnetwerken en VPN's.
• Mogelijkheid om vanuit Linux verbinding te maken met Windows-services. 127.0.0.1 directamente (hoewel het niet is toegestaan) ::1 (zoals bijvoorbeeld IPv6 loopback hiervoor)
• Verbeterde multicast-ondersteuning binnen de Windows-Linux-integratie.
• Directe toegang tot WSL vanuit het LAN zonder netsh portproxy nodig te hebben.door gebruik te maken van het IP-adres van de Windows-machine zelf.

Door deze modus in te schakelen worden veel van de klassieke WSL2 NAT-problemen opgelost . Dit is de aanbevolen optie in de meeste moderne ontwikkel- en zelfhostingomgevingen waar u een bijgewerkte versie van Windows 11 kunt gebruiken.

DNS-tunneling en het gebruik van proxy's in WSL2

In Windows 11 22H2 en latere versies is de naamresolutie vanuit WSL2 ook aanzienlijk verbeterd.De sleutel ligt in twee functionaliteiten die gedefinieerd zijn in .wslconfig: dnsTunneling y autoProxy.

De keuze dnsTunneling Het is standaard ingeschakeld in de [wsl2]-sectie. Hierdoor kunnen Linux DNS-verzoeken via een virtualisatiefunctie worden verwerkt in plaats van als normale netwerkpakketten te worden verzonden. Dit verbetert de compatibiliteit met VPN's en complexe netwerkconfiguraties op de host aanzienlijk.

Van haar kant, autoProxy=true Dwingt WSL om de HTTP-proxyinstellingen van Windows te gebruiken.Als de host zich achter een bedrijfs- of beveiligingsproxy bevindt, erft WSL2 deze automatisch over zonder dat u handmatig omgevingsvariabelen hoeft aan te passen.

Je zou bijvoorbeeld zoiets in je kunnen hebben. .wslconfig:

[wsl2]
dnsTunneling=true
autoProxy=true

Dit zorgt ervoor dat het WSL2-netwerk zich consistent gedraagt ​​met de hostconfiguratie , wat vooral handig is in bedrijven met strikte netwerk- en filterregels.

Hyper-V-firewall en beveiligde serviceblootstelling

In moderne omgevingen loopt het WSL2-netwerk ook via een speciale firewall . Vanaf WSL 2.0.9 op Windows 11 22H2 is de Hyper-V-firewall standaard ingeschakeld, wat een extra filterlaag toevoegt voor VM-verkeer (inclusief WSL2-verkeer).

Als u in de gespiegelde modus werkt en WSL2-services permanent beschikbaar wilt maken voor het LAN (bijvoorbeeld API's, dashboards of zelfgehoste services), moet u ervoor zorgen dat de firewallregels dit toestaan.

Een redelijke aanpak vanuit PowerShell met beheerdersrechten is het maken van een Hyper-V-regel voor privénetwerken :

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

Mocht u om welke reden dan ook deze specifieke Hyper-V-beveiliging willen uitschakelen (wat minder aan te raden is), dan kunt u het volgende gebruiken:

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

Het idee is om de firewall zoveel mogelijk actief te houden , de regels te beperken tot privénetwerken en alleen tot de poorten die je echt nodig hebt, en massale deactivering als laatste redmiddel te beschouwen en altijd met het oog op het opnieuw beveiligen van de configuratie zodra alles weer werkt.

WSL2-netwerkarchitectuur, X11- en 172.16.0.0/12-bereiken

Een klassiek voorbeeld dat details van het WSL2-netwerk onthult, is het gebruik van grafische applicaties via X11 , bijvoorbeeld het starten van Xming op Windows en het verzenden van Linux-applicaties via DISPLAY.

Bij een upgrade van WSL1 naar WSL2 merken veel gebruikers dat X niet meer werkt. omdat het netwerk niet langer "gedeeld" is, maar een virtueel NAT-netwerk wordt met bereiken zoals 172.16.0.0/12Dit kan ook veranderen na elke herstart van Windows of WSL.

Om X weer werkend te krijgen met Xming vanuit WSL2, is de gebruikelijke truc om het Windows IP-adres te achterhalen dat Linux ziet met behulp van:

ens

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

Tegelijkertijd is het nodig om de Windows-firewall aan te passen om X11-verkeer vanuit dat NAT-subnet toe te staan.Een gebruikelijke aanpak is om de Xming-regel te bewerken door het bereik toe te voegen. 172.16.0.0/12 in TCP+UDP 6000.

Velen schakelen uiteindelijk de Xming-authenticatie uit met de optie -acDit opent in feite de deur voor elke client X die vanuit dat netwerk binnenkomt. Het werkt, maar vanuit een beveiligingsperspectief is het nogal twijfelachtig. Daarom is het de moeite waard om te overwegen om beperktere oplossingen te gebruiken of WSLg (geïntegreerde GUI-applicaties) in Windows 11.

wsl.conf en .wslconfig: geavanceerde WSL2-configuratie

WSL biedt twee belangrijke configuratiebestanden die zowel het gedrag van de virtuele machine als dat van elke distributie bepalen.: /etc/wsl.conf (per distributie) en %UserProfile%\.wslconfig (Wereldwijd voor alle WSL2-distributies).

wsl.conf leeft binnen de Linux-distributie, in /etc/wsl.confHet wordt gebruikt om lokale opties voor die distributie te configureren: automatisch mounten, genereren van hosts y resolv.confinteroperabiliteit met Windows, standaardgebruiker, systemd, enz.

.wslconfig Het wordt buiten Linux opgeslagen, in het Windows-gebruikersprofiel. (C:\Users\<Usuario>\.wslconfig) en beheert globale parameters van de VM die WSL2 aandrijft: geheugen, CPU's, kernel, netwerkmodus, firewall, DNS, virtuele schijfgrootte, GUI-ondersteuning, enz.

Een interessant detail is de "8-secondenregel" bij het wijzigen van instellingen : wanneer je een van deze bestanden wijzigt, moet je ervoor zorgen dat de WSL VM daadwerkelijk wordt afgesloten. Zelfs als je het distributievenster sluit, kan het nog een paar seconden in het geheugen blijven.

Om een ​​subsysteem opnieuw op te starten, kunt u het volgende gebruiken :

• wsl --list --running om te controleren of er actieve distributies zijn.
• wsl --shutdown alle distributies tegelijk sluiten
• wsl --terminate <distroName> om een ​​specifieke distributie te stoppen

De configuratiewijzigingen worden pas daadwerkelijk toegepast wanneer WSL wordt uitgeschakeld en opnieuw opgestart. Dit wordt vaak over het hoofd gezien, waardoor gebruikers denken dat hun instellingen "niet werken".

Belangrijkste wsl.conf-opties per sectie

het bestand wsl.conf Het is geïnspireerd op het klassieke .ini-formaat, met secties en sleutels.De belangrijkste onderdelen zijn [automount], [network], [interop], [user], [boot], [gpu] y [time].

En [automount] Je bepaalt zelf hoe Windows-schijven worden gekoppeld binnen Linux. (doorgaans laag) /mnt):

• enabled (booleaanse waarde, standaardwaarde true)Indien waar, worden C:/, D:/, enz. automatisch gekoppeld. /mnt/c, /mnt/d...
• mountFsTab (boei)Als het waar is, wordt het verwerkt. /etc/fstab bij het opstarten van de distributie.
• root (ketting): de hoofdmap waar de schijven worden aangekoppeld, bijvoorbeeld /windir/ hebben /windir/c.
• options (door komma's gescheiden lijst): DrvFs-specifieke parameters zoals metadata, uid, gid, umask, fmask, dmask o case.

DrvFs is het brugbestandssysteem tussen Windows en Linux , ontworpen om vanuit WSL toegang te krijgen tot NTFS met toegangscontrole, metadata en hoofdlettergevoeligheid.

In de sectie [network] Je past de automatische generatie van netwerkbestanden aan.:

• generateHostsIndien waar, genereert WSL automatisch /etc/hosts.
• generateResolvConfIndien waar, creëert WSL /etc/resolv.conf met verouderde DNS.
• hostname: hostnaam die de distributie zal gebruiken.

De sectie [interop] regelt de interoperabiliteit met Windows:

• enabled: Hiermee kunt u de mogelijkheid om Windows-processen vanuit WSL te starten in- of uitschakelen.
• appendWindowsPath: bepaalt of Windows-paden moeten worden toegevoegd aan $PATH Linux.

En [user] Je kunt de gebruiker opgeven die standaard wordt gebruikt bij het opstarten van de distributie.:

• default: gebruikersnaam die standaard in WSL wordt gestart.

De sectie [boot] Het is met name handig in Windows 11 en Server 2022. om services zoals Docker automatisch te starten binnen WSL:

• command: opdrachtreeks die moet worden uitgevoerd bij het starten van WSL, bijvoorbeeld service docker start.
• protectBinfmtBeschermt het genereren van systemd-eenheden wanneer systemd is ingeschakeld.

Je hebt ook secties zoals [gpu] (toegang tot de Windows GPU vanuit Linux inschakelen), en [time] Om de tijdzone met Windows te synchroniseren.Dit voorkomt problemen bij de overgang naar zomertijd of tijdens een reis.

.wslconfig: Beheer van de virtuele machine WSL2

Terwijl wsl.conf het gedrag van elke distributie afzonderlijk verfijnt, kunt u met .wslconfig de virtuele machine die door alle WSL2-distributies wordt gedeeld, nauwkeurig afstellen . Dit bestand is alleen relevant voor distributies die als WSL2 draaien, niet als WSL1.

Binnen .wslconfig het hoofdgedeelte is [wsl2]waarbij u belangrijke parameters definieert:

• kernel y kernelModules: absolute paden van Windows naar een aangepaste Linux-kernel en de bijbehorende modules.
• memory: VM-geheugenlimiet (standaard 50% van het host-RAM), bijvoorbeeld 4GB.
• processors: aantal logische processors toegewezen aan de VM.
• localhostForwardingHiermee kunnen open poorten in WSL2 vanuit Windows worden benaderd. localhost.
• swap y swapFile: grootte en pad van het swapbestand voor de VM.
• guiApplications: schakelt ondersteuning voor GUI-applicaties (WSLg) in of uit.
• dnsProxyIn de NAT-modus bepaalt het systeem of de Linux DNS-server de NAT-instantie van de host is of een kopie van de Windows DNS-server.
• networkingModeHier kunt u kiezen tussen none, nat, bridged (verouderd), mirrored o virtioproxy.
• firewall, dnsTunneling y autoProxyDit zijn de opties die we hebben besproken om het WSL-netwerk beter te integreren met Windows-beleid.
• defaultVhdSize: maximale grootte van de VHD waarop het bestandssysteem van de distributie is opgeslagen (standaard 1 TB).

Er is ook een sectie [experimental] waarbij functies tijdens het testen worden geactiveerd als:

• autoMemoryReclaim: instellingen voor automatisch geheugenherstel (uitgeschakeld, geleidelijk, dropCache).
• sparseVhd: het creëren van virtuele schijven met een lage bandbreedte om ruimte te besparen.
• bestEffortDnsParsing y dnsTunnelingIpAddress: fijnafstelling voor DNS-tunneling.
• ignoredPorts: poorten die Linux-apps kunnen gebruiken, zelfs als ze in gebruik zijn op Windows wanneer je in de gespiegelde modus werkt.
• hostAddressLoopbackHiermee kunnen host en container verbinding maken via de lokale IP-adressen van de host in gespiegelde modus.

Een correcte configuratie van .wslconfig maakt het verschil tussen een VM die veel systeembronnen verbruikt en een geoptimaliseerde omgeving die goed samenwerkt met uw Windows-systeem en netwerk , vooral als u werkt met zware workloads, containers of meerdere distributies tegelijk.

WSL2, Docker en netwerken voor zelfhosting met Tailscale

Een heel praktisch voorbeeld is het gebruik van WSL2 op Windows-servers (zelfs Windows Server 2025) als zelfhostingplatform , waarbij Ubuntu op WSL2, Docker Engine (zonder Docker Desktop), Tailscale en een reverse proxy zoals Caddy worden gecombineerd om services zoals n8n of Supabase beschikbaar te stellen.

Het doel is om een ​​stabiele Docker-omgeving binnen WSL2 te creëren en zo de problemen van Docker Desktop op servers te vermijden . Door Docker Engine rechtstreeks op Ubuntu (WSL2) te installeren, is het containernetwerk afhankelijk van het WSL2-netwerk, dat op zijn beurt afhankelijk is van de NAT- of mirrored-modus die is gedefinieerd in .wslconfig.

Met Tailscale geïnstalleerd op WSL2 kunt u uw services publiceren op een mesh VPN zonder poorten op de router te openen, en Caddy gebruiken als reverse proxy om TLS-certificaten, routes en lichtgewicht load balancing tussen containers te centraliseren.

Om een ​​schoon, voorspelbaar en veilig netwerk te behouden, is het raadzaam om :

• Kies één coherente netwerkmodus (NAT of gespiegeld) en documenteer deze.
• Voorkom poortconflicten tussen Windows en WSL2., vertrouwend op ignoredPorts als je gespiegeld gebruikt
• Beheer de blootstelling aan de service uitsluitend via Tailscale of Caddy.in plaats van poorten "standaard" te openen in de firewall
• Automatiseer het opstarten van Docker, Tailscale en Caddy vanuit [boot] in wsl.conf om een ​​omgeving te creëren die dichter bij de productie staat.

Met deze architectuur is WSL2 niet langer alleen een ontwikkeltool, maar kan het een behoorlijk serieus self-hostingplatform worden , mits je de beperkingen ervan accepteert (virtualisatie bovenop Hyper-V, extra netwerklaag, enz.) en het zorgvuldig configureert.

Aanbevelingen voor WSL2-netwerken voor ontwikkeling en testen.

Naast de fijnafstellingen zijn er een aantal richtlijnen die je helpen om comfortabel met het WSL2-netwerk te werken zonder constant te hoeven worstelen met IP-adressen, poorten en firewalls.

Gebruik voor ontwikkelservices hoge poorten (boven 1024) en vermijd geprivilegieerde of veelgebruikte systeempoorten; dit minimaliseert conflicten en maakt extra privileges overbodig.

Zorg ervoor dat de code en de gegevens zich binnen het Linux-bestandssysteem bevinden. (Jij ~/ of interne routes) in plaats van direct te werken aan /mnt/comdat toegang tot NTFS vanuit WSL trager is en I/O-intensieve services kan belemmeren.

Automatiseer netwerkinstellingen en omleidingsregels met scripts. In PowerShell en Bash: bijvoorbeeld een script dat WSL2 configureert bij het opstarten. netsh portproxy (als je NAT blijft gebruiken) of controleer de firewallregels bij gebruik van mirroring.

Vermijd het vertrouwen op veranderende IP-adressen. gegenereerd door de interne virtuele switch. Werk waar mogelijk samen met localhost, hostnamen of vermeldingen in /etc/hosts voor uw services, zodat een IP-wijziging niet de helft van uw testinfrastructuur platlegt.

In professionele of semi-productieomgevingen is het beter om niet blindelings te vertrouwen op de automatische doorstuurfunctie van WSL . Configureer poorten, proxy's en firewallregels expliciet om precies te weten wat er waar toegankelijk is.

Wanneer WSL2 correct geconfigureerd is, biedt het een geïsoleerd maar flexibel netwerk, perfect voor geavanceerde ontwikkeling, API-testen, containerwerk en het simuleren van gedistribueerde omgevingen . De sleutel ligt in het beheersen van netwerkmodi (NAT versus mirrored), de wsl.conf- en .wslconfig-bestanden en de interactie met uw firewall en de tools in uw stack (Docker, Tailscale, reverse proxies), zodat Windows en Linux op dezelfde machine kunnen draaien zonder poortconflicten of het in gevaar brengen van de beveiliging.