WSL без интернета с VPN: как проверить NAT и DNS

Если WSL без интернета с VPN, сравните один запрос в Windows и WSL2 при выключенном и включённом туннеле, прежде чем менять конфигурацию. Затем разделите разрешение имён, сетевой режим, прокси и ответ приложения: рабочий браузер Windows не подтверждает доступность маршрута процесса Linux внутри WSL.

Ключевые выводы:

• До выбора исправления запишите версии Windows, WSL и дистрибутива.
• NAT и зеркальная сеть WSL2 имеют разные условия и поведение.
• DNS tunneling и наследование HTTP-прокси решают разные задачи.
• Меняйте одну применимую настройку, сохраняйте работу до перезапуска и повторяйте тот же запрос.
• Сохраняйте межсетевой экран, TLS, корпоративный DNS и административную политику.

Почему WSL без интернета с VPN, хотя Windows работает?

WSL2 запускает Linux в виртуализированной среде, сеть которой взаимодействует с Windows. Microsoft описывает NAT как архитектуру по умолчанию, а зеркальный режим — как вариант для Windows 11 22H2 и новее. Он предназначен для улучшения ряда сценариев, включая совместимость с VPN, но не подтверждает работу каждого клиента и окружения.［1］

Приложения Windows и Linux могут использовать разные резолверы, настройки прокси, сохранённые соединения и протоколы целей. Сравнение браузера и настольного приложения объясняет обычную границу, после которой здесь добавляются версия WSL и виртуализация. Не превращайте эту диагностику в общий сброс DNS Ubuntu.

Наблюдение	Следующая область проверки	Что пока не доказано
Windows и WSL не работают без VPN	Базовая сеть или сервис	Сбой именно из-за туннеля
Windows работает, имена в WSL не разрешаются	Резолвер и условия DNS tunneling	Поломка всех IP-маршрутов
Имя разрешается, соединение истекает по времени	Маршрут, фильтр, прокси, семейство адресов	Отказ сервера аккаунту
Соединение есть, приложение отказывает	Ответ приложения и права	Другой выход предоставит доступ
Не работает одно приложение Linux	Его сеть и поддержка прокси	Отсутствие сети у всех приложений WSL

Общее руководство по VPN даёт контекст туннеля. Здесь проверяйте именно тот дистрибутив, который запускает проблемный процесс, а не любое открытое окно Linux.

Шаг 1: Какие версии и настройки используются?

В PowerShell или командной строке Windows запишите установку WSL и поколение дистрибутива:

wsl --version
wsl --status
wsl -l -v

Microsoft при диагностике просит версии Windows, WSL, ядра, дистрибутива и шаги воспроизведения. Старые встроенные установки могут не поддерживать wsl --version; укажите это и используйте доступные сведения состояния, не придумывая номер. Последний столбец wsl -l -v различает WSL1 и WSL2.［2］

Прочитайте существующий .wslconfig в профиле пользователя Windows и /etc/wsl.conf в нужном дистрибутиве. Первый управляет глобальными настройками WSL2, второй действует отдельно для дистрибутива. Сохраните копии перед редактированием и не удаляйте посторонние ключи, комментарии или настройки организации.［3］

Отметьте, создаётся ли /etc/resolv.conf автоматически или обслуживается вручную, какой прокси уже настроен и какова версия VPN-клиента. Не публикуйте пароль прокси и корпоративные домены. Для WSL1 нужен свой поддерживаемый порядок: одинаковая команда запуска wsl не делает настройки виртуальной сети WSL2 применимыми к первой версии.

Шаг 2: Как безопасно сравнить запросы Windows и Linux?

Выберите безвредную публичную HTTPS-операцию, доступную обеим средам, либо внутреннюю операцию, явно разрешённую администратором. Зафиксируйте цель, состояние аккаунта, тип запроса и близкий период проверки. Отключите необязательный VPN и выполните запрос из Windows, затем из проблемного дистрибутива Linux.

Разделите результат на разрешение имени, установку соединения и ответ приложения. Используйте документированную диагностику или уже установленный доверенный клиент. Не устанавливайте новый пакет через неисправный путь только ради начального сравнения. Ошибка сертификата относится к доверию и не разрешает отключать его проверку.

Пример Microsoft показывает, где выполняется команда Linux при обращении к приложению Windows. Это не проверка публичного выхода: локальный адрес и успешный ответ на картинке не измерены на вашем устройстве и не относятся к испытанию продукта.［1］

Если важен публичный адрес, используйте проверку выхода браузера Windows и отдельно получите наблюдение приложения WSL. Этот сайт является браузерным инструментом, а не обещанным JSON API для curl; не разбирайте его HTML как такой интерфейс. Для подтверждения источника Linux-запроса нужна разрешённая конечная точка с документированным выводом.

Запишите четыре сочетания: Windows без туннеля, WSL без туннеля, Windows с туннелем, WSL с туннелем. Если оба результата WSL одинаково неудачны, VPN пока не является различающим фактором. Проверка DNS Ubuntu полезна, когда независимая диагностика действительно указывает на резолвер Linux.

Шаг 3: Как оценить альтернативный маршрут Windows?

Если личному компьютеру Windows нужен другой исходящий путь, установите AethoVPN из официального .exe, используйте настольные подключения Pro или Premium и выберите расположение, которое сейчас показано в приложении. Запишите состояние глобального режима и переподключитесь до сравнения запросов Windows и WSL. В этой попытке оставьте конфигурацию Linux без изменений.

Полезное наблюдение — улучшилась ли та же операция WSL, осталась прежней или стала отказывать на другом этапе. Туннель Windows не является гарантией поддержки всех версий WSL, интеграции DNS или сочетаний зеркального режима. Для новой оценки зарегистрируйтесь по электронной почте и начните трёхдневную пробную версию Pro; срок начинается с регистрации, предложение доступно один раз на пользователя. Действующие пользователи подходящего тарифа могут проверять сразу.

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

Шаг 4: Когда применимы зеркальная сеть WSL и туннелирование DNS в WSL?

Даже на Windows 11 22H2 или новее сверяйте актуальные условия Microsoft до выбора режима. Если вы управляете компьютером, добавьте только подходящий ключ networkingMode в существующую секцию [wsl2], не заменяя весь файл. Место каждой настройки определяется официальным справочником конфигурации.［1］［3］

[wsl2]
networkingMode=mirrored

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

DNS tunneling отвечает на запросы DNS Linux через механизм виртуализации. Microsoft описывает его для Windows 11 22H2 и новее как способ улучшить совместимость сложной сети, включая VPN. До dnsTunneling=true прочитайте условия конфигурации, особенно если создание файла резолвера было раньше отключено.［1］［2］［3］

Проверьте generateResolvConf в секции [network] файла /etc/wsl.conf нужного дистрибутива: для DNS tunneling автоматическое создание не должно быть отключено. Ключ dnsTunneling относится к [wsl2] в Windows %UserProfile%\.wslconfig, а не к файлу Linux. Если установленная версия уже включает его, повтор того же значения не создаёт нового сравнения.

Намеренно управляемую конфигурацию резолвера сначала должен проверить её владелец. После перезапуска из шага 6 повторите то же разрешение имени и запрос приложения.［2］［3］

Не вставляйте публичный резолвер в /etc/resolv.conf для обхода корпоративных требований разделённого DNS. Публичное имя может заработать, тогда как разрешённые внутренние имена перестанут разрешаться, а исходная причина останется скрытой. После одного поддерживаемого изменения повторите ту же проверку имени, сохранив остальную сеть неизменной.

Шаг 5: Может ли причина быть в прокси, а не DNS?

Microsoft описывает autoProxy=true как наследование информации HTTP-прокси Windows в поддерживаемых окружениях WSL. Это не другое название туннеля VPN и не принуждение всех Linux-приложений пользоваться переменными прокси. Сверьте документацию конкретного приложения и его отдельные настройки.［1］［3］

Объяснение прокси Windows помогает различить HTTP-прокси и маршрут устройства. Проверяйте наличие релевантных настроек и переменных, скрывая пароли, закрытые URL и токены. Не отправляйте поддержке полный список переменных среды.

Одно приложение может использовать разрешённый прокси, другое — прямое соединение, а NO_PROXY исключать отдельные цели. Сохраняйте такие правила при диагностике. Если корпоративный доступ зависит от управляемого прокси, попросите IT проверить приложение, не очищайте настройки глобально и не копируйте адрес браузерного расширения в WSL.

Шаг 6: Как перезапустить, восстановить и подтвердить результат?

Сохраните работу Linux, остановите задания разработки обычным способом и предупредите других пользователей этой среды WSL. Затем выполните:

wsl --shutdown

Команда останавливает виртуальную машину WSL2 и работающие дистрибутивы, чтобы глобальные изменения вступили в силу. Это не удаление, переустановка или отмена регистрации, однако несохранённая работа и службы могут прерваться. Откройте нужный дистрибутив заново и повторите точно ту же операцию.［3］

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

Для отдельного гостя VirtualBox используйте сравнение маршрутов виртуальной машины. Docker Desktop добавляет ещё одну границу выполнения: применяйте проверки контейнера, не приравнивая его backend к маршрутам всех программ WSL.

Остановитесь, если изменение управляется IT, сервис отказывает в авторизации или исходную связность невозможно восстановить. Передайте обезличенные версии, режим, первый этап ошибки, матрицу и одно проверенное изменение. Сохраняйте межсетевой экран и проверку TLS во время всего разбора и передачи вопроса владельцу.

Итоги

• Отличайте успех Windows от успеха фактического процесса WSL.
• Определите поколение WSL и условия версий.
• Разделяйте DNS, маршрут, HTTP-прокси и ответ приложения.
• Сохраняйте конфигурацию и работу до перезапуска.
• Отменяйте бесполезные изменения, вопросы политики передавайте IT.

Часто задаваемые вопросы (FAQ)

Исправляет ли зеркальный режим любую проблему VPN в WSL?

Нет. Это вариант сети с условиями и преимуществами совместимости, а не универсальное исправление. Версии, клиент, политика, DNS и приложение требуют отдельной проверки.

Подходят ли те же инструкции зеркального режима для Windows 10?

Не используйте их как поддерживаемый рецепт. Microsoft указывает Windows 11 22H2 или новее; выбирайте порядок действий для своей установки.

Почему Windows разрешает имя, а WSL нет?

Среды могут иметь разные механизмы и настройки резолвера. Сравните одно разрешённое имя и условия DNS tunneling вместо вывода о поломке всех соединений.

Направляет ли autoProxy весь Linux-трафик через VPN Windows?

Нет. Он наследует информацию HTTP-прокси там, где поддерживается. Приложения по-разному используют прокси, который отличается от туннеля устройства.

Безопасно ли заменить resolv.conf публичным DNS?

Не применяйте это как общее исправление. Сохраняйте корпоративный DNS и требования доменов: публичный резолвер может скрыть сбой и нарушить внутренние имена.

Удаляет ли wsl --shutdown мой дистрибутив?

Команда останавливает работающую среду, а не отменяет её регистрацию. Сохраните работу и остановите задания, поскольку приложения и службы будут прерваны.

Что подтверждает пользу изменения настройки?

Та же операция WSL должна дать ожидаемый результат после одного изменения, с записанными версией и исходной проверкой. Браузер Windows отдельно этого не подтверждает.

Отказ от ответственности: Это общая техническая информация. Используйте настройки, поддерживаемые вашими версиями Windows и WSL, соблюдайте закон и сетевую политику и согласуйте изменения управляемой конфигурации.

Источники:

1. Microsoft Learn — Accessing network applications with WSL — https://learn.microsoft.com/en-us/windows/wsl/networking
2. Microsoft Learn — Troubleshooting Windows Subsystem for Linux — https://learn.microsoft.com/en-us/windows/wsl/troubleshooting
3. Microsoft Learn — Advanced settings configuration in WSL — https://learn.microsoft.com/en-us/windows/wsl/wsl-config

Sources checked 7 октября 2026 г.

---

Рекомендуемые статьи:

• Отдельно проверить гостевую систему
• Определить контейнер запроса
• Разобрать различия браузера и приложения