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 и более поздние версии добавляют новые сетевые возможности. (зеркальный режим, DNS-туннелирование, автопрокси, брандмауэр 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, полученный с помощью команды route по умолчанию:

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 Чтобы просмотреть IP-адрес дистрибутива WSL2 в Windows, необходимо выполнить следующие действия.
• 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.

Включение этого режима решает многие классические проблемы NAT в WSL2. Это рекомендуемый вариант в большинстве современных сред разработки и самостоятельного размещения, где можно использовать обновленную версию Windows 11.

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

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

Выбор dnsTunneling Эта функция включена по умолчанию в разделе [wsl2]. Это позволяет обрабатывать DNS-запросы в Linux с помощью функции виртуализации, а не отправлять их в виде обычных сетевых пакетов. Это значительно улучшает совместимость с VPN и сложными сетевыми конфигурациями на хосте.

Со своей стороны, autoProxy=true заставляет WSL использовать настройки HTTP-прокси Windows.Если хост находится за корпоративным или защищенным прокси-сервером, 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)Если это так, то C:/, D:/ и т. д. автоматически монтируются в /mnt/c, /mnt/d...
• mountFsTab (булево)Если это правда, то это обрабатывается. /etc/fstab при запуске дистрибутива.
• root (цепь): корневой каталог, куда будут смонтированы диски, например /windir/ иметь /windir/c.
• options (список, разделённый запятыми): Параметры, специфичные для DrvFs, такие как 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: максимальный размер VHD-файла, на котором хранится файловая система дистрибутива (по умолчанию 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-адресами, портами и брандмауэрами.

Для разработки сервисов используйте порты с высоким 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 могли работать на одной машине без пересечения портов или компромиссов в отношении безопасности.