Почему не работает DNS при VPN в Windows и как это исправить

Как Windows выбирает DNS-сервер при VPN-подключении

Когда вы подключаетесь к VPN в Windows, система должна решить, какой DNS-сервер использовать для разрешения имен. Это решение зависит от режима туннелирования и приоритета сетевых интерфейсов. По умолчанию Windows использует DNS-серверы, назначенные VPN-подключению, если включен режим Force Tunnel. Однако в реальных сценариях часто возникают конфликты: локальные ресурсы перестают открываться по именам, а доступ в интернет может полностью пропасть.

Понимание того, как Windows выбирает DNS, критично для диагностики. Система отправляет DNS-запросы через интерфейс с наименьшей метрикой. Метрика — это числовой приоритет, который Windows назначает автоматически на основе скорости и типа подключения. Например, Ethernet 1 Гбит/с получает метрику 25, Ethernet 100 Мбит/с — 35, Wi-Fi 50–80 Мбит/с — 50. VPN-подключения обычно получают метрику 100 или выше. Если локальный Ethernet имеет метрику 25, а VPN — 100, все DNS-запросы пойдут через Ethernet, даже если вы хотите использовать DNS VPN.

Это поведение объясняет, почему после подключения к VPN вы можете видеть, что интернет работает, но корпоративные ресурсы не открываются по именам. И наоборот, если VPN имеет более низкую метрику, локальные имена перестают резолвиться. Понимание метрик — первый шаг к решению проблемы.

Режимы VPN: Force Tunnel и Split Tunnel

Windows поддерживает два основных режима VPN-подключения: Force Tunnel и Split Tunnel. В режиме Force Tunnel (опция «Использовать основной шлюз в удаленной сети» включена) весь трафик, включая DNS, направляется через VPN-туннель. Это означает, что все DNS-запросы уходят на DNS-серверы, назначенные VPN-сервером. В результате вы теряете возможность разрешать имена устройств в локальной сети, а доступ в интернет через локальное подключение блокируется. Доступ к локальным ресурсам возможен только по IP-адресам, и частично спасает кэш DNS-клиента.

В режиме Split Tunnel (опция отключена) в VPN-туннель маршрутизируется только трафик, предназначенный для корпоративных подсетей, согласно таблице маршрутизации. DNS-запросы при этом отправляются через локальный интерфейс, и Windows игнорирует DNS-серверы VPN. Это позволяет использовать локальные DNS для доступа в интернет и локальные ресурсы, но корпоративные имена могут не резолвиться, если они не доступны через локальные DNS.

Выбор режима зависит от ваших задач. Если вам нужен полный туннель для безопасности, используйте Force Tunnel, но будьте готовы к проблемам с локальными именами. Если нужен доступ и к локальным, и к корпоративным ресурсам, Split Tunnel с правильной маршрутизацией — более гибкое решение. Однако в Split Tunnel DNS-запросы для корпоративных доменов могут не попадать на нужные серверы, если не настроить DNS-суффиксы и маршруты.

Проблемы с DNS в Force Tunnel: почему локальные имена не работают

В режиме Force Tunnel весь DNS-трафик уходит в VPN-туннель. Это приводит к тому, что DNS-запросы для локальных устройств (например, принтеров, NAS или других компьютеров в домашней сети) отправляются на DNS-серверы VPN-провайдера, которые не знают о вашей локальной сети. В результате имена не разрешаются, и вы не можете подключиться к устройствам по имени, только по IP-адресу.

Дополнительная сложность возникает, если локальная сеть использует те же IP-подсети, что и удаленная сеть VPN. Например, если и дома, и в офисе используется сеть 192.168.0.0/24, маршрутизация становится конфликтной, и доступ к ресурсам может быть невозможен даже по IP. В таких случаях рекомендуется изменить локальную подсеть на нестандартную, например 10.10.10.0/24, чтобы избежать пересечений.

Частичным решением для Force Tunnel является отключение IPv6 на локальном интерфейсе. Некоторые пользователи сообщают, что это помогает, но это не универсальное решение. Более надежный способ — переключиться на Split Tunnel или настроить метрики интерфейсов, чтобы DNS-запросы для локальных имен шли через локальный DNS, а для корпоративных — через VPN. Однако в чистом Force Tunnel это невозможно без дополнительных инструментов, таких как YogaDNS, который позволяет маршрутизировать DNS-запросы по маскам доменов.

Метрики интерфейсов: как они влияют на выбор DNS

Windows 10 и 11 автоматически назначают метрики сетевым интерфейсам на основе их скорости и типа. Эта метрика определяет, через какой интерфейс будут отправляться DNS-запросы. Если у вас есть Ethernet с метрикой 25 и VPN с метрикой 100, все DNS-запросы пойдут через Ethernet, даже если VPN-подключение активно. Это означает, что DNS-серверы VPN будут игнорироваться, и корпоративные имена не будут резолвиться.

Чтобы изменить это поведение, вы можете вручную настроить метрики. Например, если вы хотите, чтобы DNS-запросы шли через VPN, увеличьте метрику локального Ethernet до значения больше 100 (например, 120). Это заставит Windows отдавать приоритет VPN-интерфейсу для DNS. Сделать это можно через графический интерфейс: откройте ncpa.cpl, свойства Ethernet, TCP/IPv4, дополнительные параметры, снимите флажок «Автоматическое назначение метрики» и укажите нужное значение.

Альтернативно можно использовать PowerShell: Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 120 (где 11 — индекс вашего LAN-интерфейса, который можно получить через Get-NetIPInterface). Или через netsh: netsh int ip set interface interface="Ethernet 3" metric=120. Аналогично можно уменьшить метрику VPN-подключения, чтобы оно стало приоритетным. Важно помнить, что изменение метрик влияет не только на DNS, но и на маршрутизацию всего трафика, поэтому действуйте осторожно.

Настройка Split Tunnel и DNS-суффиксов через PowerShell

Split Tunnel — это режим, при котором в VPN-туннель направляется только трафик к определенным подсетям, а весь остальной трафик идет через локальное подключение. Это позволяет одновременно использовать локальные DNS для интернета и корпоративные DNS для внутренних ресурсов. Однако по умолчанию Windows в Split Tunnel игнорирует DNS-серверы VPN, что может привести к невозможности разрешать корпоративные имена.

Чтобы исправить это, можно настроить DNS-суффикс для VPN-подключения. DNS-суффикс автоматически добавляется к коротким именам при отправке DNS-запросов. Например, если ваш корпоративный домен — corp.example.com, и вы вводите имя server1, Windows будет запрашивать server1.corp.example.com. Настроить суффикс можно через PowerShell: Set-VpnConnection -Name "VPN" -DnsSuffix corp.example.com.

Также важно добавить маршруты для корпоративных подсетей, чтобы трафик к ним шел через VPN. Это делается командой Add-VpnConnectionRoute -ConnectionName "VPN" -DestinationPrefix 172.16.10.0/24. Вы можете добавить несколько маршрутов для разных подсетей. Если вы используете OpenVPN-сервер, можно передавать маршруты и DNS-серверы клиентам через опции push "route 10.24.1.0 255.255.255.0" и push "dhcp-option DNS 192.168.100.11".

Эти настройки позволяют гибко управлять тем, какие DNS-запросы и трафик идут через VPN, а какие — через локальную сеть. Это особенно полезно для удаленных сотрудников, которым нужен доступ и к интернету, и к корпоративным ресурсам.

SMHNR и утечки DNS: как защититься

Smart Multi-Homed Name Resolution (SMHNR) — это функция Windows, которая была включена по умолчанию в версиях с Windows 8.1 до Windows 1703. При активной SMHNR Windows отправляет DNS-запросы на все известные DNS-серверы параллельно и использует первый полученный ответ. Это может привести к утечке DNS-запросов: внешние DNS-серверы, указанные в VPN-подключении, могут видеть ваши запросы, даже если вы используете локальный DNS. Это серьезная проблема для конфиденциальности, так как DNS-запросы раскрывают, какие сайты вы посещаете.

Чтобы предотвратить утечки, рекомендуется отключить SMHNR. Это можно сделать через групповую политику: Computer Configuration -> Administrative Templates -> Network -> DNS Client -> Turn off smart multi-homed name resolution. Установите значение Enabled. Альтернативно, можно внести изменения в реестр с помощью PowerShell:

Set-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient" -Name DisableSmartNameResolution -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" -Name DisableParallelAandAAAA -Value 1 -Type DWord

Эти команды отключают параллельную отправку DNS-запросов и предотвращают утечку. После применения изменений рекомендуется перезагрузить компьютер или перезапустить службу DNS-клиента. Отключение SMHNR также может улучшить предсказуемость выбора DNS-сервера, так как Windows будет использовать только интерфейс с наименьшей метрикой.

Практические примеры: настройка DNS для корпоративного VPN

Рассмотрим типичный сценарий: вы работаете из дома и подключаетесь к корпоративному VPN. Вам нужен доступ к внутренним ресурсам компании (например, intranet.company.com) и одновременно доступ в интернет через локального провайдера. Если использовать Force Tunnel, весь трафик пойдет через VPN, что замедлит интернет и может заблокировать локальные ресурсы. Лучше настроить Split Tunnel.

Пример настройки через PowerShell:

# Создаем VPN-подключение с Split Tunneling
Add-VpnConnection -Name "WorkVPN" -ServerAddress "vpn.company.com" -TunnelType L2TP -SplitTunneling $True -DnsSuffix "company.com"

# Добавляем маршруты для корпоративных подсетей
Add-VpnConnectionRoute -ConnectionName "WorkVPN" -DestinationPrefix 10.10.0.0/16
Add-VpnConnectionRoute -ConnectionName "WorkVPN" -DestinationPrefix 172.16.0.0/12

После подключения DNS-запросы для intranet.company.com будут отправляться на DNS-серверы VPN (если они назначены), а для остальных доменов — на локальные DNS. Если корпоративные DNS-серверы не назначаются автоматически, вы можете указать их в свойствах VPN-подключения или через PowerShell: Set-VpnConnection -Name "WorkVPN" -DnsSuffix "company.com".

Если у вас возникают проблемы с разрешением коротких имен (например, server1 вместо server1.company.com), убедитесь, что DNS-суффикс настроен правильно. Также проверьте, что маршруты для корпоративных подсетей добавлены, иначе трафик к ним может идти через локальный шлюз и не достигать цели.

Диагностика проблем с DNS: команды и инструменты

Когда DNS не работает при VPN, важно быстро диагностировать причину. Вот несколько команд, которые помогут:

• Get-NetIPInterface | Sort-Object InterfaceMetric — показывает метрики всех сетевых интерфейсов. Это поможет понять, какой интерфейс используется для DNS.
• Get-DnsClientServerAddress — выводит список DNS-серверов, назначенных каждому интерфейсу.
• Resolve-DnsName example.com — проверяет разрешение имени с использованием текущих настроек.
• nslookup example.com — классическая утилита для проверки DNS.
• ipconfig /all — показывает полную информацию о сетевых адаптерах, включая DNS-суффиксы и метрики.

Если вы подозреваете утечку DNS, можно использовать онлайн-сервисы для проверки, но помните, что они сами могут собирать данные. Лучше использовать локальные инструменты, такие как Wireshark, для анализа DNS-трафика.

Также полезно проверить кэш DNS: ipconfig /flushdns очищает кэш, что может помочь, если проблема связана с устаревшими записями. Если после очистки проблема сохраняется, переходите к настройке метрик или режима туннелирования.

Частые ошибки и как их избежать

Одна из частых ошибок — использование одинаковых IP-подсетей в локальной и удаленной сети. Например, если и дома, и в офисе используется 192.168.1.0/24, маршрутизация становится конфликтной, и доступ к ресурсам может быть невозможен. Рекомендуется использовать нестандартные подсети, например 10.10.10.0/24, чтобы избежать пересечений.

Другая ошибка — неправильная настройка DNS-суффиксов. Если вы не укажете DNS-суффикс для VPN-подключения, короткие имена корпоративных ресурсов не будут резолвиться. Убедитесь, что суффикс указан в свойствах VPN или через PowerShell.

Также многие забывают отключить SMHNR, что приводит к утечкам DNS. Проверьте настройки групповой политики или реестра, как описано выше.

Наконец, не забывайте про метрики. Если вы изменили метрику интерфейса, но DNS все еще не работает, проверьте, не переопределяет ли ее VPN-клиент. Некоторые VPN-клиенты (например, OpenVPN) могут автоматически изменять метрики при подключении. В таких случаях настройте метрики на стороне VPN-клиента или используйте скрипты для автоматической корректировки.

Вопросы и ответы