WSL2: Разширено ръководство за мрежова конфигурация и NAT и огледални режими

Информатек Дигитал » Ресурси » WSL2: Разширено ръководство за мрежова конфигурация и NAT и огледални режими

WSL2 напълно промени начина, по който Linux се интегрира с Windows , особено във всичко, свързано с мрежите: сега имаме лека виртуална машина със собствен мрежов стек, IP адрес и отделни правила за достъп. Това отваря много възможности за разработка, тестване, контейнери и самостоятелни среди за хостинг, но също така поражда опасения, когато услугите станат недостъпни, както беше при WSL1.

Разбирането на мрежовата конфигурация на WSL2, нейните NAT и огледални режими, използването на .wslconfig и wsl.conf и как те взаимодействат със защитни стени, VPN мрежи, Docker и инструменти като Tailscale е ключово за избягване на главоболия. Ще видим стъпка по стъпка как работи цялата тази настройка, как да се предоставят услуги на Windows и локалната мрежа, кои команди да се използват за получаване на правилните IP адреси и какви разширени опции за конфигурация имате, за да настроите фино вашата среда, правейки я стабилна и най-вече сигурна.

Как всъщност работи мрежата в WSL2

WSL2 вече не споделя мрежовия стек на хоста, както WSL1.Вместо това, всяка Linux дистрибуция се изпълнява в малка виртуална машина, управлявана от Hyper-V. Тази виртуална машина има свой собствен виртуален адаптер (обикновено eth0) и частен IP адрес, присвоен от вътрешен виртуален комутатор.

В режим по подразбиране, WSL2 използва NAT-базирана архитектура. (Превод на мрежови адреси). Windows действа като рутер/хост, а дистрибуцията на Linux се намира в частна подмрежа, обикновено в рамките на диапазона. 172.16.0.0/12Тази подмрежа може да се промени след рестартиране или рестартиране на WSL, нещо, което е подлудило не един човек при конфигурирането на правила за статична защитна стена.

От практическа гледна точка това означава, че IP адресът на вашата WSL2 дистрибуция не е стабилен или директно достъпен от локалната мрежа, както беше при WSL1: по подразбиране има само свързаност между Windows и WSL2 чрез правила за пренасочване и NAT, а достъпът до локалната мрежа изисква допълнителни стъпки или използване на огледален режим.

В допълнение към тази базова архитектура, Windows 11 22H2 и по-нови версии добавят нови мрежови възможности. (огледален режим, dnsTunneling, autoProxy, защитна стена на Hyper-V и др.), които се контролират от глобалния файл .wslconfigдокато някои опции в Linux се управляват с /etc/wsl.conf.

Идентифицирайте IP адреси в WSL2

Работата с WSL2 включва ясно разграничаване между два IP сценария : когато ви е необходим IP адресът на Linux дистрибуцията и когато ви е необходим IP адресът на Windows хоста, гледан от Linux. Всеки от тях се обработва с различна команда.

Сценарий 1: От Windows искате да знаете IP адреса на WSL2 дистрибуцията, така че приложение на хоста (например клиент, браузър или инструмент за тестване) да може да се свърже с услуга, работеща в Linux. За да направите това, можете да изпълните следните команди в Windows (CMD или PowerShell):

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

Ако искате да използвате дистрибуцията по подразбиране, можете да пропуснете параметъра distribution. и просто се обадете wsl.exe hostname -iВъв фонов режим тази команда се стартира в Linux hostname --ip-addresses и връща IP адреса на екземпляра. Типичен резултат може да изглежда по следния начин:

172.30.98.229

Сценарий 2: От Linux дистрибуцията трябва да знаете IP адреса на Windows хоста , например, за да може WSL2 приложение да се свърже със сървър, работещ директно на Windows (Node.js, SQL Server, Caddy и др.). В рамките на Linux shell можете да използвате:

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

Резултатът ще бъде шлюзът по подразбиране на WSL2 VM , който съответства на IP адреса на хоста на Windows, както се вижда от Linux, нещо подобно:

172.30.96.1

Тази стойност (например, 172.30.96.1) е адресът, към който вашите Linux клиенти трябва да сочат когато искате да получите достъп до услуги, работещи на хоста на Windows, докато сте в класически NAT режим.

NAT режим: поведение по подразбиране на WSL2 мрежата

Веднага след инсталирането си, WSL2 работи в NAT режим и за много прости среди за разработка това е повече от достатъчно . Важното е да разберете какво работи „самостоятелно“ и какво не, за да не губите време в преследване на „призраци“.

Достъп до Linux услуги от Windows чрез localhostАко стартирате мрежово приложение (например Node.js сървър, Flask сървър, SQL Server на Linux) на вашата WSL2 дистрибуция, можете да получите достъп до него от Windows, използвайки localhost:puertoWindows автоматично пренасочва входящите връзки към вътрешния IP адрес на WSL2 VM.

Достъп до услуги, работещи на Windows от Linux : нещата се променят тук. За да достигнете до мрежово приложение на хоста (като Node.js сървър, SQL Server или Caddy на Windows) от WSL2, трябва да използвате IP адреса на хоста, както се вижда от Linux, получен с командата за път по подразбиране:

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

С този IP адрес можете да се свържете от Linux към всяка услуга на хоста, например http://172.30.96.1:3000 ако вашият Windows сървър слуша на порт 3000 на всички интерфейси.

Когато се свързвате, използвайки отдалечени IP адреси (не localhost), приложенията ги виждат като LAN връзки.Това означава, че много сървъри трябва да бъдат конфигурирани да слушат 0.0.0.0 вместо 127.0.0.1Например, с Flask можете да стартирате:

app.run(host='0.0.0.0')

Тази промяна подобрява достъпността, но изисква внимателно внимание към сигурността , защото разрешавате връзки от локалната си мрежа, а не само от самото устройство.

Достъп до WSL2 от локалната мрежа (LAN) чрез NAT

Една от най-досадните промени при преминаване от WSL1 към WSL2 е, че дистрибуциите вече не са директно достъпни от локалната мрежа . В WSL1, ако вашата Windows система беше видима в мрежата, услугите на дистрибуцията наследяваха тази видимост почти без усилие.

В WSL2 виртуалната машина има собствен частен IP адрес и не се рекламира автоматично в локалната мрежа . За да постигнете нещо подобно на старото поведение, в NAT режим трябва да създадете прокси на порт в Windows, точно както бихте направили с всяка виртуална машина Hyper-V.

Windows включва класически инструмент за това: netsh interface portproxyТипична команда за пренасочване на хост порт към WSL2 IP/порт би била:

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

На практика бихте заменили маркерите със специфични стойности , например:

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

тук listenaddress=0.0.0.0 Това показва, че Windows ще слуша всички IPv4 адреси на хоста.и ще препрати това, което идва през порт 4000, към 192.168.101.100:4000който би бил WSL2 IP адресът, получен с:

• wsl hostname -I Това ви дава IP адреса на Linux дистрибуцията във WSL2 VM.
• cat /etc/resolv.conf Той разкрива IP адреса на хоста на Windows Vista от WSL2.

С тази техника можете да направите услуга, работеща на WSL2, достъпна от всеки компютър в локалната мрежа , стига защитната стена на Windows да го позволява и да сте наясно, че излагате на достъп услуга на виртуална машина, а не директно хоста.

IPv6 и съвременни мрежови функции

WSL2 може да работи и с IPv6, което е особено важно в съвременни среди, VPN и корпоративни мрежи . За управление на адреси, основните команди в Linux са еквивалентни на тези за IPv4:

• wsl hostname -i От Windows, за да видите IP адреса на WSL2 дистрибуцията
• ip route show | grep -i default | awk '{ print $3 }' от Linux, за да получите IP адреса на хоста на Windows

Истинският скок в качеството на поддръжката на IPv6 и VPN е в режима на огледална мрежа , наличен в Windows 11 22H2 и по-нови версии, който ще разгледаме подробно по-късно.

Режим на огледална мрежа: огледално копиране на интерфейси на Windows в Linux

На компютри с Windows 11 22H2 или по-нова версия можете да активирате „огледален“ мрежов режим в WSL2, което напълно променя модела: вместо класически NAT, Linux „вижда“ мрежовите интерфейси на Windows отразени.

За да го активирате, трябва да редактирате файла .wslconfig на вашия потребител, което е в %UserProfile%\.wslconfigОт PowerShell с администраторски права можете да го отворите с:

notepad $env:USERPROFILE\.wslconfig

Вътре добавете (или променете) секцията [wsl2], за да активирате огледален режим :

[wsl2]
networkingMode=mirrored

След като файлът е запазен, трябва да рестартирате WSL2, за да влезе в сила , например с:

wsl --shutdown

Когато го рестартирате, WSL ще използва новата огледална мрежова архитектура , която носи няколко мощни предимства:

• Вградена поддръжка на IPv6 и подобрена интеграция с корпоративни мрежи и VPN
• Възможност за свързване към услуги на Windows от Linux чрез 127.0.0.1 directamente (въпреки че не е позволено) ::1 (като например IPv6 loopback за това)
• Подобрена поддръжка на мултикаст в рамките на интеграцията Windows-Linux
• Директен достъп до WSL от локалната мрежа без нужда от netsh portproxyизползвайки IP адреса на самата машина с Windows

Активирането на този режим решава много от класическите проблеми с WSL2 NAT и е препоръчителната опция в повечето съвременни среди за разработка и самостоятелно хостване, където можете да използвате актуализиран Windows 11.

DNS тунелиране и използване на прокси сървъри в WSL2

В Windows 11 22H2 и по-нови версии, преобразуването на имена от WSL2 също е претърпяло значителен ремонт.Ключът се крие в две функционалности, дефинирани в .wslconfig: dnsTunneling y autoProxy.

Опцията dnsTunneling По подразбиране е активирано в секцията [wsl2]. Това позволява DNS заявките на Linux да се обработват чрез функция за виртуализация, вместо да се изпращат като нормални мрежови пакети. Това значително подобрява съвместимостта с VPN мрежи и сложни мрежови конфигурации на хоста.

От своя страна, autoProxy=true принуждава WSL да използва настройките на Windows HTTP прокси сървъраАко хостът е зад корпоративен или защитен прокси сървър, WSL2 автоматично го наследява, без да се налага ръчно да се борите с променливите на средата.

Може да имате например нещо подобно във вашия .wslconfig:

[wsl2]
dnsTunneling=true
autoProxy=true

Това гарантира, че WSL2 мрежата се държи съвместимо с конфигурацията на хоста , което е особено полезно в компании със строги мрежови и филтриращи политики.

Защитна стена на Hyper-V и излагане на защитени услуги

В съвременни среди WSL2 мрежата също преминава през специална защитна стена . Започвайки с WSL 2.0.9 на Windows 11 22H2, функцията за защитна стена Hyper-V е активирана по подразбиране, добавяйки допълнителен слой филтриране за трафика на виртуални машини (включително WSL2 трафик).

Ако работите в огледален режим и искате да предоставите постоянно WSL2 услуги на локалната мрежа (напр. API, табла за управление или услуги за самостоятелно хостване), трябва да се уверите, че правилата на защитната стена го позволяват.

Разумен подход от PowerShell с администраторски права е да се създаде правило за Hyper-V за частни мрежи :

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

Ако по някаква причина искате да деактивирате тази специфична Hyper-V защита (което е по-малко препоръчително), можете да използвате:

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

Идеята е защитната стена да се поддържа активна, когато е възможно , като се ограничават правилата до частни мрежи и само до портовете, от които наистина се нуждаете, а масовата деактивация се запазва като последна мярка и винаги с цел отново да се втвърди конфигурацията веднага щом всичко заработи.

WSL2 мрежова архитектура, X11 и 172.16.0.0/12 диапазони

Класически случай, който разкрива подробности за WSL2 мрежата, е използването на графични приложения чрез X11 , например стартиране на Xming на Windows и изпращане на Linux приложения чрез DISPLAY.

При надграждане от WSL1 към WSL2, много потребители установяват, че X спира да работи. защото мрежата престава да бъде „споделена“ и се превръща във виртуална NAT мрежа с диапазони като 172.16.0.0/12което може да се промени и след всяко рестартиране на Windows или WSL.

За да накарате X да работи отново с Xming от WSL2, обичайният трик е да получите IP адреса на Windows, който Linux вижда, използвайки:

ENS

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

Успоредно с това е необходимо да се настрои защитната стена на Windows, за да се разреши X11 трафик от тази NAT подмрежа.Типичен подход е да се редактира правилото Xming чрез добавяне на диапазона 172.16.0.0/12 в TCP+UDP 6000.

Много от тях в крайна сметка деактивират Xming удостоверяването с опцията -acТова ефективно „отваря вратата“ за всеки клиент X, пристигащ от тази мрежа. Работи, но от гледна точка на сигурността е доста съмнително, така че си струва да се обмислят по-ограничени решения или използване на WSLg (интегрирани графични приложения) в Windows 11.

wsl.conf и .wslconfig: разширена WSL2 конфигурация

WSL предлага два ключови конфигурационни файла, които контролират както поведението на виртуалната машина, така и това на всяка дистрибуция.: /etc/wsl.conf (от дистрибутор) и %UserProfile%\.wslconfig (глобално за всички WSL2 дистрибуции).

wsl.conf живее в рамките на Linux дистрибуцията, в /etc/wsl.confИзползва се за конфигуриране на локални опции за тази дистрибуция: автоматично монтиране, генериране на hosts y resolv.confсъвместимост с Windows, потребител по подразбиране, systemd и др.

.wslconfig Запазва се извън Linux, в потребителския профил на Windows. (C:\Users\<Usuario>\.wslconfig) и контролира глобалните параметри на виртуалната машина, която захранва WSL2: памет, процесори, ядро, мрежов режим, защитна стена, DNS, размер на виртуалния диск, поддръжка на графичен потребителски интерфейс и др.

Един интересен детайл е „правилото за 8 секунди“ при промяна на настройките : когато променяте някой от тези файлове, трябва да се уверите, че WSL виртуалната машина действително се изключва. Дори ако затворите прозореца на дистрибуцията, той може да остане в паметта за няколко секунди.

За да принудите рестартирането на подсистемата, можете да използвате :

• wsl --list --running за да проверите дали има активни дистрибуции
• wsl --shutdown да се затворят всички дистрибуции наведнъж
• wsl --terminate <distroName> да спрете конкретна дистрибуция

Едва когато WSL се изключи и рестартира, промените в конфигурацията действително се прилагат , нещо, което мнозина пренебрегват и смятат, че настройките им „не работят“.

Основни опции на wsl.conf по секции

Файлът wsl.conf Вдъхновен е от класическия .ini формат, със секции и ключовеОсновните раздели са [automount], [network], [interop], [user], [boot], [gpu] y [time].

En [automount] Вие контролирате как Windows дисковете се монтират в Linux (обикновено ниско) /mnt):

• enabled (булева стойност, по подразбиране true)Ако е true, C:/, D:/ и др. се монтират автоматично в /mnt/c, /mnt/d...
• mountFsTab (булева): ако е вярно, се обработва /etc/fstab при стартиране на дистрибуцията.
• root (верига): например главната директория, където ще бъдат монтирани устройствата /windir/ да има /windir/c.
• options (списък, разделен със запетаи)Специфични за DrvF параметри, като например metadata, uid, gid, umask, fmask, dmask o case.

DrvFs е мостовата файлова система между Windows и Linux , предназначена за достъп до NTFS от WSL с контрол на разрешенията, метаданни и чувствителност към малки и големи букви.

В раздела [network] Вие настройвате автоматичното генериране на мрежови файлове:

• generateHostsАко е вярно, WSL генерира автоматично /etc/hosts.
• generateResolvConfАко е вярно, WSL създава /etc/resolv.conf със стар DNS.
• hostname: име на хост, което дистрибуцията ще използва.

раздел [interop] контролира съвместимостта с Windows:

• enabled: Активира или деактивира възможността за стартиране на процеси на Windows от WSL.
• appendWindowsPath: решава дали да добави пътища на Windows към $PATH Linux.

En [user] Можете да укажете потребителя, който ще се използва по подразбиране при стартиране на дистрибуцията:

• default: потребителско име, което ще се стартира по подразбиране в WSL.

раздел [boot] Това е особено полезно в Windows 11 и Server 2022. за автоматично стартиране на услуги, като например Docker в WSL:

• command: команден низ за изпълнение при стартиране на WSL, например service docker start.
• protectBinfmt: защитава генерирането на systemd единици, когато systemd е активиран.

Имате и раздели като [gpu] (разрешаване на достъп до графичния процесор на Windows от Linux) и [time] синхронизиране на часовата зона с WindowsТова предотвратява проблеми при преминаване към лятно часово време или пътуване.

.wslconfig: WSL2 управление на виртуална машина

Докато wsl.conf настройва фино поведението на всяка дистрибуция, .wslconfig ви позволява да настройвате фино виртуалната машина, споделена от всички WSL2 дистрибуции . Този файл е приложим само за дистрибуции, работещи като WSL2, а не като WSL1.

Dentro de .wslconfig основният раздел е [wsl2]където дефинирате ключови параметри:

• kernel y kernelModules: абсолютни пътища от Windows до персонализирано Linux ядро ​​и неговите модули.
• memoryнапример ограничение на паметта на виртуалната машина (по подразбиране 50% от RAM паметта на хоста) 4GB.
• processors: брой логически процесори, присвоени на виртуалната машина.
• localhostForwarding: позволява достъп до отворените портове в WSL2 от Windows чрез localhost.
• swap y swapFile: размер и път до файла за суап за виртуалната машина.
• guiApplications: активира или деактивира поддръжката на графични приложения (WSLg).
• dnsProxyКогато сте в NAT режим, той решава дали DNS сървърът на Linux ще бъде NAT инстанция на хоста или копие на DNS сървъра на Windows.
• networkingModeТук избирате между none, nat, bridged (остарели), mirrored o virtioproxy.
• firewall, dnsTunneling y autoProxy: опции, които обсъдихме за по-добра интеграция на WSL мрежата с политиките на Windows.
• defaultVhdSize: максимален размер на VHD диска, където се съхранява файловата система на дистрибуцията (по подразбиране 1 TB).

Има и раздел [experimental] където функциите се активират при тестване като:

• autoMemoryReclaim: настройки за автоматично възстановяване на паметта (деактивирано, постепенно, dropCache).
• sparseVhdсъздаване на разредени виртуални дискове за пестене на място.
• bestEffortDnsParsing y dnsTunnelingIpAddressфина настройка за DNS тунелиране.
• ignoredPorts: портове, които Linux приложенията могат да използват, дори ако се използват в Windows, когато сте в огледален режим.
• hostAddressLoopback: позволява на хоста и контейнера да се свързват, използвайки локалните IP адреси на хоста в огледален режим.

Правилното конфигуриране на .wslconfig прави разликата между виртуална машина, която изразходва много ресурси, и оптимизирана среда, която работи добре с вашия Windows и мрежа , особено ако работите с големи натоварвания, контейнери или множество едновременни дистрибуции.

WSL2, Docker и работа в мрежа за самостоятелно хостване с Tailscale

Много практичен случай е използването на WSL2 на Windows сървъри (дори Windows Server 2025) като платформа за самостоятелно хостване , комбинирайки Ubuntu на WSL2, Docker Engine (без Docker Desktop), Tailscale и обратен прокси като Caddy, за да се разкрият услуги като n8n или Supabase.

Целта е да се постигне стабилна Docker среда в рамките на WSL2, като се избегнат проблемите на Docker Desktop на сървъри . Чрез инсталиране на Docker Engine директно на Ubuntu (WSL2), мрежата от контейнери разчита на WSL2 мрежата, която от своя страна зависи от NAT или огледалния режим, дефиниран в .wslconfig.

С инсталиран Tailscale на WSL2, можете да публикувате услугите си в mesh VPN, без да отваряте портове на рутера, и да използвате Caddy като обратен прокси, за да централизирате TLS сертификати, маршрути и леко балансиране на натоварването между контейнерите.

За да поддържате чиста, предвидима и сигурна мрежа, е препоръчително да :

• Изберете един кохерентен мрежов режим (NAT или огледален) и го документирайте
• Избягвайте конфликти на портове между Windows и WSL2, разчитайки на ignoredPorts ако използвате огледално
• Контролирайте експозицията на услугата само чрез Tailscale или Caddyвместо да отварят портове „по подразбиране“ в защитната стена
• Автоматизирайте стартирането на Docker, Tailscale и Caddy от [boot] в wsl.conf да има среда, по-близка до производствената

С тази архитектура, WSL2 престава да бъде просто инструмент за разработка и може да се превърне в доста сериозна платформа за самостоятелно хостване , стига да приемете ограниченията ѝ (виртуализация върху Hyper-V, допълнителен мрежов слой и др.) и да я конфигурирате внимателно.

Най-добри практики за WSL2 мрежи за разработка и тестване

Освен фината настройка, има редица насоки, които ви помагат да работите комфортно с WSL2 мрежата, без постоянно да се борите с IP адреси, портове и защитни стени.

За услуги за разработка използвайте високи портове (над 1024) и избягвайте привилегировани или силно използвани системни портове; това минимизира конфликтите и елиминира необходимостта от допълнителни привилегии.

Уверете се, че кодът и данните се намират във файловата система на Linux. (ТУ ~/ или вътрешни маршрути) вместо да работите директно върху /mnt/cзащото достъпът до NTFS от WSL е по-бавен и може да навреди на услугите с интензивен вход/изход.

Автоматизирайте мрежовите настройки и правилата за пренасочване със скриптове В PowerShell и Bash: например, скрипт, който конфигурира WSL2 при стартирането му. netsh portproxy (ако продължавате с NAT) или проверете правилата на защитната стена, когато използвате огледално излъчване.

Избягвайте да разчитате на смяна на IP адреси генерирани от вътрешния виртуален комутатор. Винаги, когато е възможно, работете с localhost, имена на хостове или записи в /etc/hosts за вашите услуги, така че промяната на IP адреса да не наруши половината от вашата тестова инфраструктура.

В професионални или полупроизводствени среди е най-добре да не се разчита сляпо на автоматичното пренасочване на WSL . Конфигурирайте изрично портове, прокси сървъри и правила за защитна стена, за да знаете точно какво е изложено на риск и къде.

Когато е правилно конфигуриран, WSL2 предлага изолирана, но гъвкава мрежа, идеална за напреднала разработка, API тестване, работа с контейнери и симулиране на разпределени среди . Ключът се крие в овладяването на мрежовите режими (NAT срещу огледален режим), файловете wsl.conf и .wslconfig и взаимодействието с вашата защитна стена и инструментите във вашия стек (Docker, Tailscale, обратни прокси сървъри), така че Windows и Linux да могат да работят на една и съща машина без конфликти на портове или компрометиране на сигурността.