WSL2: Avansert veiledning til nettverkskonfigurasjon og NAT og speilede moduser

Informatec Digital » Ressurser » WSL2: Avansert veiledning til nettverkskonfigurasjon og NAT og speilede moduser

WSL2 har fullstendig endret måten Linux integreres med Windows påSpesielt i alt som har med nettverket å gjøre: Vi har nå en lett virtuell maskin med sin egen nettverksstabel, sin egen IP-adresse og separate tilgangsregler. Dette åpner opp mange muligheter for utvikling, testing, containere og selvhostingsmiljøer, men det reiser også bekymring når tjenester blir utilgjengelige, slik det skjedde med WSL1.

Forstå WSL2-nettverkskonfigurasjon, NAT- og speilemoduser, bruk av .wslconfig og wsl.conf, og hvordan de samhandler med brannmurer, VPN-er, Docker eller verktøy som Tailscale Dette er nøkkelen til å unngå hodebry. La oss se trinn for trinn hvordan hele dette oppsettet fungerer, hvordan du eksponerer tjenester for Windows og LAN, hvilke kommandoer du skal bruke for å få de riktige IP-adressene, og hvilke avanserte konfigurasjonsalternativer du har for å finjustere miljøet ditt, slik at det blir stabilt og fremfor alt sikkert.

Hvordan nettverket faktisk fungerer i WSL2

WSL2 deler ikke lenger vertsnettverksstakken slik som WSL1I stedet kjører den hver Linux-distribusjon i en liten virtuell maskin som administreres av Hyper-V. Den virtuelle maskinen har sin egen virtuelle adapter (vanligvis eth0) og en privat IP-adresse tilordnet av en intern virtuell svitsj.

I standardmodus bruker WSL2 en NAT-basert arkitektur (Network Address Translation). Windows fungerer som ruter/vert, og Linux-distribusjonen ligger på et privat delnett, vanligvis innenfor området. 172.16.0.0/12Dette delnettet kan endres etter omstart eller omstart av WSL, noe som har drevet mer enn én person til vanvidd når de konfigurerer statiske brannmurregler.

Fra et praktisk synspunkt betyr dette at IP-adressen til WSL2-distribusjonen din verken er stabil eller direkte tilgjengelig fra lokalnettverket. Som med WSL1: som standard er det bare tilkobling mellom Windows og WSL2 via omdirigeringsregler og NAT, og eksponering for det lokale nettverket krever ekstra trinn eller bruk av speilet modus.

I tillegg til denne basisarkitekturen legger Windows 11 22H2 og senere versjoner til nye nettverksfunksjoner. (speilet modus, dnsTunneling, autoProxy, Hyper-V-brannmur osv.) som styres fra den globale filen .wslconfigmens visse alternativer i Linux administreres med /etc/wsl.conf.

Identifiser IP-adresser i WSL2

Å jobbe med WSL2 innebærer å tydelig skille mellom to IP-scenarier: når du trenger IP-adressen til Linux-distribusjonen og når du trenger IP-adressen til Windows-verten sett fra Linux. Hver av dem løses med en annen kommando.

Scenario 1: Fra Windows vil du vite IP-adressen til WSL2-distribusjonen For å tillate at et program på verten (for eksempel en klient, nettleser eller testverktøy) kobler seg til en tjeneste som kjører i Linux. For å gjøre dette kan du kjøre følgende kommandoer i Windows (ved hjelp av CMD eller PowerShell):

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

Hvis du vil bruke standarddistroen, kan du utelate distribusjonsparameteren. og bare ring wsl.exe hostname -iI bakgrunnen starter denne kommandoen i Linux hostname --ip-addresses og returnerer instansens IP-adresse. Et typisk resultat kan se omtrent slik ut:

172.30.98.229

Scenario 2: Fra Linux-distribusjonen må du vite IP-adressen til Windows-vertenFor eksempel, for å koble en WSL2-applikasjon til en server som kjører innebygd på Windows (Node.js, SQL Server, Caddy, osv.). Innenfor Linux-skallet kan du bruke:

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

Utdataene vil være standardgatewayen til den virtuelle WSL2-maskinen., som tilsvarer IP-adressen til Windows-verten sett fra Linux, noe sånt som:

172.30.96.1

Den verdien (for eksempel 172.30.96.1) er adressen som Linux-klientene dine skal peke til når du vil ha tilgang til tjenester som kjører på Windows-verten mens du er i klassisk NAT-modus.

NAT-modus: standardoppførsel for WSL2-nettverket

WSL2 fungerer i NAT-modus rett ut av esken, og for mange enkle utviklingsmiljøer er dette mer enn tilstrekkelig.Det viktigste er å forstå hva som fungerer «på egenhånd» og hva som ikke fungerer, for ikke å kaste bort tid på å jage spøkelser.

Tilgang til Linux-tjenester fra Windows ved hjelp av localhostHvis du kjører et nettverksprogram (for eksempel en Node.js-server, en Flask-server, en SQL Server på Linux) på WSL2-distribusjonen din, kan du få tilgang til det fra Windows ved hjelp av localhost:puertoWindows videresender automatisk innkommende tilkoblinger til den interne IP-adressen til den virtuelle WSL2-maskinen.

Tilgang til tjenester som kjører på Windows fra LinuxDet er her ting endrer seg. For å nå et nettverksprogram på verten (for eksempel en Node.js-server, SQL Server eller Caddy på Windows) fra WSL2, må du bruke vertens IP-adresse slik den vises i Linux, hentet med standard rutekommando:

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

Med den IP-adressen kan du koble fra Linux til hvilken som helst tjeneste på vertenfor eksempel http://172.30.96.1:3000 hvis Windows-serveren din lytter på port 3000 på alle grensesnitt.

Når du kobler til ved hjelp av eksterne IP-adresser (ikke localhost), ser applikasjoner dem som LAN-tilkoblinger.Dette betyr at mange servere må konfigureres til å lytte på 0.0.0.0 i stedet for 127.0.0.1For eksempel, med Flask kan du starte:

app.run(host='0.0.0.0')

Denne endringen forbedrer tilgjengeligheten, men krever fokus på sikkerhet.fordi du tillater tilkoblinger fra ditt lokale nettverk, ikke bare fra selve datamaskinen.

Tilgang til WSL2 fra det lokale nettverket (LAN) ved hjelp av NAT

En av de mest irriterende endringene ved overgangen fra WSL1 til WSL2 er at distribusjoner ikke lenger er direkte tilgjengelige fra LAN-et.I WSL1, hvis Windows-en din var synlig på nettverket, arvet distribusjonens tjenester den eksponeringen nesten uanstrengt.

I WSL2 har den virtuelle maskinen sin egen private IP-adresse og annonseres ikke automatisk på LAN-et.For å oppnå noe som ligner på den gamle oppførselen, må du i NAT-modus opprette en portproxy i Windows, slik du ville gjort med en hvilken som helst virtuell Hyper-V-maskin.

Windows inneholder et klassisk verktøy for dette: netsh interface portproxyEn typisk kommando for å omdirigere en vertsport til WSL2 IP/port ville være:

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

I praksis ville du erstatte markørene med spesifikke verdier., for eksempel:

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

Her listenaddress=0.0.0.0 Dette indikerer at Windows vil lytte på alle IPv4-adressene til verten.og vil videresende det som kommer inn gjennom port 4000 til 192.168.101.100:4000som ville være WSL2 IP-adressen som ble oppnådd med:

• wsl hostname -I Den gir deg IP-adressen til Linux-distribusjonen i WSL2 VM
• cat /etc/resolv.conf Den avslører IP-adressen til Windows Vista-verten fra WSL2.

Med denne teknikken kan du gjøre en tjeneste som kjører på WSL2 tilgjengelig fra hvilken som helst datamaskin på LAN-et.forutsatt at Windows-brannmuren tillater det, og du er sikker på at du eksponerer en tjeneste til en virtuell maskin, ikke direkte til verten.

IPv6 og moderne nettverksfunksjoner

WSL2 kan også fungere med IPv6, noe som er spesielt relevant i moderne miljøer, VPN-er og bedriftsnettverk.For å håndtere adresser er de grunnleggende kommandoene i Linux tilsvarende de i IPv4:

• wsl hostname -i Fra Windows for å vise IP-adressen til WSL2-distribusjonen
• ip route show | grep -i default | awk '{ print $3 }' fra Linux for å hente IP-adressen til Windows-verten

Der kvalitetsspranget i IPv6- og VPN-støtte virkelig er merkbart, er i speilet nettverksmodus., tilgjengelig i Windows 11 22H2 og senere versjoner, som vi skal se mer detaljert på senere.

Speilet nettverksmodus: speiling av Windows-grensesnitt i Linux

På datamaskiner med Windows 11 22H2 eller høyere kan du aktivere «speilet» nettverksmodus. I WSL2 endres modellen fullstendig: i stedet for klassisk NAT, «ser» Linux Windows-nettverksgrensesnittene reflektert.

For å aktivere det, må du redigere filen .wslconfig av brukeren din, som er i %UserProfile%\.wslconfigFra PowerShell med administratorrettigheter kan du åpne den med:

notepad $env:USERPROFILE\.wslconfig

Inni, legg til (eller endre) [wsl2]-delen for å aktivere speilet modus:

[wsl2]
networkingMode=mirrored

Når filen er lagret, må du starte WSL2 på nytt for at den skal tre i kraft.For eksempel med:

wsl --shutdown

Når du starter den på nytt, vil WSL bruke den nye speilede nettverksarkitekturen.som gir flere svært kraftige fordeler:

• Innebygd IPv6-støtte og forbedret integrasjon med bedriftsnettverk og VPN-er
• Mulighet for å koble til Windows-tjenester fra Linux ved hjelp av 127.0.0.1 directamente (selv om det ikke er tillatt) ::1 (som for eksempel IPv6-loopback for dette)
• Forbedret multicast-støtte i Windows-Linux-integrasjonen
• Direkte tilgang til WSL fra LAN uten behov for netsh portproxybruker IP-adressen til selve Windows-maskinen

Å aktivere denne modusen løser mange av de klassiske WSL2 NAT-problemene og det er det anbefalte alternativet i de fleste moderne utviklings- og selvhostingsmiljøer der du kan bruke en oppdatert versjon av Windows 11.

DNS-tunneling og bruk av proxyer i WSL2

I Windows 11 22H2 og senere versjoner har navneløsningen fra WSL2 også fått en betydelig overhaling.Nøkkelen ligger i to funksjoner definert i .wslconfig: dnsTunneling y autoProxy.

Alternativet dnsTunneling Den er aktivert som standard i [wsl2]-delen. Dette gjør at Linux DNS-forespørsler kan håndteres gjennom en virtualiseringsfunksjon, i stedet for å bli sendt ut som vanlige nettverkspakker. Dette forbedrer kompatibiliteten med VPN-er og komplekse nettverkskonfigurasjoner på verten betraktelig.

For sin del, autoProxy=true tvinger WSL til å bruke Windows HTTP-proxyinnstillingeneHvis verten står bak en bedrifts- eller sikkerhetsproxy, arver WSL2 den automatisk uten at du trenger å slite med miljøvariabler manuelt.

Du kunne for eksempel ha noe sånt i din .wslconfig:

[wsl2]
dnsTunneling=true
autoProxy=true

Dette sikrer at WSL2-nettverket oppfører seg konsekvent med vertskonfigurasjonen., spesielt nyttig i selskaper med strenge nettverks- og filtreringsregler.

Hyper-V-brannmur og eksponering for sikker tjeneste

I moderne miljøer går WSL2-nettverket også gjennom en dedikert brannmur.Fra og med WSL 2.0.9 på Windows 11 22H2 er Hyper-V-brannmurfunksjonen aktivert som standard, noe som legger til et ekstra lag med filtrering for VM-trafikk (inkludert WSL2-trafikk).

Hvis du jobber i speilet modus og ønsker å eksponere WSL2-tjenester permanent til LAN-et (for eksempel API-er, dashbord eller selvhostingstjenester), må du sørge for at brannmurreglene tillater det.

En rimelig tilnærming fra PowerShell med administratorrettigheter er å opprette en Hyper-V-regel for private nettverk:

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

Hvis du av en eller annen grunn vil deaktivere den spesifikke Hyper-V-beskyttelsen (noe mindre anbefalt), kan du bruke:

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

Tanken er å holde brannmuren aktiv når det er mulig.å begrense regler til private nettverk og kun til portene du virkelig trenger, og reservere all massedeaktivering som en siste utvei og alltid med sikte på å herde konfigurasjonen igjen så snart alt fungerer.

WSL2-nettverksarkitektur, X11- og 172.16.0.0/12-områder

Et klassisk tilfelle som avslører detaljer om WSL2-nettverket er bruken av grafiske applikasjoner via X11For eksempel å starte Xming på Windows og sende Linux-applikasjoner via DISPLAY.

Når man oppgraderer fra WSL1 til WSL2, opplever mange brukere at X slutter å virke. fordi nettverket slutter å være "delt" og blir et virtuelt NAT-nettverk med områder som 172.16.0.0/12som også kan endres etter hver omstart av Windows eller WSL.

For å få X til å fungere igjen med Xming fra WSL2, er det vanlige trikset å hente Windows IP-adressen som Linux ser. ved hjelp av:

ens

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

Parallelt er det nødvendig å justere Windows-brannmuren for å tillate X11-trafikk fra det NAT-undernettet.En typisk tilnærming er å redigere Xming-regelen ved å legge til området 172.16.0.0/12 i TCP+UDP 6000.

Mange ender opp med å deaktivere Xming-autentisering med alternativet -acDette «åpner effektivt døren» for enhver klient X som kommer fra det nettverket. Det fungerer, men fra et sikkerhetssynspunkt er det ganske tvilsomt, så det er verdt å vurdere mer begrensede løsninger eller bruke WSLg (integrerte GUI-applikasjoner) i Windows 11.

wsl.conf og .wslconfig: avansert WSL2-konfigurasjon

WSL tilbyr to viktige konfigurasjonsfiler som kontrollerer både virkemåten til den virtuelle maskinen og virkemåten til hver distribusjon.: /etc/wsl.conf (av distro) og %UserProfile%\.wslconfig (globalt for alle WSL2-distribusjoner).

wsl.conf bor i Linux-distribusjonen, i /etc/wsl.confDen brukes til å konfigurere lokale alternativer for den distroen: automatiske monteringer, generering av hosts y resolv.confinteroperabilitet med Windows, standardbruker, systemd osv.

.wslconfig Den lagres utenfor Linux, i Windows-brukerprofilen. (C:\Users\<Usuario>\.wslconfig) og kontrollerer globale parametere for den virtuelle maskinen som driver WSL2: minne, CPUer, kjerne, nettverksmodus, brannmur, DNS, størrelse på virtuell disk, GUI-støtte osv.

En merkelig detalj er «8-sekundersregelen» når man endrer innstillinger.Når du endrer noen av disse filene, må du sørge for at WSL VM er helt avslått. Selv om du lukker distrovinduet, kan den forbli i minnet i noen sekunder.

For å tvinge frem en omstart av et delsystem kan du bruke:

• wsl --list --running for å sjekke om det finnes noen aktive distroer
• wsl --shutdown å lukke alle distribusjoner samtidig
• wsl --terminate <distroName> å stoppe en spesifikk distro

Konfigurasjonsendringene trer bare i kraft når WSL slås av og startes på nytt.Noe som mange overser og tror at justeringene deres «ikke fungerer».

Hovedvalg for wsl.conf etter seksjon

Filen wsl.conf Den er inspirert av det klassiske .ini-formatet, med seksjoner og nøklerHovedseksjonene er [automount], [network], [interop], [user], [boot], [gpu] y [time].

En [automount] Du kontrollerer hvordan Windows-disker monteres i Linux (vanligvis lav) /mnt):

• enabled (bool, standard sann)Hvis sant, monteres C:/, D:/ osv. automatisk i /mnt/c, /mnt/d...
• mountFsTab (bool): hvis det er sant, blir det behandlet /etc/fstab når du starter distroen.
• root (kjede): rotkatalogen der stasjonene skal monteres, for eksempel /windir/ å ha /windir/c.
• options (kommaseparert liste)DrvFs-spesifikke parametere som metadata, uid, gid, umask, fmask, dmask o case.

DrvFs er filsystemet som bygger bro mellom Windows og Linux., designet for å få tilgang til NTFS fra WSL med tillatelseskontroll, metadata og forskjell på store og små bokstaver.

I seksjonen [network] Du justerer den automatiske genereringen av nettverksfiler:

• generateHostsHvis sant, genereres WSL automatisk /etc/hosts.
• generateResolvConfHvis sant, oppretter WSL /etc/resolv.conf med eldre DNS.
• hostnamevertsnavnet som distribusjonen vil bruke.

seksjon [interop] kontrollerer interoperabilitet med Windows:

• enabledAktiverer eller deaktiverer muligheten til å starte Windows-prosesser fra WSL.
• appendWindowsPath: bestemmer om Windows-stier skal legges til $PATH Linux.

En [user] Du kan angi brukeren som skal brukes som standard når du starter distroen:

• defaultbrukernavn som startes som standard i WSL.

seksjon [boot] Det er spesielt nyttig i Windows 11 og Server 2022 for å automatisk starte tjenester, som Docker i WSL:

• command: kommandostreng som skal kjøres når WSL startes, for eksempel service docker start.
• protectBinfmt: beskytter genereringen av systemd-enheter når systemd er aktivert.

Du har også seksjoner som [gpu] (aktiver tilgang til Windows GPU fra Linux), og [time] for å synkronisere tidssonen med WindowsDette forhindrer problemer når du bytter til sommertid eller reiser.

.wslconfig: WSL2 virtuell maskinkontroll

Mens wsl.conf finjusterer oppførselen til hver distro, lar .wslconfig deg finjustere den virtuelle maskinen som deles av alle WSL2-distribusjoner.Denne filen tas kun med i betraktningen av distribusjoner som kjører som WSL2, ikke WSL1.

Innenfor .wslconfig hoveddelen er [wsl2]der du definerer nøkkelparametere:

• kernel y kernelModulesabsolutte stier fra Windows til en tilpasset Linux-kjerne og dens moduler.
• memoryVM-minnegrense (standard 50 % av verts-RAM), for eksempel 4GB.
• processorsantall logiske prosessorer som er tilordnet den virtuelle maskinen.
• localhostForwarding: tillater at åpne porter i WSL2 er tilgjengelige fra Windows ved hjelp av localhost.
• swap y swapFilestørrelse og bane til vekslingsfilen for den virtuelle maskinen.
• guiApplications: aktiverer eller deaktiverer støtte for GUI-applikasjoner (WSLg).
• dnsProxyNår du er i NAT-modus, avgjør den om Linux DNS-serveren skal være vertens NAT-instans eller en kopi av Windows DNS.
• networkingModeHer velger du mellom none, nat, bridged (foreldet), mirrored o virtioproxy.
• firewall, dnsTunneling y autoProxy: alternativer vi har diskutert for å bedre integrere WSL-nettverket med Windows-policyer.
• defaultVhdSize: maksimal størrelse på VHD-en der distribusjonens filsystem er lagret (standard 1 TB).

Det er også en seksjon [experimental] hvor funksjoner aktiveres i testing som:

• autoMemoryReclaim: innstillinger for automatisk minnegjenoppretting (deaktivert, gradvis, dropCache).
• sparseVhd: opprettelse av sparsomme virtuelle disker for å spare plass.
• bestEffortDnsParsing y dnsTunnelingIpAddressfinjustering for DNS-tunneling.
• ignoredPorts: porter som Linux-apper kan bruke selv om de er i bruk på Windows når du er i speilet modus.
• hostAddressLoopbacklar vert og container koble seg til ved hjelp av lokale IP-adresser til verten i speilet modus.

Riktig konfigurering av .wslconfig utgjør forskjellen mellom en ressurskrevende virtuell maskin og et optimalisert miljø som fungerer bra med Windows-systemet og nettverket ditt.spesielt hvis du jobber med tunge arbeidsmengder, containere eller flere samtidige distroer.

WSL2, Docker og nettverk for selvhosting med Tailscale

Et veldig praktisk eksempel er å bruke WSL2 på Windows-servere (til og med Windows Server 2025) som en selvhostingsplattform., som kombinerer Ubuntu på WSL2, Docker Engine (uten Docker Desktop), Tailscale og en omvendt proxy som Caddy for å eksponere tjenester som n8n eller Supabase.

Tanken er å ha et stabilt Docker-miljø i WSL2, og dermed unngå problemene med Docker Desktop på servere.Når du installerer Docker Engine direkte på Ubuntu (WSL2), er containernettverket avhengig av WSL2-nettverket, som igjen avhenger av NAT- eller speilmodusen som er definert i .wslconfig.

Med Tailscale installert på WSL2 kan du publisere tjenestene dine på et mesh-VPN. uten å åpne porter på ruteren, og bruke Caddy som en omvendt proxy for å sentralisere TLS-sertifikater, ruter og lettvektsbelastningsfordeling mellom containere.

For å opprettholde et rent, forutsigbart og sikkert nettverk, er det tilrådelig:

• Velg en enkelt koherent nettverksmodus (NAT eller speilet) og dokumenter den
• Unngå portkonflikter mellom Windows og WSL2, avhengig av ignoredPorts hvis du bruker speilvendt
• Kontroller tjenesteeksponering kun via Tailscale eller Caddyi stedet for å åpne porter "som standard" i brannmuren
• Automatiser oppstarten av Docker, Tailscale og Caddy fra [boot] i wsl.conf å ha et miljø nærmere produksjonen

Med denne arkitekturen slutter WSL2 å bare være et utviklingsverktøy og kan bli en ganske seriøs selvhostingsplattform.forutsatt at du aksepterer begrensningene (virtualisering over Hyper-V, ekstra nettverkslag osv.) og konfigurerer det nøye.

Beste praksis for WSL2-nettverk for utvikling og testing

Bortsett fra finjusteringen, finnes det en rekke retningslinjer som hjelper deg å jobbe komfortabelt med WSL2-nettverket. uten å stadig vekk kjempe med IP-adresser, porter og brannmurer.

For utviklingstjenester, bruk høye porter (over 1024) og unngå privilegerte eller mye brukte porter; dette minimerer konflikter og eliminerer behovet for ekstra rettigheter.

Sørg for at koden og dataene ligger i Linux-filsystemet. (du ~/ eller interne ruter) i stedet for å jobbe direkte på /mnt/cfordi tilgang til NTFS fra WSL er tregere og kan straffe I/O-intensive tjenester.

Automatiser nettverksinnstillinger og omdirigeringsregler med skript I PowerShell og Bash: for eksempel et skript som konfigurerer WSL2 når det starter. netsh portproxy (hvis du fortsetter med NAT) eller sjekk brannmurreglene når du bruker speiling.

Unngå å stole på å endre IP-adresser generert av den interne virtuelle bryteren. Når det er mulig, arbeid med localhost, vertsnavn eller oppføringer i /etc/hosts for tjenestene dine, slik at en IP-endring ikke ødelegger halve testinfrastrukturen din.

I profesjonelle eller semiproduksjonsmiljøer er det best å ikke blindt stole på WSLs automatiske videresending.Konfigurer eksplisitt porter, proxyer og brannmurregler for å vite nøyaktig hva som er eksponert og hvor.

Når det er riktig konfigurert, tilbyr WSL2 et isolert, men fleksibelt nettverk, perfekt for avansert utvikling, API-testing, arbeid med containere og simulering av distribuerte miljøer.Nøkkelen er å mestre nettverksmoduser (NAT vs. speilet), wsl.conf- og .wslconfig-filene, og samhandlingen med brannmuren og verktøyene i stacken din (Docker, Tailscale, reverse proxyer), slik at Windows og Linux kan kjøre på samme maskin uten overlappende porter eller kompromisser med sikkerheten.