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 можна використовувати:

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

Вихідним результатом буде шлюз за замовчуванням для віртуальної машини WSL2., що відповідає 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.

Доступ до служб, що працюють на 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), програми бачать їх як локальні з’єднання.Це означає, що багато серверів мають бути налаштовані на прослуховування 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Типова команда для перенаправлення порту хоста на IP/порт WSL2 буде такою:

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яка буде IP-адресою WSL2, отриманою за допомогою:

• wsl hostname -I Це надає вам IP-адресу дистрибутива Linux у віртуальній машині WSL2.
• 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 безпосередньо (хоча це не дозволено) ::1 (наприклад, зациклення IPv6 для цього)
• Покращена підтримка багатоадресної розсилки в рамках інтеграції 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. за допомогою:

ЕПЗ

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)Якщо це так, 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.

У межах .wslconfig основний розділ є [wsl2]де ви визначаєте ключові параметри:

• kernel y kernelModules: абсолютні шляхи від Windows до власного ядра Linux та його модулів.
• memoryНаприклад, обмеження пам'яті віртуальної машини (за замовчуванням 50% оперативної пам'яті хоста). 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: максимальний розмір віртуального жорсткого диска, на якому зберігається файлова система дистрибутива (за замовчуванням 1 ТБ).

Також є розділ [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 могли працювати на одній машині без перекриття портів або порушення безпеки.