Monday, December 11th, 2017

Как обойти проблему с VPN клиентами и раздельной DNS

Published on Февраль 12, 2009 by   ·   Один комментарий

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

Введение

Пару лет назад я участвовал в нескольких хороших дискуссиях с различными людьми, включая парня из Microsoft Networking Support, о том, какая ожидается работа по разрешению имен для VPN клиентов. Все соглашались с тем, что когда VPN клиент подключается, мы надеемся, что RRAS адаптер будет автоматически помещен на верх списка адаптеров. Как вы, возможно, знаете, порядок адаптеров играет важную роль в процессе DNS разрешения, потому что DNS серверы, ассоциированные с адаптером, который находится выше в списке адаптеров, проверяются первыми.

Однако, на практике, мы не увидели такого поведения даже, если мы вручную помещали RRAS адаптер на вершину списка соединений в диалоговом окне Advanced Settings (Расширенные Настройки) инструмента Network and Dial-up Connections (Сетевые и Коммутируемые Соединения). Из-за того, что не заметно какого-либо нарушения в конфигурации, с которой я работаю, самое большее, что я мог увидеть – это небольшое замедление в разрешении имен, я не волновался о решении этой проблемы.

Когда я начал публиковать некоторые внутренние сервисы и настраивать хорошо разработанную раздельную DNS инфраструктуру для поддержки этого, я немедленно получил некоторые жалобы от нескольких VPN пользователей на то, что некоторые внутренние сервисы больше не доступны. Было не трудно определить, что дефектными внутренними сервисами были те, которые определены на внешним DNS сервере. Итак, проблема с разрешением старых VPN имен возникла снова и на этот раз она была реальной поломкой. Было интересно, что только некоторые VPN пользователи испытали это, хотя все они используют одинаковую конфигурацию, за исключением типа разделяемого устройства, подключаемого их рабочую станцию к кабельному/dsl модему. Также заметим, что различные ISP использовались для VPN клиентов и центральное подключение к ISA серверу.

Причина

Для понимания того, почему только некоторые VPN пользователи имели проблемы, давайте посмотрим на результат ipconfig и nslookup команд на работающем и неработающем VPN клиенте.

IPCONFIG

  • Windows IP Конфигурация
Элемент Работающий VPN Клиент Ошибочный VPN Клиент
Host Name (Host имя) PCSP02 PCEB02
Primary DNS Suffix (Суффикс первичного DNS) intranet.splab.net intranet.splab.net
Node Type (Тип узла) Hybrid Hybrid
IP Routing Enabled (Разрешена IP Маршрутизация) No No
WINS Proxy Enabled (Разрешен WINS Proxy) No No
DNS Suffix Search List (Список поиска DNS суффикса) intranet.splab.net splab.net intranet.splab.net splab.net

Как вы можете видеть в этой таблице сверху, Primary DNS Suffix и DNS Suffix Search List корректно настроены.

  • Соединение Ethernet адаптера локальной сети
Элемент Работающий VPN Клиент Ошибочный VPN Клиент
Connection-specific DNS Suffix (DNS суффикс, специфичный для соединения)
Description (Описание) Broadcom NetXtreme Gigabit Ethernet Realtek RTL8139/810x Family Fast Ethernet NIC
Physical Address (Физический адрес) 00-0B-5D-58-02-C2 00-03-0D-25-BD-12
Dhcp Enabled (Разрешен DHCP) Yes Yes
Autoconfiguration Enabled (Разрешена автоконфигурация) Yes Yes
IP Address (IP-адрес) 192.168.1.101 192.168.2.101
Subnet Mask (Маска подсети) 255.255.255.0 255.255.255.0
Default Gateway (Шлюз по умолчанию) 192.168.1.1 192.168.2.1
DHCP Server (DHCP сервер) 192.168.1.1 192.168.2.1
DNS Servers (DNS серверы) 195.238.2.22 195.238.2.21 192.168.2.1

Как вы можете видеть в этой таблице сверху, нет настроенного DNS суффикса, специфичного для соединения. Это – стандартная конфигурация для любого LAN адаптера. Однако здесь есть различия в DNS Серверах, связанных с LAN адаптером DHCP Сервера в разделяемом устройстве. Заметим, что оба пользователя используют одного ISP, но они используют различные типы разделяемого устройства. На работающем клиенте разделяемое устройство связано с DNS серверами ISP. На ошибочном VPN клиенте разделяемое устройство связано со своим собственным IP-адресом в качестве DNS сервера, означая, что эта коробка выступает в роли DNS proxy сервера.

  • PPP адаптер VPN Cevi NV
Элемент Работающий VPN Клиент Ошибочный VPN Клиент
Connection-specific DNS Suffix (DNS суффикс, специфичный для соединения) intranet.splab.net intranet.splab.net
Description (Описание) WAN (PPP/SLIP) Interface WAN (PPP/SLIP)
Interface Physical Address (Физический адрес) 00-53-45-00-00-00 00-53-45-00-00-00
Dhcp Enabled (Разрешен DHCP) No No
IP Address (IP-адрес) 172.31.1.11 172.31.1.8
Subnet Mask (Маска подсети) 255.255.255.255 255.255.255.255
Default Gateway (Шлюз по умолчанию) 172.31.1.11 172.31.1.8
DNS Servers (DNS серверы) 172.16.8.14 172.16.10.2 172.31.0.3 172.16.8.14 172.16.10.2 172.31.0.3
Primary WINS Server (Первичный WINS Сервер) 172.16.8.14 172.16.8.14
Secondary WINS Server (Вторичный WINS Сервер) 172.16.10.2 172.16.10.2

Как вы можете видеть в таблице сверху, DNS суффикс, специфичный для соединения, DNS Серверы и Первичный и Вторичный WINS Сервер – все они соответствующим образом связаны с VPN клиентом. Заметим, что в VPN профайле флаг Use default gateway on remote network (Использовать шлюз по умолчанию на удаленной сети) отмечен.

NSLOOKUP

  • Без VPN соединения
Работающий VPN Клиент Ошибочный VPN Клиент
C:\>nslookup Default Server: dnspool042.isp.belgacom.be Address: 195.238.2.22 C:\>nslookup Default Server: Address: 192.168.2.1

Как вы можете увидеть в таблице вверху, результаты оказались, как и ожидались. Для работающих VPN клиентов ISP сервер является возвращаемым, а для ошибочных VPN клиентов разделяемое устройство само является DNS сервером.

  • С VPN соединением
Работающий VPN Клиент Ошибочный VPN Клиент
C:\>nslookup *** Can’t find server name for address 195.238.2.22: Query refused *** Can’t find server name for address 195.238.2.21: Query refused Default Server: adc01.intranet.splab.net Address: 172.16.8.14 C:\>nslookup Default Server: Address: 192.168.2.1

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

Должно быть очевидно теперь, почему только некоторые VPN пользователи имеют проблемы. Из-за того, что PPP (RRAS) адаптер не имеет наивысший порядок в списке адаптеров, DNS серверы, связанные с PPP адаптером, не проверяются первыми. Следовательно, на ошибочных VPN клиентах все еще используется DNS сервер, связанный с LAN адаптером. Как следствие, любой запрос на внутренний ресурс (intranet.splab.net), для которого есть публичный DNS вход, также будет разрешен на публичный IP-адрес вместо внутреннего IP-адреса. Причина, почему это работает на других VPN клиентах, — это случайность. Если ISP, используемый VPN клиентом, будет принимать внешние запросы на свои DNS серверы, мы получим точно такую же проблему.

Обходной путь

Как мы уже знаем из прошлого, ручное помещение RRAS адаптера на вершину списка подключений в диалоге Advanced Settings (Расширенные Настройки) инструмента Network and Dial-up Connections (Сетевые и Коммутируемые Соединения) не решает эту проблему. После более тщательного изучения, я был направлен к статье Microsoft Knowledge Base 311218 — Cannot Change the Binding Order for Remote Access Connections. Эта статья содержит ключ к обходному пути. Тем не менее, запомните, что это все еще дефект в Microsoft OС и пока, как я знаю, у них нет планов его исправлять.

После ручного применения обходного пути, описанного в KB311218, на работающих и ошибочных VPN клиентах, мы протестировали их снова, и оба VPN клиента работали нормально. Заметьте, что перезагрузка была не обязательна и что изменения реестра срабатывали немедленно. Также, nslookup на обоих VPN клиентах теперь немедленно возвращает один из DNS серверов, привязанных к PPP адаптеру, как показано в таблице ниже:

Работающий VPN Клиент Ошибочный VPN Клиент
C:\>nslookup Default Server: zita.intranet.splab.net Address: 172.31.0.3 C:\>nslookup Default Server: adc01.intranet.splab.net Address: 172.16.8.14

После более тщательного тестирования мы обнаружили, что применение KB311218 не является однократным процессом. Каждый раз при изменении списка адаптеров, изменения реестра должны быть сделаны снова. Итак, настало время поиска метода для автоматизации этого процесса. Из-за того, что мы также расследовали CMAK (Connection Manager Administration Kit – Набор Администрирования Соединений) для распределения некоторых новых VPN настроек клиентам, мы думали, что скрипт в качестве действия до соединения должен быть хорошим решением. Наконец, мы обнаружили некоторые полезные сообщения на форумах ISAserver.org и списке обсуждения. Код в сообщениях выглядел основанным на скрипте, написанном Torgeir Bakken, Microsoft MVP в Scripting и WMI от Porsgrunn Norway.

Оригинальный скрипт можно найти по адресу http://www.ureader.com/message/89324.aspx и он приводится здесь с небольшими дополнительными комментариями:


' KB311218 - Cannot Change the Binding Order for Remote Access Connections
' ========================================================================
' VBScript that places the \Device\NdisWanIp entry on the top in the
' registry value Bind (multi-string) that is found under the key
' HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage\.
' If the entry already is at the top, no registry update is done.

Const HKLM = &H80000002

sComputer = "."   ' use "." for local computer

' Connect to WMI's StdRegProv class
Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" _
         & sComputer & "\root\default:StdRegProv")

' Define registry location
sKeyPath = "SYSTEM\CurrentControlSet\Services\Tcpip\Linkage"
sValueName = "Bind"

oReg.GetMultiStringValue HKLM, sKeyPath, sValueName, arValues

arValuesNew = Array()

For i = 0 To UBound(arValues)
   If i = 0 Then
      If LCase(arValues(i)) = "\device\ndiswanip" Then
         ' Entry is already first in the list, no point in continuing
         Exit For
      Else
         ' Put NdisWanIp in the first element in the new array
         ReDim Preserve arValuesNew(0)
         arValuesNew(0) = "\Device\NdisWanIp"
      End If
   End If

   ' Continue adding the rest of the elements to the new array
   If LCase(arValues(i)) <> "\device\ndiswanip" Then
      iCountNew = UBound(arValuesNew) + 1
      ReDim Preserve arValuesNew(iCountNew)
      arValuesNew(iCountNew) = arValues(i)
   End If
Next

' If there are elements to be found in the array, update the
' registry value
If UBound(arValuesNew) > -1 Then
   oReg.SetMultiStringValue HKLM, sKeyPath, sValueName, arValuesNew
End If

Однажды применив скрипт, приведенный выше, с помощью CMAK в качестве действия до соединения в VPN профиле, мы не получили простого объяснения испорченности разрешения имен. В качестве дополнительной выгоды, мы также объединили некоторые действия после соединения. Во-первых, мы должным образом настроили установки IE proxy для VPN соединения. Далее, мы применили некоторые критичные обновления, такие как Антивирусные описания и Microsoft Automatic Update к корпоративному WSUS серверу (команда %WinDir%\system32\wuauclt.exe /detectnow). Наконец, мы принудительно применили Политику Групп (команда %WinDir%\system32\gpupdate.exe /force /wait:0).

В ISA Server 2004 VPN Deployment Kit, раздел 14 Configuring VPN Quarantine есть подробный процесс того, как создать Connection Manager Profile (Профиль Управления Соединением). Итак, мы не будем его повторять здесь. Однако, мы покажем вам некоторые screenshot’ы, на которых вы определите упомянутые выше действия до и после соединения.

Настройка установок IE proxy для VPN соединения

Обойти vpn

Файл ProxyConfig.txt содержит настройки IE proxy для VPN соединения. Пример содержимого этого файла показан ниже:

[Automatic Proxy]
AutoProxyEnable=0
AutoConfigScriptEnable=1
AutoConfigScript=http://zita.intranet.splab.net:8080/array.dll?Get.Routing.Script
[Manual Proxy]
ProxyEnable=0

Пользовательские действия

Vpn 2003 проблема с днс

В качестве примера действия до соединения Change Binding Order for RAS (Изменения порядка связывания для RAS):

Переопределение dns по умолчанию vpn

В качестве примера действия после соединения Start Group Policy Update (Начало Обновления Политики Групп):

Как обойти днс?

Заключение

В этой статье мы обсудили проблему разрешения имен с VPN клиентами и соответствующую настройку раздельной DNS инфраструктуры. Несмотря на то, что этот дефект в Microsoft OС очевидно не будет исправлен, пока достаточное количество пользователей этого не потребует, существуют обходные возможности разрешить эту проблему. Обходной путь, обсуждаемый в этой статье, основан на статье Knowledge Base 311218, скрипт, написанный Torgeir Bakken, для автоматизации требуемых изменений реестра, и использует CMAK для соединения всех различных частей воедино.

Я надеюсь, вы получили удовольствие от этой статьи и нашли в ней что-нибудь, что сможете применить в своем собственном окружении. Если вы имеете какие-либо вопросы по теме, которую я обсуждал в этой статье, зайдите на http://forums.isaserver.org/m_2002004268/tm.htm и оставьте сообщение. Я буду проинформирован о вашем сообщении и отвечу на ваши вопросы, как только смогу. Спасибо!

www.isaserver.org







Смотрите также:

Tags: , , , , , , , ,

Readers Comments (Один комментарий)

  1. стассо:

    ребята, подскажите… я поймал через WI-FI сеть автоматически, но не как не подключиться, требует ключ безопасности сети или парольную фразу, что делать???




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]