В Windows 10 при активном VPN подключении в режиме Force Tunneling (включена опция “Use default gateway on remote network”/ “Использовать основной шлюз в удаленной сети”) для разрешения имен через службу DNS используются DNS сервера и суффиксы, настроенные для VPN подключения. Соответственно, вы теряете возможность резолвить DNS имена в своей локальной сети и пользоваться Интернетом через внутреннюю LAN.
При этом с Windows 10 можно выполнить ping до ресурсов в вашей LAN сети (пропингуйте ваш шлюз, соседний компьютер или принтер), но по имени они не доступны, т.к. Windows пытается разрешить имена в локальной сети через DNS сервера, указанные для VPN соединения.
В Google я нашел рекомендации по отключению IPv6 на локальном (LAN) подключении и это работает (если вы хотите использовать Force-Tunneling).
Если для VPN подключения используется режим Split Tunneling (снята галка “Use default gateway on remote network”), вы можете пользоваться интернетом через свою локальную сеть, но не можете резолвить DNS адреса в удаленной VPN сети (в этом случае не помогает отключение IPv6).
Нужно понимать, что Windows отправляет DNS запрос с сетевого интерфейса, у которого высший приоритет (меньшее значение метрики интерфейса). Допустим, ваше VPN подключение работает в режиме Split Tunneling (вы хотите пользоваться интернетом через свою LAN и корпоративными ресурсами через VPN подключение).
С помощью PowerShell проверьте значение метрик всех сетевых интерфейсов:
Get-NetIPInterface | Sort-Object Interfacemetric
На картинке выше видно, что у локального Ethernet подключения указана более низкая метрика (25), чем у VPN интерфейса (в этом примере 100). Соответственно, DNS трафик идет через интерфейс с более низким значением метрики. Это значит, что ваши DNS запросы отправляются на ваши локальные DNS сервера, а не на DNS сервера VPN подключения. Т.е. в такой конфигурации вы не можете резолвить адреса во внешней VPN сети.
Кроме того, нужно обязательно упомянуть новую фичу DNS клиента в Windows 8.1 и Windows 10. В этих версиях ОС для максимально быстрого получения ответов на DNS запросы был добавлен функционал DNS релолвера под названием Smart Multi-Homed Name Resolution (SMHNR). При использовании SMHNR система по умолчанию отправляет DNS запросы на все известные системе DNS сервера параллельно и использует тот ответ, который пришел быстрее. Это не безопасно, т.к. потенциально внешние DNS сервера (которые указаны в вашем VPN подключении) могут видеть ваши DNS запросы (утечка ваших DNS запросов вовне). Вы можете отключить SMHNR в Windows 10 с помощью групповой политики:
Computer Configuration -> Administrative Templates -> Network -> DNS Client-> Turn off smart multi-homed name resolution = Enabled.
Или командами (для Windows 8.1):
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
В Windows 10 Creators Update (1709) и выше DNS запросы отправляются на все известные DNS сервера по порядку, а не параллельно. Вы можете увеличить приоритет конкретного DNS, если уменьшите его метрику.
Соответственно, изменение метрики позволит вам отправлять DNS запросы через тот сетевой интерфейс (LAN или VPN), разрешение имен через который для вас более приоритетно.
Итак, чем меньше значение метрики интерфейса, тем больше приоритет такого подключения. Windows выставляет метрику IPv4 сетевым интерфейсам автоматически в зависимости от их скорости и типа. Например, для LAN подключения с скоростью >200 Мбит значение метрики интерфейса 10, а для беспроводного Wi-FI подключения со скоростью 50-80 Мбит метрика 50 (см. таблицу https://support.microsoft.com/en-us/help/299540/an-explanation-of-the-automatic-metric-feature-for-ipv4-routes).
Вы можете изменить метрику интерфейса через графический интерфейс, PowerShell или команду netsh.
Например, вы хотите, чтобы DNS запросы отправлялись через VPN подключение. Вам нужно увеличить метрики ваших локальных LAN подключений, чтобы они стали больше 100 (в моем примере).
Откройте Панель управления -> Сеть и Интернет -> Сетевые подключения, откройте свойства вашего Ethernet подключения, выберите свойства протокола TCP/IPv4, перейдите на вкладку “Дополнительные параметры TCP/IP”. Снимите галку “Автоматическое назначение метрики” и измените метрику интерфейса на 120.
Тоже самое можно сделать командами PowerShell управления сетью (используйте индекс вашего LAN интерфейса, полученный с помощью командлета
Get-NetIPInterface
):
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 120
Или netsh (нужно указать имя вашего LAN подключения)
netsh int ip set interface interface="Ethernet 3" metric=120
Аналогично вы можете уменьшить значение метрики в свойствах VPN подключения.
Также вы можете изменить настройки вашего VPN подключения, изменив режим на SplitTunneling и указать DNS суффикс для подключения c помощью PowerShell:
Get-VpnConnection
Set-VpnConnection -Name "VPN" -SplitTunneling $True
Set-VpnConnection -Name "VPN" -DnsSuffix yourdomain.com
Так в итоге то хочется, чтобы резолвинг работал автоматически. относительно того, по какому интерфейсу обращаешься и не париться с метриками. Что делать в этом случае?
1) прописать все DNS в основной интерфейс
2) написать скрипт, который «подшаманит» метрики при подключении и вернет все «как было» при отключении
Если я правильно понял, то автор предлагает для «одновременной» работы с локальными ресурсами и/или локальным интернетом и корпоративными ресурсами, подключёнными через vpn постоянно вручную менять туда-сюда метрики интерфейсов?
Ну как-то так себе «решение» проблемы…. :/
Согласен, такое себе решение. Не знаю как на Windows, но на Mac я в свойствах VPN подключения добавил DNS сервер рабочей сети и у меня все резолвится без активной галки «гонять трафик через шлюз VPN» — без каких-либо костылей.
Блин. Вот за что «люблю2 PowerShell, так это за такие вот «косяки»
Windows 7 Professional
PS C:\Users> Get-NetIPInterface | Sort-Object Interfacemetric
Get-NetIPInterface : The term 'Get-NetIPInterface' is not recognized as the name of a cmdlet, function, script file, or operable program. C
heck the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
+ Get-NetIPInterface | Sort-Object Interfacemetric
+ ~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Get-NetIPInterface:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
PS C:\Users>
Что я «забыл» ему подключить?
Всё просто, на 99.9% уверен что на 7ке старая версия powershell: $PSVersionTable
Обновите
До какой?
Установлено два разных
PowerShell 6.2.1
Copyright (c) Microsoft Corporation. All rights reserved.
https://aka.ms/pscore6-docs
Type ‘help’ to get help.
PS C:\Users\kornev> Get-Host|Select-Object Version
Version
——-
6.2.1
——————————————————————————————
Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.
PS C:\Users\kornev> Get-Host|Select-Object Version
Version
——-
5.1.14409.1018
Я поднимаю такой ВПН (пример для L2TP с ключом для Win8.1 и Win10):
$VpnName = "VPN"
$Address = "xx.xx.xx.xx"
$ipSecKey = "key"
$dnsSuffix = "domain.local"
Add-VpnConnection -Name $VpnName -ServerAddress $Address -EncryptionLevel Optional -AuthenticationMethod MSCHAPv2 -SplitTunneling -TunnelType L2TP -L2tpPsk $ipSecKey -RememberCredential -DnsSuffix $dnsSuffix -Force
Add-VpnConnectionRoute -ConnectionName $VpnName -DestinationPrefix 192.168.0.0/24
Add-VpnConnectionRoute -ConnectionName $VpnName -DestinationPrefix 10.10.0.0/24
При этом VPN-сервер выдает DNS на свое подключение клиенту. И всё работает прекрасно. Имена резолвятся по короткому имени, маршруты к ним работают. Инет и локальные ресурсы доступны.
На Win7, если не хочется править статические маргруты, то только ставить галку «Основной шлюз в удаленной сети». Так же будут прлблемы, если локальная сеть совпадает с удаленной.
А если у кого-то домашняя Локальная сеть тоже 192.168.0.0/24?
В домашней сети проще сменить ip адресацию, чтобы она не пересекалась с ip адресацией предприятия. Это не проблема.
Правильно не использовать на предприятии сети 192.168.0.0 и 192.168.1.0. Что бы потом не было мучительно больно.
Ну 192.168.0.0 понятно. Ещё «особо одарённые» лепят маску 255.255.0.0
А потом «удивляются» 🙂
А эту почему? 192.168.1.0 Обычная сеть. Что-то «сакральное»?
Это причина не трогать сеть 192..168.1.0?
192.168.1.1 и 192.168.0.1 — это общепринятые сетевые локальные адреса, которые производители маршрутизаторов нередко используют как стандарт доступа к настройкам роутера.
Alex Kornev, отвечаю сам себе, потому что на вашем комментарии нет почему-то кнопки ответить.
Эти две сети лучше не использовать, потому что они дефолтные в большинстве роутеров (SOHO класса по крайней мере). И вся веселуха начинается когда надо пользователей по VPN’у подключать к сети предприятия. Или объединить площадки общей сетью, а на них на всех сеть одинаковая. И начинается любовь с каким-нибудь netmap’ом и перенастройка домашних сетей пользователей. Последнее вообще дичь полнейшая.
Так что надо просто взять себе за правило нигде и никогда не делать сети 192.168.0.0 и 192.168.1.0. Страшного в этом ничего нет, но позволит избежать кучу потенциального геморроя.
Ну я так и написал. Разве нет. Повторюсь еще раз.
192.168.1.1 и 192.168.0.1 — это общепринятые сетевые локальные адреса, которые производители маршрутизаторов нередко используют как стандарт доступа к настройкам роутера.
Вообще оборудование класса SOHO неказисто использовать в компаниях Хотя… наверное я слишком долго работаю с компаниями 1000+ человек с распределенными, в том числе территориально разнесенными, офисами. Отвык 🙂
А «особо одаренные» админо-студенты-школьники «лепят» сети 192.168.0.0/16 — «У меня все работает и все видно» 🙂
Класс! На самом деле хорошая идея, и можно раздать powershell скрипт пользователям на удаленке.
В Win7, да и в Win10 обхожусь вот таким батником
rasdial VPNNAME user password
route add 192.168.100.0 mask 255.255.255.0 192.168.105.4
START /W [то что надо запустить]
route delete 192.168.100.0
rasdial VPNNAME /disconnect
exit
Если надо поднять VPN на время
И никаких «Основной шлюз в удаленной сети»
Есс-но номера сетей разные.
Делать одну сеть — это даже не моветон, а безграмотность «админов»
с сетями типа 192.168.0.0/255.255.0.0
Set-NetIPInterface -InterfaceIndex 11 -InterfaceMetric 120 вот это работает только при включенном vpn для отключенных впн не видит
Или netsh (нужно указать имя вашего LAN подключения)
netsh int ip set interface interface=»Ethernet 3″ metric=120
вот это в вин 10 1909 не работает проверял
выдает вот это
Синтаксическая ошибка в имени файла, имени папки или метке тома.