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

17

У меня есть ПК с 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

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

введите описание изображения здесь

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

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

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

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

Далее Edit:

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

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

— Bryan
источник

Вы никогда не упоминали, какой брандмауэр вы используете? Это довольно важный фактор IMO, так как я думаю, что именно здесь вы потенциально найдете ответ на этот вопрос.

— Хенни

@ Hanny межсетевой экран обеспечивается трансляцией сетевых адресов на модемах ADSL на обоих сайтах. Возможно, я могу предоставить номера моделей, если они действительно нужны, но они будут просто стандартными модемами ADSL NATing. Учитывая, что мы говорим об AD со встроенным DNS, я не считаю эти устройства актуальными, поскольку проблемы касаются исключительно DNS.

— Брайан

Если VPN не обрабатывается брандмауэром, а Windows, то это представляет другую отправленную параметры для работы, так как Windows VPN довольно ограничен в моем опыте. Например, с ASA 5505 - разделить туннелирование - это действительно легко устранить, и есть много настроек, которые можно выполнить, особенно в отношении проблем DNS и назначения DNS. Вот почему я спросил, спасибо за разъяснение.

— Хенни

Не могли бы вы добавить route print(из vpn-соединения) к сообщению?

— florianb

В маршрутизации нет ничего плохого, так как он может подключаться через IP, но не через DNS

— MichelZ

12

Хорошо, нашел отличный ресурс здесь: 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, только одна удаляется при закрытии соединения

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

Изучите раздел реестра Bind

Подключитесь к вашему VPN-соединению

Снова проверьте ключ Bind и скопируйте GUID, который был добавлен в начало списка.

Вставьте запись GUID внизу списка 20 раз

Экспортируйте ключ и очищайте экспортированный файл, чтобы включить только ключ связывания

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

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

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

— ZnArK
источник

Хорошая находка. Это работает очень хорошо, в сочетании со скриптом запуска компьютера для сброса значения ключа реестра при каждой загрузке, что должно стать отличным обходным путем, что не должно быть проблемой в первую очередь. Большое спасибо. Я дам это для дальнейшего тестирования.

— Брайан

3

Я бы порекомендовал создать запланированное задание. Отслеживайте событие с кодом 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.

— Стив Б

4

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

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

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

— апк
источник

Интересно, что, глядя на мою таблицу маршрутизации, показатель на интерфейсе локальной сети самый низкий (20), у VPN-соединения показатель 21. Он сказал, что эта проблема может быть несколько неустойчивой, и с таблицей маршрутизации, как показано выше. , все в настоящее время работает правильно. Я попытаюсь воссоздать проблему и перепроверить таблицу маршрутизации.

— Брайан

Обновление, только что снова открыл туннель, и все мои подключения к дискам оборвались, но таблица маршрутизации ничем не отличается от описанной выше. т.е. метрика 20 для локальной сети, метрика 21 для VPN.

— Брайан

1

@ Брайан, эта статья Microsoft ( support.microsoft.com/kb/299540 ), вроде как, подтверждает то, что я сказал выше. Было бы интересно посмотреть, что произойдет, если вы пройдете процедуру, которую я написал выше, когда у вас будет время. Другие сообщали о проблемах, которые вы периодически видите, и решали их с помощью жесткой привязки метрик ( serverfault.com/questions/70792/… ). К сожалению, в настоящее время у меня нет аналогичной настройки для проведения некоторых тестов.

— ank

Большое спасибо за этот @ank, я обязательно попробую позже на следующей неделе, когда вернусь в офис. Интересная статья Кстати. Благодарю.

— Брайан

1

Это помогло мне! Метрика в настройках IPv4 для сетевого адаптера, похоже, не имеет ничего общего с метрикой в таблице маршрутизации! Изменение порядка GUID в HKLM \ System \ CurrentControlSet \ Services \ Tcpip \ Linkage \ Bind, о котором писал ZnArK, ничего не изменило в отношении использования NIC / DNS. Это проверено на Windows 10

— MrCalvin

4

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

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

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

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

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

— Бреннан
источник

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

— Брайан

3

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

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

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

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

— MichelZ
источник

К вашему сведению ... это мешает вам использовать удаленный (VPN) DNS.

— MichelZ

Проблема в том, что, как только туннель будет запущен, я уже страдаю от проблемы, описанной в моем вопросе, поэтому команда будет слишком поздно. Также, поэкспериментировав с этим, команда на самом деле, кажется, не имеет никакого значения ( nslookupвсе еще использует удаленный DNS-сервер, плюс ipconfigвсе еще перечисляет удаленный DNS-сервер). Я также отредактировал настройки DNS для подключения VPN-туннеля, чтобы использовать мои собственные внутренние настройки DNS, но это игнорируется, и весь мой трафик DNS по-прежнему направляется на удаленный DNS-сервер.

— Брайан

1

Я пробовал это, поскольку у меня была та же проблема, и она работала здесь. Вы корректировали « имя VPN »? Кроме того, если вы в основном обеспокоены этим один сервер , на котором ваши диски подключены к, добавьте его в файле хостов, и ничто не сможет изменить его

— MichelZ

Спасибо, я попытался изменить имя (вырезать и вставить из ipconfigвыходных данных, и когда я ошибся, я получил ошибку The filename, directory name, or volume label syntax is incorrect), так что я почти уверен, что правильно понял команду. Возможно, что-то на удаленном PPTP-сервере не позволяет мне переопределить настройку DNS. Я буду исследовать, но мне нравится идея ввода файла hosts. Я попробую. Также см. Мое изменение к вопросу.

— Брайан

Я просто попробовал команду еще раз, и она действительно удалила DNS-сервер из соединения PPP. Не могли бы вы проверить с ipconfig /all? Тем не менее, я думаю, что запись хостов должна быть для вас самым легким решением.

— MichelZ

2

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

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

— dunxd
источник

Для информации, я могу получить доступ к сетевым ресурсам, пока туннель работает, это просто разрешение DNS, которое, кажется, нарушается. Я не был знаком с этим термином, split tunnellingесли честно, но, насколько я могу судить, это просто означает, что я не использую шлюз по умолчанию на удаленном сайте, что, несмотря на то, что я не указал, я уже делаю. Спасибо за ответ, я отредактирую свой вопрос, чтобы отразить это.

— Брайан

1

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

— Джеймс Снирингер

0

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

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

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

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

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

— Rsingh
источник

0

У меня есть кое-что, с чем я сталкивался!

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

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

— Graham.Fraser
источник

0

Я просто удаляю эту опцию из конфигурации клиента VPN

setenv opt block-outside-dns

Это решило проблему

— Ismail
источник

0

У меня была эта проблема несколько лет назад, и я исправил ее, отредактировав файл VPN-подключения. Просто сделайте файл vpn.pbk (вы можете найти его в Google), откройте этот файл с помощью текстового редактора, такого как блокнот, и измените значение UseRasCredentials на ноль, и ваша проблема решена. но единственная проблема заключается в том, что приоритет локальных подключений DNS становится выше, чем DNS VPN, а разрешение имен занимает больше времени (если VPN используется для подключения к Интернету).

— Мохсен Бигдели
источник

-1

Как вы думаете, почему это DNS?

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

Определите сервер WINS и повторите тестирование.

— Бен Лессани - Сонасси
источник

Я не знаю наверняка, что это является причиной моих проблем, но я знаю, что клиенты AD должны использовать DNS-серверы, которые используются для размещения AD, а это не так. Так как проблема возникает только тогда, когда я устанавливаю VPN-соединение, и мое разрешение DNS в то же время становится шатким, кажется, что DNS является вероятным кандидатом. Несмотря на это, я не хочу использовать удаленный DNS-сервер при подключении к другой сети с использованием VPN.

— Брайан

Вы определили сервер WINS в соответствии с моим предложением? Windows не типично использовать DNS-сервер в VPN, если только он не определен или «Использовать удаленный шлюз установлен», который, как вы сказали, отключен. Также вы используете статический IP-адрес в туннеле VPN, так почему вы вообще задали записи DNS? Удалите эти DNS-серверы (192.168.0.16-17) или установите WINS-сервер.

— Бен Лессани - Сонасси

Нет, я не пробовал этого, поскольку у нас нет сервера WINS, на который можно было бы указывать клиентам. Я не уверен, что WINS поможет быть честным, поэтому я не заинтересован в установке WINS-сервера в нашей сети, потому что это может помочь. Я, конечно, учту эту идею, так что спасибо. IP назначается сервером VPN и является динамическим. Если я не назначаю DNS-сервер для VPN-подключения, он назначается сервером динамически. Я даже жестко запрограммировал свои собственные DNS-серверы в свойствах VPN-подключения, но он все еще использует DNS-серверы на удаленном сайте.

— Брайан

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

— Брайан

1

Ваша интерпретация этого неверна. IP-адрес назначается сервером PPTP, который фактически не использует DHCP. У сервера PPTP есть пул, из которого он может выделить, но это не DHCP. Однако каждый раз при подключении я получаю новый IP-адрес. Кроме того, я не ставил флажок для использования удаленного шлюза, как вы можете ясно видеть из таблицы маршрутизации.

— Брайан