Доступ к сетевым приложениям с помощью WSL

При работе с сетевыми приложениями и WSL следует учитывать несколько соображений. По умолчанию WSL использует архитектуру на основе NAT, и мы рекомендуем попробовать новый режим зеркальной сети, чтобы получить последние функции и улучшения.

Определение IP-адреса

Существует два сценария, которые следует учитывать при определении IP-адреса, используемого для дистрибутива Linux, работающего через WSL:

Сценарий один. С точки зрения узла Windows необходимо запросить IP-адрес дистрибутива Linux, работающий через WSL2, чтобы программа на узле Windows может подключаться к серверной программе, работающей внутри дистрибутива (экземпляра).

Узел Windows может использовать команду:

wsl -d <DistributionName> hostname -I

При запросе распределения по умолчанию эта часть команды, назначающая распределение, может быть опущена: -d <DistributionName> Не забудьте использовать флаг заглавной буквы -I , а не нижний регистр -i.

В режиме капюшона команда узла wsl.exe запускает целевой экземпляр и выполняет команду hostname -ILinux. Затем эта команда выводит IP-адрес экземпляра STDOUTWSL в . Затем текстовое STDOUT содержимое передается обратно в wsl.exe. Наконец, wsl.exe отображает выходные данные в командной строке.

Типичные выходные данные могут быть:

172.30.98.229

Сценарий Два. Программа, запущенная внутри дистрибутива Linux через WSL2 (экземпляр), хочет знать IP-адрес узла Windows, чтобы программа Linux может подключиться к программе сервера узлов Windows.

Пользователь WSL2 Linux может использовать команду:

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

Типичные выходные данные могут быть:

172.30.96.1

Таким образом, 172.30.96.1 это IP-адрес узла для Windows, в этом примере.

Примечание.

Эти действия, описанные выше, требуются при выполнении WSL2 с сетевым режимом NAT по умолчанию. Когда WSL2 работает с новым зеркальным режимом, узел Windows и виртуальная машина WSL2 могут подключаться друг к другу с помощью localhost (127.0.0.1) в качестве целевого адреса, поэтому трюк использования IP-адреса однорангового узла запроса не требуется.

Сетевой режим по умолчанию: NAT

По умолчанию WSL использует архитектуру на основе NAT (преобразование сетевых адресов) для сети. При работе с сетевой архитектурой на основе NAT следует учитывать следующие рекомендации.

Доступ к сетевым приложениям Linux из Windows (localhost)

Если вы создаете сетевое приложение (например, приложение, работающее на NodeJS или SQL Server) в дистрибутиве Linux, вы можете получить к нему доступ из приложения Windows (например, используя Microsoft Edge или Chrome) с помощью localhost (как обычно это и происходит).

Доступ к сетевым приложениям Windows из Linux (IP-адрес основной системы)

Если вы хотите получить доступ к сетевому приложению, работающему в Windows (например, к приложению, работающему на NodeJS или SQL Server) из дистрибутива Linux (напр., Ubuntu), необходимо использовать IP-адрес основной системы. Хотя это происходит и нечасто, для этого можно выполнить следующие действия.

1. Получите IP-адрес основной системы, выполнив следующую команду из дистрибутива Linux: ip route show | grep -i default | awk '{ print $3}'
2. Подключитесь к любому серверу Windows, используя скопированный IP-адрес.

На изображении ниже показан пример подключения к серверу Node.js под управлением Windows через cURL.

Подключение через удаленные IP-адреса

При использовании удаленных IP-адресов для подключения к приложениям они будут рассматриваться как подключения из локальной сети (LAN). Это означает, что необходимо убедиться, что приложение может принимать подключения по локальной сети.

Например, может потребоваться привязать приложение к 0.0.0.0 вместо 127.0.0.1. В примере приложения Python, использующего Flask, это можно сделать с помощью команды app.run(host='0.0.0.0'). Помните о безопасности при внесении этих изменений, так как это позволит подключениям из локальной сети.

Доступ к дистрибутиву WSL 2 из локальной сети (LAN)

При использовании дистрибутива WSL 1, если к компьютеру можно получить доступ из локальной сети, то приложения, работающие в WSL, могут быть также доступны в локальной сети.

Это нетипичная ситуация в WSL 2. В WSL 2 имеется виртуализированный адаптер Ethernet с собственным уникальным IP-адресом. В настоящее время для включения этого рабочего процесса необходимо выполнить те же действия, что и для обычной виртуальной машины. (Мы ищем способы улучшить это взаимодействие.)

Ниже приведен пример использования команды Portproxy интерфейса Netsh для добавления прокси-сервера порта, прослушивающего порт узла и подключающего прокси-сервер порта к IP-адресу виртуальной машины WSL 2.

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

В этом примере необходимо обновить <yourPortToForward> номер порта, например listenport=4000. listenaddress=0.0.0.0 означает, что входящие запросы будут приниматься из ЛЮБОГО IP-адреса. Адрес прослушивания указывает IPv4-адрес, для которого требуется прослушивать и может быть изменен на значения, которые включают IP-адрес, имя netBIOS компьютера или DNS-имя компьютера. Если адрес не указан, по умолчанию используется адрес локального компьютера. Необходимо обновить <yourPortToConnectToInWSL> значение до номера порта, в котором требуется подключиться WSL, например connectport=4000. Наконец, значение должно быть IP-адресом дистрибутива Linux, connectaddress установленным через WSL 2 (адрес виртуальной машины WSL 2), который можно найти, введя команду: wsl.exe hostname -I

Поэтому эта команда может выглядеть примерно так:

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

Чтобы получить IP-адрес, используйте следующую команду:

• wsl hostname -I для IP-адреса дистрибутива Linux, установленного через WSL 2 (адрес виртуальной машины WSL 2)
• cat /etc/resolv.conf для IP-адреса компьютера Windows, как показано на виртуальной машине WSL 2 (виртуальная машина WSL 2)

Использование listenaddress=0.0.0.0 будет прослушивать все порты IPv4.

Примечание.

Использование нижнего регистра "i" с командой имени узла приведет к созданию другого результата, отличного от использования верхнего регистра "I". wsl hostname -i — это локальный компьютер (127.0.1.1 — это адрес диагностики заполнителя), а wsl hostname -I IP-адрес локального компьютера будет возвращен другими компьютерами и должен использоваться для идентификации connectaddress дистрибутива Linux, работающего через WSL 2.

Доступ по протоколу IPv6

• wsl hostname -i для IP-адреса дистрибутива Linux, установленного через WSL 2 (адрес виртуальной машины WSL 2)
• ip route show | grep -i default | awk '{ print $3}' для IP-адреса компьютера Windows, как показано на виртуальной машине WSL 2 (виртуальная машина WSL 2)

Использование listenaddress=0.0.0.0 будет прослушивать все порты IPv4.

Зеркальное отображение сети

На компьютерах под управлением Windows 11 22H2 и более поздних версий можно задать networkingMode=mirrored в .wslconfig [wsl2] файле для включения сети зеркального режима. Включение этого изменения WSL в совершенно новую сетевую архитектуру, которая имеет цель зеркального отображения сетевых интерфейсов, имеющихся в Windows в Linux, для добавления новых сетевых функций и повышения совместимости.

Ниже приведены текущие преимущества включения этого режима:

• Поддержка протокола IPv6
• Подключитесь к серверам Windows из Linux с помощью адреса 127.0.0.1localhost. Адрес ::1 локального узла IPv6 не поддерживается
• Улучшена совместимость сети для виртуальных сетей
• Поддержка многоадресной рассылки
• Подключение к WSL непосредственно из локальной сети (LAN)

Примечание.

Выполните следующую команду в окне PowerShell с правами администратора, чтобы настроить параметры брандмауэра Hyper-V, чтобы разрешить входящий трафик: Set-NetFirewallHyperVVMSetting -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -DefaultInboundAction Allow илиNew-NetFirewallHyperVRule -Name "MyWebServer" -DisplayName "My Web Server" -Direction Inbound -VMCreatorId '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -Protocol TCP -LocalPorts 80.

Этот новый режим устраняет проблемы с сетью, возникающие при использовании архитектуры на основе NAT (преобразование сетевых адресов). Найдите известные проблемы или отзывы о любых ошибках, обнаруженных в репозитории продукта WSL на GitHub.

Туннелирование DNS

На компьютерах под управлением Windows 11 22H2 и более поздних версий в .wslconfigdnsTunneling=true [wsl2] файле WSL используется функция виртуализации для ответа на ЗАПРОСы DNS из WSL, а не запрашивать их по сетевому пакету. Эта функция предназначена для улучшения совместимости с виртуальными сетями и других сложных сетей.

Автоматический прокси-сервер

На компьютерах под управлением Windows 11 22H2 и более поздних версий параметр autoProxy=true [wsl2] в файле применяет WSL для использования сведений о прокси-сервере .wslconfig Windows. Если у вас уже настроен прокси-сервер в Windows, включение этой функции приведет к автоматическому настройке прокси-сервера в WSL.

WSL и брандмауэр

На компьютерах под управлением Windows 11 22H2 и более поздних версий с WSL 2.0.9 и выше функция брандмауэра Hyper-V будет включена по умолчанию. Это обеспечит следующее:

• Дополнительные сведения о функциях безопасности Windows, которые будут автоматически применяться к WSL, см . в брандмауэре Защитника Windows с расширенным безопасностью .
• Дополнительные сведения о применении этих правил и параметров см. в статье "Настройка брандмауэра Hyper-V", чтобы узнать больше о применении этих правил и параметров как локально, так и через интернет-инструменты, такие как Intune.