WSL2: Avancerad guide till nätverkskonfiguration och NAT- och speglade lägen

Informatec Digital » Resurser » WSL2: Avancerad guide till nätverkskonfiguration och NAT- och speglade lägen

WSL2 har helt förändrat hur Linux integreras med WindowsSärskilt i allt som rör nätverket: vi har nu en lätt virtuell maskin med egen nätverksstack, egen IP-adress och separata åtkomstregler. Detta öppnar upp många möjligheter för utveckling, testning, containrar och självhostande miljöer, men det väcker också oro när tjänster blir otillgängliga, som hände med WSL1.

Förstå WSL2-nätverkskonfiguration, dess NAT- och speglade lägen, användningen av .wslconfig och wsl.conf, och hur de interagerar med brandväggar, VPN, Docker eller verktyg som Tailscale. Detta är nyckeln till att undvika huvudvärk. Låt oss steg för steg se hur hela den här installationen fungerar, hur man exponerar tjänster för Windows och LAN, vilka kommandon man ska använda för att få rätt IP-adresser och vilka avancerade konfigurationsalternativ du har för att finjustera din miljö, vilket gör den stabil och framför allt säker.

Hur nätverket faktiskt fungerar i WSL2

WSL2 delar inte längre värdnätverksstacken som WSL1Istället kör den varje Linuxdistribution i en liten virtuell maskin som hanteras av Hyper-V. Den virtuella maskinen har sin egen virtuella adapter (vanligtvis eth0) och en privat IP-adress som tilldelats av en intern virtuell switch.

I standardläget använder WSL2 en NAT-baserad arkitektur (Network Address Translation). Windows fungerar som router/värd, och Linuxdistributionen finns på ett privat subnät, vanligtvis inom intervallet. 172.16.0.0/12Detta subnät kan ändras efter omstarter eller WSL-omstarter, något som har gjort mer än en person galen när de konfigurerat statiska brandväggsregler.

Ur praktisk synvinkel betyder detta att din WSL2-distributions IP-adress varken är stabil eller direkt åtkomlig från nätverket. Precis som med WSL1: som standard finns det bara anslutning mellan Windows och WSL2 via omdirigeringsregler och NAT, och exponering för det lokala nätverket kräver extra steg eller användning av speglat läge.

Utöver denna basarkitektur lägger Windows 11 22H2 och senare versioner till nya nätverksfunktioner. (speglat läge, dnsTunneling, autoProxy, Hyper-V-brandvägg, etc.) som styrs från den globala filen .wslconfigmedan vissa alternativ i Linux hanteras med /etc/wsl.conf.

Identifiera IP-adresser i WSL2

Att arbeta med WSL2 innebär att tydligt skilja mellan två IP-scenarier: när du behöver IP-adressen för Linuxdistributionen och när du behöver IP-adressen för Windows-värden sett från Linux. Varje åtgärdas med ett annat kommando.

Scenario 1: Från Windows vill du veta IP-adressen för WSL2-distributionen För att tillåta att ett program på värden (till exempel en klient, webbläsare eller testverktyg) ansluter till en tjänst som körs i Linux. För att göra detta kan du köra följande kommandon i Windows (med CMD eller PowerShell):

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

Om du vill använda standarddistributionen kan du utelämna distributionsparametern. och bara ringa wsl.exe hostname -iI bakgrunden startas detta kommando i Linux hostname --ip-addresses och returnerar instansens IP-adress. Ett typiskt resultat kan se ut ungefär så här:

172.30.98.229

Scenario 2: Från Linux-distributionen behöver du veta IP-adressen för Windows-värdenTill exempel, för att ansluta en WSL2-applikation till en server som körs direkt på Windows (Node.js, SQL Server, Caddy, etc.). Inom Linux-skalet kan du använda:

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

Utdata kommer att vara standardgatewayen för den virtuella WSL2-servern., vilket motsvarar IP-adressen för Windows-värden sett från Linux, ungefär så här:

172.30.96.1

Det värdet (till exempel 172.30.96.1) är adressen som dina Linux-klienter ska peka till när du vill komma åt tjänster som körs på Windows-värden i klassiskt NAT-läge.

NAT-läge: standardbeteende för WSL2-nätverket

WSL2 fungerar direkt i NAT-läge, och för många enkla utvecklingsmiljöer är detta mer än tillräckligt.Det viktiga är att förstå vad som fungerar "på egen hand" och vad som inte gör det, för att inte slösa tid på att jaga spöken.

Åtkomst till Linux-tjänster från Windows med hjälp av localhostOm du kör en nätverksapplikation (till exempel en Node.js-server, en Flask-server, en SQL Server på Linux) på din WSL2-distribution kan du komma åt den från Windows med hjälp av localhost:puertoWindows vidarebefordrar automatiskt inkommande anslutningar till den interna IP-adressen för den virtuella WSL2-datorn.

Åtkomst till tjänster som körs på Windows från LinuxHär förändras saker och ting. För att nå en nätverksapplikation på värden (t.ex. en Node.js-server, SQL Server eller Caddy på Windows) från WSL2 måste du använda värdens IP-adress som den ses från Linux, erhållen med standardkommandot route:

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

Med den IP-adressen kan du ansluta från Linux till vilken tjänst som helst på värden., till exempel http://172.30.96.1:3000 om din Windows-server lyssnar på port 3000 på alla gränssnitt.

När du ansluter med fjärr-IP-adresser (inte localhost) ser program dem som LAN-anslutningar.Det här innebär att många servrar måste konfigureras för att lyssna på 0.0.0.0 istället för 127.0.0.1Till exempel, med Flask kan du starta:

app.run(host='0.0.0.0')

Denna förändring förbättrar tillgängligheten men kräver fokus på säkerhet.eftersom du tillåter anslutningar från ditt lokala nätverk, inte bara från själva datorn.

Åtkomst till WSL2 från det lokala nätverket (LAN) med hjälp av NAT

En av de mest irriterande förändringarna vid övergången från WSL1 till WSL2 är att distributioner inte längre är direkt tillgängliga från LAN:et.I WSL1, om ditt Windows var synligt på nätverket, ärvde distributionens tjänster den exponeringen nästan utan ansträngning.

I WSL2 har den virtuella maskinen sin egen privata IP-adress och annonseras inte automatiskt på LAN:et.För att uppnå något liknande det gamla beteendet måste du i NAT-läge skapa en portproxy i Windows, precis som du skulle göra med vilken virtuell Hyper-V-maskin som helst.

Windows innehåller ett klassiskt verktyg för detta: netsh interface portproxyEtt typiskt kommando för att omdirigera en värdport till WSL2 IP/port skulle vara:

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

I praktiken skulle du ersätta markörerna med specifika värden., till exempel:

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

Här listenaddress=0.0.0.0 Detta indikerar att Windows lyssnar på alla värdens IPv4-adresser.och vidarebefordrar det som kommer in via port 4000 till 192.168.101.100:4000vilket skulle vara WSL2 IP-adressen som erhålls med:

• wsl hostname -I Den ger dig IP-adressen till Linux-distributionen inuti den virtuella WSL2-servern.
• cat /etc/resolv.conf Den avslöjar IP-adressen för Windows Vista-värden från WSL2.

Med den här tekniken kan du göra en tjänst som körs på WSL2 tillgänglig från vilken dator som helst på nätverket.förutsatt att Windows-brandväggen tillåter det och du är säker på att du exponerar en tjänst från en virtuell dator, inte värden direkt.

IPv6 och moderna nätverksfunktioner

WSL2 kan också fungera med IPv6, vilket är särskilt relevant i moderna miljöer, VPN och företagsnätverk.För att hantera adresser är de grundläggande kommandona i Linux likvärdiga med de i IPv4:

• wsl hostname -i Från Windows för att visa IP-adressen för WSL2-distributionen
• ip route show | grep -i default | awk '{ print $3 }' från Linux för att hämta IP-adressen för Windows-värden

Där kvalitetssprånget i IPv6- och VPN-stöd verkligen märks är i speglat nätverksläge., tillgänglig i Windows 11 22H2 och senare versioner, vilket vi kommer att se mer i detalj senare.

Speglat nätverksläge: spegla Windows-gränssnitt i Linux

På datorer med Windows 11 22H2 eller senare kan du aktivera "speglat" nätverksläge. I WSL2 förändras modellen helt: istället för klassisk NAT "ser" Linux Windows nätverksgränssnitt reflekterade.

För att aktivera det måste du redigera filen .wslconfig av din användare, som är i %UserProfile%\.wslconfigFrån PowerShell med administratörsbehörighet kan du öppna den med:

notepad $env:USERPROFILE\.wslconfig

Inuti, lägg till (eller modifiera) avsnittet [wsl2] för att aktivera speglat läge:

[wsl2]
networkingMode=mirrored

När filen har sparats måste du starta om WSL2 för att den ska träda i kraft.Till exempel med:

wsl --shutdown

När du startar om det kommer WSL att använda den nya speglade nätverksarkitekturen.vilket medför flera mycket kraftfulla fördelar:

• Inbyggt IPv6-stöd och förbättrad integration med företagsnätverk och VPN:er
• Möjlighet att ansluta till Windows-tjänster från Linux med hjälp av 127.0.0.1 directamente (även om det inte är tillåtet) ::1 (t.ex. IPv6-loopback för detta)
• Förbättrat multicast-stöd inom Windows-Linux-integrationen
• Direktåtkomst till WSL från LAN utan behov av netsh portproxymed hjälp av IP-adressen för själva Windows-maskinen

Att aktivera det här läget löser många av de klassiska WSL2 NAT-problemen. och det är det rekommenderade alternativet i de flesta moderna utvecklings- och självhostingsmiljöer där du kan använda en uppdaterad version av Windows 11.

DNS-tunnling och användning av proxyservrar i WSL2

I Windows 11 22H2 och senare versioner har namnmatchningen från WSL2 också fått en betydande översyn.Nyckeln ligger i två funktioner som definieras i .wslconfig: dnsTunneling y autoProxy.

Alternativet dnsTunneling Den är aktiverad som standard i avsnittet [wsl2]. Detta gör att Linux DNS-förfrågningar kan hanteras via en virtualiseringsfunktion, istället för att skickas ut som vanliga nätverkspaket. Detta förbättrar kompatibiliteten med VPN och komplexa nätverkskonfigurationer på värden avsevärt.

För sin del, autoProxy=true tvingar WSL att använda Windows HTTP-proxyinställningarOm värden finns bakom en företags- eller säkerhetsproxy ärver WSL2 den automatiskt utan att du behöver brottas med miljövariabler manuellt.

Du kan till exempel ha något liknande i din .wslconfig:

[wsl2]
dnsTunneling=true
autoProxy=true

Detta säkerställer att WSL2-nätverket beter sig konsekvent med värdkonfigurationen., särskilt användbart i företag med strikta nätverks- och filtreringspolicyer.

Hyper-V-brandvägg och säker tjänsteexponering

I moderna miljöer passerar WSL2-nätverket också genom en dedikerad brandvägg.Från och med WSL 2.0.9 på Windows 11 22H2 är Hyper-V-brandväggsfunktionen aktiverad som standard, vilket lägger till ett extra filtreringslager för VM-trafik (inklusive WSL2-trafik).

Om du arbetar i speglat läge och vill permanent exponera WSL2-tjänster för LAN:et (till exempel API:er, dashboards eller egenhostingtjänster) måste du se till att brandväggsreglerna tillåter det.

En rimlig metod från PowerShell med administratörsbehörighet är att skapa en Hyper-V-regel för privata nätverk:

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

Om du av någon anledning vill inaktivera det specifika Hyper-V-skyddet (något mindre rekommenderat), kan du använda:

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

Tanken är att hålla brandväggen aktiv när det är möjligt.begränsa reglerna till privata nätverk och endast till de portar du verkligen behöver, och reservera all massdeaktivering som en sista utväg och alltid med sikte på att härda konfigurationen igen så snart allt fungerar.

WSL2-nätverksarkitektur, X11- och 172.16.0.0/12-intervall

Ett klassiskt fall som avslöjar detaljer om WSL2-nätverket är användningen av grafiska applikationer via X11Till exempel att starta Xming på Windows och skicka Linux-applikationer via DISPLAY.

När man uppgraderar från WSL1 till WSL2 upplever många användare att X slutar fungera. eftersom nätverket upphör att vara "delat" och blir ett virtuellt NAT-nätverk med intervall som 172.16.0.0/12vilket också kan ändras efter varje omstart av Windows eller WSL.

För att få X att fungera igen med Xming från WSL2 är det vanliga tricket att hämta Windows IP-adressen som Linux ser. använder sig av:

ENS

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

Parallellt är det nödvändigt att justera Windows-brandväggen för att tillåta X11-trafik från det NAT-subnätet.Ett typiskt tillvägagångssätt är att redigera Xming-regeln genom att lägga till intervallet 172.16.0.0/12 i TCP+UDP 6000.

Många inaktiverar Xming-autentisering med alternativet -acDetta "öppnar effektivt dörren" för alla klienter X som anländer från det nätverket. Det fungerar, men ur säkerhetssynpunkt är det ganska tveksamt, så det är värt att överväga mer begränsade lösningar eller att använda WSLg (integrerade GUI-applikationer) i Windows 11.

wsl.conf och .wslconfig: avancerad WSL2-konfiguration

WSL erbjuder två viktiga konfigurationsfiler som styr både den virtuella maskinens och varje distributions beteende.: /etc/wsl.conf (av distribution) och %UserProfile%\.wslconfig (globalt för alla WSL2-distributioner).

wsl.conf bor inom Linuxdistributionen, i /etc/wsl.confDen används för att konfigurera lokala alternativ för den distributionen: automatiska monteringar, generering av hosts y resolv.confinteroperabilitet med Windows, standardanvändare, systemd, etc.

.wslconfig Den sparas utanför Linux, i Windows användarprofil. (C:\Users\<Usuario>\.wslconfig) och styr globala parametrar för den virtuella maskin som driver WSL2: minne, processorer, kärna, nätverksläge, brandvägg, DNS, virtuell diskstorlek, GUI-stöd etc.

En märklig detalj är "8-sekundersregeln" när man ändrar inställningarNär du ändrar någon av dessa filer måste du se till att den virtuella WSL-maskinen är helt avstängd. Även om du stänger distributionsfönstret kan den finnas kvar i minnet i några sekunder.

För att tvinga fram en omstart av ett delsystem kan du använda:

• wsl --list --running för att kontrollera om det finns några aktiva distributioner
• wsl --shutdown att stänga alla distributioner på en gång
• wsl --terminate <distroName> att stoppa en specifik distro

Konfigurationsändringarna tillämpas endast när WSL stängs av och startas om.Något som många förbiser och tror att deras justeringar "inte fungerar".

Huvudalternativ för wsl.conf per sektion

Filen wsl.conf Det är inspirerat av det klassiska .ini-formatet, med sektioner och nycklarHuvudavsnitten är [automount], [network], [interop], [user], [boot], [gpu] y [time].

En [automount] Du styr hur Windows-enheter monteras i Linux (vanligtvis låg) /mnt):

• enabled (bool, standard sant)Om sant monteras C:/, D:/, etc. automatiskt i /mnt/c, /mnt/d.
• mountFsTab (bool)Om det är sant, bearbetas det /etc/fstab när du startar distributionen.
• root (kedja): rotkatalogen där enheterna kommer att monteras, till exempel /windir/ att ha /windir/c.
• options (kommaavgränsad lista)DrvFs-specifika parametrar som t.ex. metadata, uid, gid, umask, fmask, dmask o case.

DrvFs är filsystemet som överbryggar Windows och Linux., utformad för att komma åt NTFS från WSL med behörighetskontroll, metadata och skiftlägeskänslighet.

I avsnittet [network] Du justerar den automatiska genereringen av nätverksfiler:

• generateHostsOm sant genereras WSL automatiskt /etc/hosts.
• generateResolvConfOm sant skapar WSL /etc/resolv.conf med äldre DNS.
• hostname: värdnamn som distributionen kommer att använda.

avsnitt [interop] styr interoperabilitet med Windows:

• enabledAktiverar eller inaktiverar möjligheten att starta Windows-processer från WSL.
• appendWindowsPath: avgör om Windows-sökvägar ska läggas till $PATH Linux.

En [user] Du kan ange den användare som ska användas som standard när distributionen startas:

• default: användarnamn som kommer att startas som standard i WSL.

avsnitt [boot] Det är särskilt användbart i Windows 11 och Server 2022 för att automatiskt starta tjänster, såsom Docker inom WSL:

• command: kommandosträng som ska köras när WSL startas, till exempel service docker start.
• protectBinfmtskyddar genereringen av systemd-enheter när systemd är aktiverat.

Du har också avsnitt som [gpu] (aktivera åtkomst till Windows GPU från Linux), och [time] för att synkronisera tidszonen med WindowsDetta förhindrar problem när du byter till sommartid eller reser.

.wslconfig: WSL2 virtuell maskinkontroll

Medan wsl.conf finjusterar beteendet för varje distribution, låter .wslconfig dig finjustera den virtuella maskin som delas av alla WSL2-distributioner.Den här filen tas endast med i beräkningen av distributioner som körs som WSL2, inte WSL1.

Inom .wslconfig huvudavsnittet är [wsl2]där du definierar nyckelparametrar:

• kernel y kernelModulesabsoluta sökvägar från Windows till en anpassad Linuxkärna och dess moduler.
• memoryVM-minnesgräns (standard 50 % av värdens RAM), till exempel 4GB.
• processors: antal logiska processorer som är tilldelade den virtuella maskinen.
• localhostForwarding: gör att öppna portar i WSL2 kan nås från Windows med hjälp av localhost.
• swap y swapFilestorlek och sökväg för växlingsfilen för den virtuella datorn.
• guiApplicationsaktiverar eller inaktiverar stöd för grafiska applikationer (WSLg).
• dnsProxyNär du är i NAT-läge avgör den om Linux DNS-servern ska vara värdens NAT-instans eller en kopia av Windows DNS.
• networkingModeHär väljer du mellan none, nat, bridged (föråldrad), mirrored o virtioproxy.
• firewall, dnsTunneling y autoProxyalternativ vi har diskuterat för att bättre integrera WSL-nätverket med Windows-policyer.
• defaultVhdSize: maximal storlek på den virtuella hårddisken där distributionens filsystem lagras (standard 1 TB).

Det finns också en sektion [experimental] var funktioner aktiveras i testning som:

• autoMemoryReclaiminställningar för automatisk minnesåterställning (inaktiverad, gradvis, dropCache).
• sparseVhdskapande av glesa virtuella diskar för att spara utrymme.
• bestEffortDnsParsing y dnsTunnelingIpAddressfinjustering för DNS-tunnling.
• ignoredPorts: portar som Linux-appar kan använda även om de används på Windows när du är i speglat läge.
• hostAddressLoopbacktillåter värd och container att ansluta med hjälp av värdens lokala IP-adresser i speglat läge.

Att konfigurera .wslconfig korrekt gör skillnaden mellan en resurskrävande virtuell maskin och en optimerad miljö som fungerar bra med ditt Windows-system och nätverk.särskilt om du arbetar med tunga arbetsbelastningar, containrar eller flera samtidiga distributioner.

WSL2, Docker och nätverk för självhosting med Tailscale

Ett mycket praktiskt exempel är att använda WSL2 på Windows-servrar (även Windows Server 2025) som en självhostande plattform., som kombinerar Ubuntu på WSL2, Docker Engine (utan Docker Desktop), Tailscale och en omvänd proxy som Caddy för att exponera tjänster som n8n eller Supabase.

Tanken är att ha en stabil Docker-miljö inom WSL2, vilket undviker problemen med Docker Desktop på servrar.När man installerar Docker Engine direkt på Ubuntu (WSL2) förlitar sig containernätverket på WSL2-nätverket, vilket i sin tur beror på NAT eller speglat läge som definierats i .wslconfig.

Med Tailscale installerat på WSL2 kan du publicera dina tjänster på ett mesh-VPN. utan att öppna portar på routern, och använda Caddy som en omvänd proxy för att centralisera TLS-certifikat, rutter och lättviktig lastbalansering mellan containrar.

För att upprätthålla ett rent, förutsägbart och säkert nätverk är det lämpligt:

• Välj ett enda koherent nätverksläge (NAT eller speglat) och dokumentera det
• Undvik portkonflikter mellan Windows och WSL2, förlitar sig på ignoredPorts om du använder speglad
• Kontrollera tjänsteexponering endast via Tailscale eller Caddyistället för att öppna portar "som standard" i brandväggen
• Automatisera uppstarten av Docker, Tailscale och Caddy från [boot] i wsl.conf att ha en miljö närmare produktionen

Med denna arkitektur upphör WSL2 att bara vara ett utvecklingsverktyg och kan bli en ganska seriös självhostande plattform.förutsatt att du accepterar dess begränsningar (virtualisering över Hyper-V, ytterligare nätverkslager etc.) och konfigurerar den noggrant.

Bästa praxis för WSL2-nätverk för utveckling och testning

Förutom finjusteringen finns det ett antal riktlinjer som hjälper dig att arbeta bekvämt med WSL2-nätverket. utan att ständigt kämpa med IP-adresser, portar och brandväggar.

För utvecklingstjänster, använd höga portar (över 1024) och undvik privilegierade eller flitigt använda portar; detta minimerar konflikter och eliminerar behovet av extra privilegier.

Se till att koden och data finns i Linux-filsystemet. (du ~/ eller interna rutter) istället för att arbeta direkt på /mnt/ceftersom åtkomst till NTFS från WSL är långsammare och kan drabba I/O-intensiva tjänster.

Automatisera nätverksinställningar och omdirigeringsregler med skript I PowerShell och Bash: till exempel ett skript som konfigurerar WSL2 när det startar. netsh portproxy (om du fortsätter med NAT) eller kontrollera brandväggsreglerna när du använder spegling.

Undvik att förlita dig på att byta IP-adress genereras av den interna virtuella switchen. Arbeta när det är möjligt med localhost, värdnamn eller poster i /etc/hosts för dina tjänster, så att en IP-ändring inte förstör halva din testinfrastruktur.

I professionella eller semiproduktionsmiljöer är det bäst att inte blint förlita sig på WSL:s automatiska vidarebefordran.Konfigurera portar, proxyservrar och brandväggsregler explicit för att veta exakt vad som exponeras och var.

När det är korrekt konfigurerat erbjuder WSL2 ett isolerat men flexibelt nätverk, perfekt för avancerad utveckling, API-testning, arbete med containrar och simulering av distribuerade miljöer.Nyckeln är att behärska nätverkslägen (NAT vs. speglad), wsl.conf- och .wslconfig-filerna, och interaktionen med brandväggen och verktygen i din stack (Docker, Tailscale, omvända proxyservrar), så att Windows och Linux kan köras på samma maskin utan att överlappa portar eller kompromissa med säkerheten.