В Windows интернет есть, а в WSL2 нет: как разбирать DNS, NAT и VPN

Сначала подтвердите версию и границы проблемы

Windows открывает сайты, а apt, git или curl внутри WSL2 не может соединиться. Это не обязательно одна общая неисправность: браузер Windows может пользоваться прокси, а Linux-программа — прямым соединением; внутренние имена организации могут требовать её DNS-политики.

В PowerShell Windows:

wsl --version
wsl --status
wsl --list --verbose

Убедитесь, что проблемный дистрибутив действительно работает как WSL2. Версия приложения WSL и версия Windows — разные сведения. Старые встроенные варианты WSL могут не знать часть современных команд и параметров; сначала сверяйте применимость с документацией. Описанные далее mirrored и DNS tunneling требуют поддерживаемой Windows 11 и достаточно новой WSL. ^{[1], [2], [3]}

Зафиксируйте, пропадают ли все внешние ресурсы или только внутренний сервер, возникает ли ошибка только с VPN и какой именно дистрибутив затронут. Docker и отдельные контейнеры имеют дополнительные сетевые уровни; работоспособность одной WSL-среды не описывает автоматически каждый контейнер.

Повторите запрос к одному и тому же имени

В Windows замените учебное site.example на проблемный сервер:

Resolve-DnsName -Name site.example
Test-NetConnection -ComputerName site.example -Port 443 -InformationLevel Detailed
curl.exe --verbose --connect-timeout 10 --max-time 30 --output NUL "https://site.example/"

Внутри нужного Linux-дистрибутива:

getent ahosts site.example
ip address
ip route
curl --version
curl --verbose --connect-timeout 10 --max-time 30 --output /dev/null "https://site.example/"

getent проверяет системный путь разрешения имени Linux; curl показывает этап отказа конкретного HTTP-клиента. У минимального дистрибутива часть утилит может отсутствовать: сообщение «command not found» не является сетевой ошибкой. Установку нужного пакета выполняют штатным способом своего дистрибутива, когда доступен репозиторий. ^{[2], [4], [5]}

Сравните разрешённые адреса и то, использует ли curl прокси. Открывающийся браузер Windows и неработающий прямой запрос Linux не образуют чистое сравнение, пока различаются посредники.

Прочитайте оба файла конфигурации, прежде чем менять их

Файл %UserProfile%\.wslconfig находится в профиле Windows и задаёт параметры WSL2. Файл /etc/wsl.conf находится внутри конкретного Linux-дистрибутива. Не перепутайте их и не создавайте файл с расширением .txt. ^[3]

Get-Content "$env:USERPROFILE\.wslconfig" -ErrorAction SilentlyContinue

cat /etc/wsl.conf
cat /etc/resolv.conf
ls -l /etc/resolv.conf

Отсутствие необязательного wsl.conf или .wslconfig допустимо. Перед изменением сохраните копию существующего файла и запишите, отсутствовал ли он. В старых инструкциях часто отключали generateResolvConf и вручную закрепляли DNS; такая настройка может мешать современной DNS tunneling. Не удаляйте resolv.conf, пока не выяснили, генерируется ли он и не является ли ссылкой.

DNS tunneling: не заменяйте корпоративный DNS случайным публичным

На поддерживаемой Windows 11 22H2 и новее DNS tunneling позволяет обрабатывать DNS-запросы WSL через механизм виртуализации Windows. Это помогает учитывать сетевые особенности и VPN. Проверьте версию WSL и действующие параметры; одно наличие строки в файле не гарантирует поддержку функции. ^{[2], [3]}

В .wslconfig соответствующий параметр находится в секции wsl2:

[wsl2]
dnsTunneling=true

Для DNS tunneling генерация resolv.conf не должна быть отключена через generateResolvConf в wsl.conf. Если раньше стояло false, сначала сохраните копии и верните управляемую генерацию по руководству WSL; отдельно учтите вручную созданный или защищённый файл. Не прописывайте один и тот же внешний DNS всем сетям: внутренние зоны VPN могут исчезнуть.

После применения сравните getent для внешнего и внутреннего имени. Если Windows тоже не разрешает внутреннее имя, сначала исправляют её сетевую политику — WSL не создаст отсутствующий ответ самостоятельно.

Требование о generateResolvConf и ограничения DNS tunneling отдельно описаны в разделе устранения неполадок WSL. Если файл resolv.conf раньше закрепляли вручную или делали неизменяемым, переход нельзя свести к одной строке в .wslconfig. Сохраните свой вариант и восстановите штатную схему именно для дистрибутива; не применяйте чужую команду создания символической ссылки без проверки её цели. ^[8]

NAT и mirrored решают разные задачи

Традиционный режим WSL2 использует NAT. В mirrored сетевые возможности Windows отражаются в Linux; среди преимуществ Microsoft отмечает совместимость с VPN, IPv6 и взаимодействие через localhost. Mirrored доступен на Windows 11 22H2 и новее с соответствующей WSL; поддержка конкретного VPN всё равно требует проверки. ^[2]

Для отдельного опыта можно изменить только networkingMode в сохранённом .wslconfig:

[wsl2]
networkingMode=mirrored

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

Проверьте прокси Windows и переменные Linux

Если Windows выходит через HTTP-прокси, сравните Параметры → Сеть и Интернет → Прокси и переменные среды Linux:

printenv http_proxy https_proxy HTTP_PROXY HTTPS_PROXY no_proxy NO_PROXY

Вывод может содержать секреты, если раньше пароль поместили в URL; не отправляйте его целиком. Современная WSL поддерживает autoProxy, который передаёт сведения о прокси Windows. Настройка находится в секции wsl2; применимость и значения по умолчанию проверяют по своей версии. ^{[2], [3], [6]}

[wsl2]
autoProxy=true

Наличие прокси ещё не гарантирует, что любое Linux-приложение правильно использует сценарий PAC или проходит корпоративную аутентификацию. Проверьте его собственную настройку и поддержку. Прокси, слушающий только 127.0.0.1 Windows, в NAT нельзя автоматически считать доступным по 127.0.0.1 Linux; в mirrored правила взаимодействия другие. Не открывайте локальный прокси всем сетям ради проверки.

Для PAC WSL может передавать адрес сценария через WSL_PAC_URL; это не означает, что любая Linux-программа умеет выполнить такой сценарий. Пользовательские переменные окружения могут иметь приоритет над автоматически полученными. Если после смены Windows-прокси Linux продолжает обращаться к старому адресу, проверьте настройки оболочки, WSLENV и конфигурацию самой программы. ^[8]

Примените изменение штатно и проверьте влияние VPN

Сохраните работу во всех запущенных дистрибутивах и задачах WSL, включая зависимые процессы. В PowerShell Windows:

wsl --shutdown

Команда завершает все запущенные дистрибутивы и виртуальную среду WSL2, а не только текущую вкладку терминала. Затем снова запустите нужный дистрибутив и повторите исходные команды. Закрыть одну вкладку бывает недостаточно для применения .wslconfig. ^{[1], [3]}

Если правила сети разрешают, сравните состояние с VPN и без него, сохраняя один сетевой режим и один целевой сервер. При сбое только с VPN важны его версия, режим WSL, DNS и прокси. Не меняйте одновременно все три параметра: будет невозможно понять, какой из них повлиял.

Mirrored не универсален: Microsoft описывает отдельные несовместимости VPN и клиентов защиты. Например, для Global Secure Access указана возможность нарушения из-за временных адресов DNS и особые обходы через другой режим или DNS-параметр. Это основание проверить конкретный установленный клиент, а не включать либо отключать DNS tunneling на всех компьютерах. ^[8]

Если DNS верен, исследуйте порт, TLS и защиту

Если getent возвращает адрес, а curl сообщает об ошибке сертификата, перейдите к доверенному издателю и корпоративной HTTPS-инспекции. Хранилища доверия Windows и Linux могут отличаться. Сертификат организации устанавливают по её официальной инструкции; отключение проверки TLS не исправляет доверие.

Для WSL на актуальной Windows действуют также сетевые правила Windows и Hyper-V. Администратор может прочитать применённые параметры, не отключая защиту:

Get-NetFirewallHyperVVMSetting -PolicyStore ActiveStore -Name "{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}"

Отсутствие команды или отказ прав нужно отличать от результата блокировки. Фильтрация исходящего трафика, корпоративные правила и запрет объединения локальных правил могут влиять на WSL. Не добавляйте глобальное Allow и не выключайте firewall целиком. Для выяснения причины нужен конкретный адрес, порт, время и действующее правило. ^[7]

Передайте администратору версии Windows/WSL, режим, копии конфигурации без секретов, ответы DNS, этап ошибки curl и результат сравнения с VPN. Не выполняйте wsl --unregister: это удаляет дистрибутив, а не сбрасывает его сеть.