WSL2: Розширений посібник з налаштування мережі, NAT та режимів дзеркалювання

Informatec Digital » Ресурси » 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, отриману за допомогою команди default path:

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