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
Порядок привязки интерфейсов следующий:
Я не настраивал VPN-туннель для использования шлюза по умолчанию на удаленном конце, и сетевое соединение с узлами в обеих сетях в порядке. (т.е. я могу пинговать любой узел в нашей сети или удаленной сети).
Я изменил свойства подключения PPTP для использования DNS-серверов. 10.58.3.32 с последующим 192.168.0.16, но запрос по-прежнему идет на 192.168.0.16.
Редактировать:
Исчезающие локальные ресурсы размещаются в корнях домена DFS, что может (или не может) иметь значение.
Дальнейшее редактирование:
Это влияет только на корни DFS домена. Если я ссылаюсь на общий ресурс через имя сервера (т.е. \\server\share вместо того \\dfsroot\share), Я могу получить доступ к общим ресурсам.
Согласно моему комментарию против этот ответ, Я обнаружил, что могу добавить DNS-имя домена в файл моих хостов, который не дает моим (DFS) сетевым дискам исчезать, но я все равно хотел бы, чтобы жирная часть моего вопроса (выше) отвечала, если у кого-то есть какие-либо идеи .
Хорошо, нашел здесь отличный ресурс: 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 несколько раз, чтобы уменьшить частоту повторного импорта ключа.
Также важно не забыть повторить эту процедуру, если есть какие-либо изменения в сетевых адаптерах.
Мне кажется, что туннель VPN каким-то образом имеет приоритет над интерфейсом локальной сети, направляя трафик DNS на серверы DNS VPN (вы можете проверить запрос на этих серверах, чтобы проверить это поведение, если у вас есть доступ к ним, или кто-то может проверить это поведение для ты).
Я не могу полностью объяснить это, поскольку порядок привязки указывает на иное. Согласно этому разместить здесь (см. ответ с более высокой оценкой) Windows по-другому воспринимает это, выбирая канал с более высоким приоритетом в зависимости от скорости соединения, а НЕ от порядка привязки адаптера. Поэтому для тестирования попробуйте следующее, чтобы изменить это автоматическое поведение: 1) перейдите в раздел «Сетевые подключения» и для каждого выполните 2) Свойства IP v4 3) Расширенный 4) Отключите «Автоматическую метрику» 5) Вручную установите метрику 1 для вашего локального соединение и показатель 2 для вашего VPN-соединения (PPP). Таким образом, он будет как бы жестко привязать путь к локальным DNS-серверам, как предпочтительнее, чем удаленный DNS.
Надеюсь это поможет!
Как уже говорилось, это проблема раздельного туннелирования.
Три исправления, рекомендую №2, потому что это просто и будет иметь хорошую производительность при использовании хорошей коробки с VMware Workstation 8.
1 - Включить раздельное туннелирование - небезопасно и может потребовать работы на стороне клиента. Маловероятно, что гестапо ИТ-безопасности отключит вас.
2 - Подход виртуализированного рабочего стола - P2V ваш существующий рабочий стол и превратите его в виртуальную машину. Используйте виртуальную машину для VPN-подключения к клиенту. Вы сохраняете свой рабочий стол и можете переключаться на него и отключаться по мере необходимости.
3 - Подход к виртуализированному серверу - P2V ваш существующий рабочий стол и превратите его в виртуальную машину, а затем поместите его в бесплатную версию ESXi. Вы сохраняете свой рабочий стол и можете переключаться на виртуальную машину по мере необходимости через консоль. Это может быть медленным ...
К сожалению, Windows VPN не поддерживает «Split-DNS». Однако вы можете удалить DNS-сервер из VPN-соединения после подключения к удаленному сайту.
Вы можете сделать это, выполнив:
интерфейс netsh ipv4 удалить dnsservers name = "название VPN"адрес = все проверить = нет
Вы ДОЛЖНЫ делать это каждый раз, когда подключаетесь к сети VPN.
Ваш VPN-туннель находится между клиентом и клиентской сетью. Похоже, он не использует раздельное туннелирование, которое не позволит вам получить доступ к ресурсам в вашей собственной сети, пока туннель открыт.
Таким образом, вам (или вашему клиенту) необходимо включить раздельное туннелирование, или вам нужно дополнительное сетевое соединение и настраиваемая таблица маршрутов для доступа к обеим сетям одновременно.
Хотя этот вопрос был задан давно, но публикация этого ответа может помочь другим. У меня была такая же проблема с VPN, когда, когда пользователи подключались к удаленному vpn, их внешние DNS останавливались, например. google.com работали только домены компании, которые были перечислены на split-dns.
Проблема заключалась в том, что локальная машина, используемая для выполнения запросов DNS, направляется в туннель vpn, и если DNS разрешен в туннеле, он откатывается. Когда он откатывается, он сначала выбирает ipv6 в качестве разрешения, а затем никогда не возвращается к ipv4.
Итак, чтобы проверить результаты, мы сначала отключили ipv6 на локальном компьютере, он начал работать. Чтобы навсегда исправить это для всех пользователей, мы включили client-bypass-protocol команда на брандмауэре ASA, который проигнорировал IPv6, если он не настроен на пулах vpn.
поэтому, если вы не можете управлять брандмауэром и знаете, что разделенный туннель и разделенный DNS на месте, но он не работает, вы можете попробовать отключить ipv6 на локальном компьютере, и если вы можете управлять им, вы можете включить указанную выше команду, если вы не используете ipv6 в своей удаленной сети.
Это помогло мне, надеюсь, это поможет другим :)
Ура, у меня есть опыт!
Установите VPN-соединение с локальным DNS-сервером и подключитесь к VPN, используя nslookup для запроса имени домена VPN. Вы должны получить ответ с IP-адресом, который является локальным для локальной сети VPN. Это означает, что вы использовали DNS-серверы VPN для решения запроса.
Теперь откройте подключение к локальной сети и вручную установите DNS на свой локальный DNS или DNS провайдера. Воля !!! используйте клавишу со стрелкой и повторите запрос nslookup. Вы получите общедоступный IP-адрес, что означает, что вы использовали свой локальный DNS-сервер / ISP-сервер для решения запроса домена VPN. Бац !!!!
Я просто удаляю эту опцию из конфигурации VPN клиента
setenv opt block-outside-dns
Это решило проблему
У меня была эта проблема несколько лет назад, и я решил, отредактировав файл VPN-подключения, просто сделайте файл vpn.pbk (вы можете найти его в Google), откройте этот файл через текстовый редактор, например блокнот, и измените значение UseRasCredentials на ноль, и проблема будет решена. но единственная проблема заключается в том, что ваши локальные соединения. Приоритет DNS становится выше, чем VPN DNS, и разрешение имен занимает больше времени (если для подключения к Интернету используется VPN).
Как вы думаете, почему это DNS?
Если вы теряете доступ к своим сетевым ресурсам при подключении к VPN - почти наверняка ваша машина испытывает трудности с WINS / NETBIOS.
Определите WINS-сервер и повторите попытку.