Вопрос: VPN-соединение заставляет DNS использовать неправильный DNS-сервер


У меня есть ПК с Windows 7 в сети нашей компании (который входит в нашу Active Directory). Все работает нормально, пока я не открою VPN-подключение к сайту клиента.

Когда я подключаюсь, я теряю сетевой доступ к общим ресурсам в сети, включая такие каталоги, как «Данные приложения», для которых у нас есть политика перенаправления папок. Как вы можете себе представить, это затрудняет работу с ПК, поскольку ярлыки на рабочем столе перестают работать, программное обеспечение перестает работать должным образом из-за того, что из него извлекаются «данные приложения».

Наша сеть маршрутизируется (10.58.5.0/24), с другими локальными подсетями, существующими в пределах 10.58.0.0/16. Удаленная сеть находится на 192.168.0.0/24.

Я проследил проблему до того, как связан с DNS. Как только я открою VPN-туннель, все мой DNS-трафик проходит через удаленную сеть, что объясняет потерю локальных ресурсов, но мой вопрос заключается в том, как я могу заставить локальные DNS-запросы обращаться к нашим локальным DNS-серверам, а не к нашим клиентам?

Выход ipconfig /all когда он не подключен к VPN, находится ниже:

Windows IP Configuration

   Host Name . . . . . . . . . . . . : 7k5xy4j
   Primary Dns Suffix  . . . . . . . : mydomain.local
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : mydomain.local

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : mydomain.local
   Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
   Physical Address. . . . . . . . . : F0-4D-A2-DB-3B-CA
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::9457:c5e0:6f10:b298%10(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.58.5.89(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : 31 January 2012 15:55:47
   Lease Expires . . . . . . . . . . : 10 February 2012 10:11:30
   Default Gateway . . . . . . . . . : 10.58.5.1
   DHCP Server . . . . . . . . . . . : 10.58.3.32
   DHCPv6 IAID . . . . . . . . . . . : 250629538
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-AC-76-2D-F0-4D-A2-DB-3B-CA

   DNS Servers . . . . . . . . . . . : 10.58.3.32
                                       10.58.3.33
   NetBIOS over Tcpip. . . . . . . . : Enabled

Это результат той же команды с подключенным туннелем VPN:

Windows IP Configuration

   Host Name . . . . . . . . . . . . : 7k5xy4j
   Primary Dns Suffix  . . . . . . . : mydomain.local
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : mydomain.local

PPP adapter Customer Domain:

   Connection-specific DNS Suffix  . : customerdomain.com
   Description . . . . . . . . . . . : CustomerDomain
   Physical Address. . . . . . . . . :
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.0.85(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.255
   Default Gateway . . . . . . . . . :
   DNS Servers . . . . . . . . . . . : 192.168.0.16
                                       192.168.0.17
   Primary WINS Server . . . . . . . : 192.168.0.17
   NetBIOS over Tcpip. . . . . . . . : Disabled

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : mydomain.local
   Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
   Physical Address. . . . . . . . . : F0-4D-A2-DB-3B-CA
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::9457:c5e0:6f10:b298%10(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.58.5.89(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : 31 January 2012 15:55:47
   Lease Expires . . . . . . . . . . : 10 February 2012 10:11:30
   Default Gateway . . . . . . . . . : 10.58.5.1
   DHCP Server . . . . . . . . . . . : 10.58.3.32
   DHCPv6 IAID . . . . . . . . . . . : 250629538
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-AC-76-2D-F0-4D-A2-DB-3B-CA

   DNS Servers . . . . . . . . . . . : 10.58.3.32
                                       10.58.3.33
   NetBIOS over Tcpip. . . . . . . . : Enabled

Таблица маршрутизации

Интерфейс сетевого макета сети

          0.0.0.0          0.0.0.0        10.58.5.1       10.58.5.89     20
        10.58.5.0    255.255.255.0         On-link        10.58.5.89    276
       10.58.5.89  255.255.255.255         On-link        10.58.5.89    276
      10.58.5.255  255.255.255.255         On-link        10.58.5.89    276
    91.194.153.42  255.255.255.255        10.58.5.1       10.58.5.89     21
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.0.0    255.255.255.0     192.168.0.95     192.168.0.85     21
     192.168.0.85  255.255.255.255         On-link      192.168.0.85    276
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link        10.58.5.89    276
        224.0.0.0        240.0.0.0         On-link      192.168.0.85    276
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link        10.58.5.89    276
  255.255.255.255  255.255.255.255         On-link      192.168.0.85    276

Порядок привязки для интерфейсов следующий:

enter image description here

Я не настраивал туннель VPN для использования шлюза по умолчанию на удаленном конце, и сеть, связанная с узлами в обеих сетях, прекрасна. (т. е. я могу пинговать любой узел в нашей сети или удаленной сети).

Я изменил свойства подключения PPTP для использования DNS-серверов 10.58.3.32 с последующим 192.168.0.16, но запрос по-прежнему относится к 192.168.0.16.


Редактировать:

Локальные ресурсы, которые исчезают, размещаются на корнях домена DFS, которые могут (или могут отсутствовать) быть релевантными.


Дальнейшее редактирование:

Это только влияет на корни домена DFS. Если я ссылаюсь на общий ресурс через имя сервера (т. \\server\share вместо \\dfsroot\share), Я могу получить доступ к акциям.

В соответствии с моим комментарием против этот ответ, Я обнаружил, что могу добавить DNS-имя домена в файл моих хостов, из-за которого мои сетевые диски (DFS) исчезнут, но мне все же хотелось бы, чтобы смелая часть моего вопроса (выше) отвечала, есть ли у кого-нибудь идеи ,


15
2018-02-02 10:31


Источник


Вы никогда не говорили о том, какой брандмауэр вы используете? Это очень важный фактор ИМО, поскольку я думаю, что именно там вы сможете найти ответ на этот вопрос. - Hanny
@hanny брандмауэр обеспечивается трансляцией сетевых адресов на ADSL-модемах на обоих сайтах. Я могу, возможно, предоставить номера моделей, если это действительно необходимо, но они будут просто стандартными модемами ADSL NAT. Учитывая, что мы говорим об AD с интегрированным DNS, я не считаю эти устройства релевантными, поскольку проблемы являются чисто DNS. - Bryan
Если VPN не обрабатывается брандмауэром, а Windows, то он представляет разные отправленные параметры для работы внутри, поскольку Windows VPN довольно ограничен в моем опыте. Например, с ASA 5505 - сплит-туннелирование - это что-то действительно легкое для устранения неполадок, и есть большая конфигурация, которая может быть выполнена, особенно в отношении проблем DNS и назначения DNS. Вот почему я спросил, спасибо за разъяснение. - Hanny
Не могли бы вы добавить route print (от vpn-соединения) до сообщения? - florianb
Нет ничего плохого в маршрутизации, так как он может подключаться через IP-адрес, но не через DNS - MichelZ


Ответы:


Хорошо, нашел отличный ресурс здесь: http://rdpfiles.com/2011/08/25/windows-vpn-client-and-local-dns-resolution/

Это не идеально, но может работать.

Порядок привязки хранится в реестре в следующем месте:    HKLM\System\CurrentControlSet\Services\Tcpip\Linkage\Bind, Список   включает все GUID устройства для сетевых адаптеров и активные   соединения в порядке приоритета привязки.

При работе с ключом реестра появляются следующие факты:

Изменение порядка GUID в реестре влияет на   обязательный порядок, в том числе для VPN-соединений

  • Любые изменения ключа вступают в силу немедленно
  • Когда VPN-соединение завершено, GUID для подключения добавляется в начало порядка привязки, если он еще не существует
  • Когда VPN-соединение закрыто, запись GUID для соединения удаляется
  • Если для соединения есть несколько записей GUID, только один из них удаляется при закрытии соединения

Этот механизм создает возможность следующего обходного пути:

  1. Изучите раздел реестра Bind
  2. Подключение к VPN-соединению
  3. Еще раз проверьте ключ Bind и скопируйте GUID, который был добавлен в начало списка.
  4. Вставьте запись GUID в нижней части списка 20 раз.
  5. Экспортируйте ключ и очистите экспортированный файл, чтобы включить только ключ привязки

Результат - это ключ, который будет поддерживать желаемое поведение. Каждый раз   VPN-соединение установлено, поскольку GUID присутствует, он будет   не добавляется. Поскольку идентификатор GUID находится внизу, разрешение DNS будет   выполняется локально клиенту. Когда соединение отключено, один   Запись GUID будет удалена. После 20 VPN-подключений экспортируется   файл реестра может использоваться для повторной передачи ключа.

Конечно, вы можете вставлять GUID больше раз, чтобы уменьшить, как часто вы   придется переименовывать ключ.

Также важно помнить о повторной процедуре, если есть какие-либо   изменения сетевых адаптеров.


11
2018-06-25 23:59



Хорошая находка. Это работает очень хорошо, в сочетании с сценарием запуска компьютера, чтобы сбросить значение ключа реестра при каждой загрузке, что должно стать отличным обходным решением для того, что не должно быть проблемой в первую очередь. Большое спасибо. Я дам это дополнительное тестирование. - Bryan
Я бы рекомендовал создать запланированную задачу. Контролируйте идентификатор события 20226, который соответствует событию отключения VPN. Затем запустите небольшой скрипт powershell (powershell -File c:\scripts\fixdnsbind.ps1) который содержит: $val = Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\services\Tcpip\Linkage -Name Bind; $val.Bind += "\Device\{D7D0BD5E-B65C-4239-BA4D-D309186E9524}"; Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\services\Tcpip\Linkage -Name Bind -Value $val.Bind, (не забудьте адаптировать идентификатор адаптера). Вы также запускаете этот сценарий один раз перед подключением к VPN. - Steve B


Как уже говорилось, это проблема разделения туннелей.

Три исправления, рекомендуйте # 2, потому что это легко и будет иметь хорошую производительность, если вы используете хорошую коробку с VMware Workstation 8

1 - Включить раздельное туннелирование - небезопасно и может потребовать работы со стороны клиента. Вероятно, это не произойдет, ИТ-безопасность гестапо собирается закрыть вас.

2 - Виртуализированный подход к рабочему столу - P2V существующий рабочий стол и превратите его в виртуальную машину. Используйте виртуальную машину для VPN для клиента. Вы держите свой рабочий стол и можете переключаться на него и из него по мере необходимости.

3 - Виртуализированный серверный подход - P2V ваш существующий рабочий стол и превратите его в виртуальную машину, а затем поставьте на бесплатную версию ESXi. Вы сохраняете свой рабочий стол и можете переключиться на виртуальную машину по мере необходимости через консоль. Это может быть медленным ...


3
2018-06-23 18:02



+1; Мне нравится идея иметь выделенную виртуализованную систему для этой задачи, однако я не вижу, что здесь хорошо работает на данный момент по разным причинам. Это, безусловно, будет хорошим решением в будущем. Благодарю. - Bryan


Мне кажется, что VPN-туннель каким-то образом имеет приоритет над локальным интерфейсом, направляющим DNS-трафик на VPN-серверы VPN (вы можете проверить запрос на этих серверах, чтобы проверить это поведение, если у вас есть к ним доступ, или кто-то может проверить это поведение для вы).

Это я не могу полностью объяснить, поскольку порядок привязки указывает по-разному. Согласно этому сообщение здесь (см. более высокий ответ). У Windows есть другое представление, когда дело доходит до этого, выбирая канал с более высоким приоритетом в зависимости от скорости соединения НЕ с порядком привязки адаптера. Поэтому для тестирования попробуйте следующее изменить это автоматическое поведение: 1) перейти к сетевым соединениям и для каждого сделать 2) Свойства IP v4 3) Дополнительно 4) Отключить «Автоматическая метрика» 5) Вручную введите метрику 1 для вашей локальной соединение и метрика 2 на вашем VPN-соединении (PPP). Таким образом, он будет сортировать жесткий провод, путь к локальным DNS-серверам, как предпочтительный по сравнению с удаленным DNS.

Надеюсь это поможет!


2
2018-06-21 14:58



Интересно, что, глядя на мою таблицу маршрутизации выше, метрика на интерфейсе LAN является самой низкой (20), VPN-соединение имеет показатель 21. Сказав это, эта проблема может быть несколько прерывистой, а таблица маршрутизации показана выше , все работает правильно. Я попытаюсь воссоздать проблему и повторно проверить таблицу маршрутизации. - Bryan
Обновите, просто заново открыли туннель, и все мои подключения к дискам упали, но таблица маршрутизации ничем не отличается от выше. т. е. метрика 20 для локальной сети, метрика 21 для VPN. - Bryan
@Bryan, эта статья Microsoft (support.microsoft.com/kb/299540), вроде, проверяет, что я сказал выше. Было бы интересно посмотреть, что произойдет, если вы пройдете процедуру, которую я написал выше, когда у вас есть время. Другие сообщают о точных прерывистых проблемах, которые вы видите, и решили это путем жесткой проводки метрик (serverfault.com/questions/70792/...). К сожалению, в настоящее время у меня нет аналогичной настройки для проведения некоторых тестов. - ank
Огромное спасибо за этот @ank, я, конечно же, буду на следующей неделе, когда вернусь в офис. Интересная статья BTW. Благодарю. - Bryan
Это сделал трюк для меня! Метрика в настройках IPv4 для сетевого адаптера, похоже, не имеет ничего общего с метрикой в ​​таблице маршрутизации! Изменение порядка GUID в HKLM \ System \ CurrentControlSet \ Services \ Tcpip \ Linkage \ Bind, о котором писал ZnArK, ничего не изменило в отношении того, какой NIC / DNS используется. Это проверено на Windows 10 - MrCalvin


Ваш VPN-туннель находится между клиентом и клиентской сетью. Похоже, что это не использование сплит-туннелирования, которое остановит вас при доступе к ресурсам в вашей собственной сети, пока туннель вверх.

Таким образом, вам (или вашему клиенту) необходимо разрешить раздельное туннелирование, или вам нужно дополнительное сетевое соединение и настроенная таблица маршрутов для одновременного доступа к обеим сетям.


1
2018-02-02 12:58



Для информации я могу получить доступ к сетевым ресурсам, пока туннель завершен, это просто разрешение DNS, которое, похоже, сломается. Я не был знаком с термином split tunnellingесли честно, но, насколько я могу судить, это просто означает, что я не использую шлюз по умолчанию на удаленном сайте, который, несмотря на то, что я не указываю, я уже делаю. Спасибо за ответ, я отредактирую свой вопрос, чтобы отразить это. - Bryan
В этом случае это похоже на то, что VPN-клиент не настроен для разделения DNS. С помощью разделенного DNS концентратор VPN предоставляет вашему VPN-клиенту список DNS-серверов (как это в настоящее время), а также список доменов, которые являются единственными доменами, которые должны использоваться с этими DNS-серверами; все остальные будут использовать DNS вашей системы по умолчанию. - James Sneeringer


К сожалению, Windows VPN не может выполнять «Split-DNS». Однако вы можете удалить DNS-сервер из VPN-подключения после подключения к удаленному сайту.

Вы можете сделать это, выпустив:

netsh interface ipv4 delete dnsservers name = "имя VPN"address = all   проверить = нет

Вы должны делать это каждый раз, когда вы подключаетесь к VPN-сети.


1
2018-06-20 13:09



FYI ... это останавливает вас от использования удаленного (VPN) DNS. - MichelZ
Проблема в том, что, как только туннель поднимается, я уже страдаю от проблемы, описанной в моем вопросе, поэтому команда будет слишком поздно. Кроме того, экспериментируя с этим, команда фактически не имеет никакого значения (nslookup все еще использует удаленный DNS-сервер, плюс ipconfig все еще перечисляет удаленный DNS-сервер). Я также отредактировал параметры DNS для туннельного подключения VPN, чтобы использовать собственные внутренние настройки DNS, но это игнорируется, все, что мой DNS-трафик по-прежнему отображается на удаленном DNS-сервере. - Bryan
Я пробовал это, так как у меня была такая же проблема, и она работала здесь. Вы настроили "имя VPN«Кроме того, если вы в основном обеспокоены этим один сервер, к которому подключены ваши диски, добавьте его в свой файл hosts, и ничто не сможет его переопределить - MichelZ
Спасибо, я попытался изменить имя (вырезать и вставить из ipconfig вывода, и когда я понял, что ошибаюсь, я получил ошибку The filename, directory name, or volume label syntax is incorrect), поэтому я уверен, что правильно получил команду. Возможно, что-то на удаленном сервере PPTP не позволяет переопределить настройку DNS. Я буду исследовать, но мне нравится идея ввода файлов хостов. Я дам это. Также см. Мое редактирование на вопрос. - Bryan
Я просто попробовал команду еще раз, и он удалил DNS-сервер из PPP-соединения. Не могли бы вы подтвердить ipconfig /all? Я думаю, что запись хостов должна быть самым простым решением для вас. - MichelZ


Хотя этот вопрос был задан давно, но опубликовал этот ответ, поскольку это может помочь другим. У меня была та же проблема с VPN, когда пользователи использовали для подключения к удаленному vpn свои внешние dns, используемые для остановки, например. google.com использовались только домены компании, которые были указаны в split-dns,

Проблема заключалась в том, что локальная машина использовала dns-запрос, поступающий в туннель vpn, и если dns разрешено в туннеле, он падает. Когда он отпадает, он сначала выбирает ipv6 как разрешение, а затем никогда не возвращается к ipv4.

Таким образом, чтобы проверить результаты, мы сначала отключили ipv6 на локальном компьютере, и он начал работать. Чтобы окончательно исправить это для всех пользователей, которые мы включили client-bypass-protocol команды на брандмауэре ASA, который игнорировал IPv6, если он не настроен для пулов vpn.

поэтому, если вы не можете управлять брандмауэром и знать, что сплит-туннель и разделить dns на месте, но он не работает, вы можете попробовать отключить ipv6 на локальном компьютере, и если вы можете управлять им, вы можете включить команду выше, если вы не используете ipv6 в своей удаленной сети.

Это помогло мне, надеюсь, это поможет другим :)


0
2018-06-26 22:54





Я что-то имею с опытом!

Установите VPN-соединение с локальным DNS-сервером и подключитесь к VPN, используемому nslookup, для запроса имени домена VPN. Вы должны получить ответ с IP-адресом, локальным для VPN-локальной сети. Это означает, что вы использовали VPN-серверы VPN для разрешения запроса.

Теперь откройте подключение к локальной сети и вручную настройте DNS на локальный или ISP-DNS. Воля !!! используйте клавишу со стрелкой и повторите запрос nslookup. Вы получите общедоступный IP-адрес, чтобы использовать локальный / ISP-DNS-сервер для разрешения запроса домена VPN. Bam !!!!


0
2018-06-25 05:28





Почему вы думаете, что его DNS?

Если вы потеряете доступ к своим сетевым ресурсам при подключении к VPN - кажется, почти наверняка, что ваша машина испытывает трудности с WINS / NETBIOS.

Определите сервер WINS и повторите проверку.


-1
2018-06-20 21:38



Я точно не знаю, что это является причиной моих проблем, но я знаю, что клиенты AD должны использовать DNS-серверы, которые используются для размещения AD, и это не так. Поскольку проблема возникает только в том случае, когда я делаю VPN-соединение, и в то же время мое DNS-разрешение становится вялым, похоже, что DNS является вероятным кандидатом. Несмотря на это, я не хочу использовать удаленный DNS-сервер при подключении к другой сети с использованием VPN. - Bryan
Вы определили WINS-сервер в соответствии с моим предложением? Не типично для Windows использовать DNS-сервер в VPN, если не используется одно значение или «Использовать удаленный шлюз установлен», который, как вы сказали, отключен. Также вы используете статический IP-адрес в туннеле VPN, так почему вы вообще настроили записи DNS? Удалите эти DNS-серверы (192.168.0.16-17) или установите WINS-сервер. - Ben Lessani - Sonassi
Нет, я не пробовал, так как у нас нет WINS-сервера, чтобы указать клиентам. Я не уверен, что WINS поможет быть честным, поэтому я не заинтересован в установке WINS-сервера в нашей сети, потому что он мог бы Помогите. Конечно, я буду помнить об этой идее, поэтому спасибо. IP назначается сервером VPN и является динамическим. Если я не назначаю DNS-сервер для VPN-подключения, он динамически назначается сервером. Я даже жестко закодировал свои собственные DNS-серверы в свойствах VPN-подключения, но он все еще использует DNS-серверы на удаленном сайте. - Bryan
Я не нуждаюсь и не хочу использовать удаленный DNS-сервер, я всегда хочу, чтобы разрешение DNS выполнялось на локальном сервере, это будем исправить мою проблему, поэтому мой вопрос сосредоточен на DNS. Вероятно, я мог бы использовать правило брандмауэра для блокировки доступа к удаленному DNS-серверу, но это не устраняет проблему с неправильной конфигурацией. - Bryan
ваша интерпретация этого неверна. IP-адрес назначается сервером PPTP, который фактически не использует DHCP. На сервере PPTP есть пул, из которого он может выделяться, но это не DHCP. Однако каждый раз, когда я подключаюсь, я получаю разные IP-адреса. Кроме того, я не отмечен флажок, чтобы использовать удаленный шлюз, как вы можете ясно видеть из таблицы маршрутизации. - Bryan