По умолчанию для всех VPN подключений в Windows используется режим Force Tunnel (в настройках VPN включена опция ‘
Use default gateway on remote network
‘/’
Использовать основной шлюз в удаленной сети
‘). В этом режиме для разрешения имен будут использоваться DNS сервера, которые назначены вашему подключению сервером VPN, и вы не сможете разрешать имена устройств в вашей локальной сети.
Для VPN подключения в Windows доступно два режима:
- Force Tunnel (включена опция Use default gateway) — весь трафик, в том числе DNS, отправляется в VPN туннель. В таком режиме после подключения к VPN вы теряете возможность резолвить DNS имена хостов в вашей локальной сети (после подключения к VPN вы также теряете доступ в Интернет через свою LAN). Доступ будет работать только по IP адресам (частично в этом случае спасает кэш DNS клиента);В Google я нашел рекомендации по отключению IPv6 на локальном (LAN) подключении и это работает (если вы хотите использовать Force-Tunnel).
- Split Tunnel (отключена опция Use default gateway on remote network) — в VPN туннель маршрутизируется только трафик к корпоративным серверам (в соответствии с таблицей маршрутизацией). В этом режиме Windows для разрешения имен использует ваши локальные DNS и игнорирует DNS сервера и DNS суффикс VPN подключения. Таким образом доступ в Интернет и разрешение имен выполняется через вашу локальную сеть (в соответствии с настройками локального сетевого адаптера).
Windows 10/11 отправляет DNS запросы с сетевого интерфейса с наивысшим приоритетом (у которого самое маленькое значение метрики интерфейса). Чтобы вывести значения метрик сетевых интерфейсов компьютера, выполните PowerShell команду:
Get-NetIPInterface | Sort-Object Interfacemetric
На данном компьютере есть два подключение:
- Ethernet подключение с метрикой 25
- VPN подключение – метрика 100
Это значит, что ваши DNS запросы отправляются через интерфейс с меньшей метрикой (Ethernet) на ваши локальные DNS сервера, а не на DNS сервера VPN подключения. В такой конфигурации вы не можете резолвить адреса во внешней VPN сети.
Windows 10/11 задают метрики IPv4 сетевым интерфейсам автоматически в зависимости от их скорости и типа:
Скорость и тип подключения | Метрика |
Ethernet 1 Гб | 25 |
Ethernet 100 Мб | 35 |
Wi-Fi интерфейс со скоростью 50-80 Мб | 50 |
(см. таблицу https://support.microsoft.com/en-us/help/299540/an-explanation-of-the-automatic-metric-feature-for-ipv4-routes).
Например, вы хотите, чтобы DNS запросы отправлялись через VPN подключение. В нашем примере это означает, что нужно увеличить метрику локального Ethernet адаптера и сделать его больше 100.
Вы можете изменить метрики сетевых интерфейсов из графического интерфейса или из командной строки.
- Откройте панель управления сетевыми подключениями (
ncpa.cpl
), откройте свойства вашего 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 подключения.
В такой конфигурации DNS запросы будут выполняться через VPN подключение.
Также вы можете изменить настройки вашего VPN подключения, изменив режим на SplitTunneling (трафик DNS по умочалнию идет в вашу LAN) и указать DNS суффикс для подключения c помощью PowerShell:
Get-VpnConnection
Set-VpnConnection -Name "VPN" -SplitTunneling $True
Set-VpnConnection -Name "VPN" -DnsSuffix yourdomain.com
Также можете указать трафик каких подсетей нужно всегда отправлять в VPN туннель:
Add-VpnConnectionRoute -ConnectionName $VpnName -DestinationPrefix 172.16.10.0/24
Add-VpnConnectionRoute -ConnectionName $VpnName -DestinationPrefix 10.24.2.0/24
Если вы используете OpenVPN сервер, вы можете назначить клиентам дополнительные маршруты и DNS сервера с помощью опций:
push "route 10.24.1.0 255.255.255.0" push "dhcp-option DNS 192.168.100.11"
В версиях с Windows 8.1 до Windows 1703 по умолчанию включена опция Smart Multi-Homed Name Resolution (SMHNR). При активной SMHNR Windows отправляет DNS запросы на все известные системе DNS сервера параллельно и использует тот ответ, который пришел быстрее. Это не безопасно, т.к. потенциально внешние DNS сервера (которые указаны в вашем VPN подключении) могут видеть ваши DNS запросы (утечка ваших DNS запросов вовне). Чтобы предотвратить утечку DNS запросов, желательно отключить SMHNR с помощью групповой политики:
Или можно внести аналогичное изменение в реестр с помощью команд 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
Так в итоге то хочется, чтобы резолвинг работал автоматически. относительно того, по какому интерфейсу обращаешься и не париться с метриками. Что делать в этом случае?
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 не работает проверял
выдает вот это
Синтаксическая ошибка в имени файла, имени папки или метке тома.
Приветствую.
Прошу помощи, может кто-то встречался с таким и знает как победить.
Есть сервер со статическим адресом внутренней сети + впн с динамикой. Пользователи на него ходят из локалки по днс имени. На днс сервере включено динамическое обновление. Все было ок много лет. А недавно на днс-сервере адрес сервера подменился со статического «внутреннего» на ip-адрес полученный при подключении к впн. Соответственно пользователи на него не попадают из внутренней сети. Как регулируется какой адрес должен возвращать клиет днс серверу для обновления? Просто первый раз с таким столкнулся, а в гугле быстро ответ найти не смог…
Буду благодарен за любые предложения
А почему на DNS-сервере адрес сервера подменился? Он разве там не статикой прописан? Может просто кто-то удалил статическую А-запись для сервера, вот он и выдал свой последний полученный адрес в динамике? Создайте для сервера правильную статическую А-запись в зоне.
в статье не увидел ситуацию, когда при активном впн внутрисетевые ресурсы не резолвятся.
Чек-бокс «использовать основной шлюз удалённой сети» — снят.
Приходится по айпишнику ходить на сетевую шару.
Куда идет DNS будет зависить еще и от метрики подключения. Какая и вас метрика у VPN, а какая у локальной сети?
метрики подключения в rasphone.pbk для остальных подключений винда ставит их автоматически. Меньше чем 5 в теории подключить невозможно