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

В прошлом я много читал о пользователях 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 Конфигурация

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

• Соединение Ethernet адаптера локальной сети

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

• PPP адаптер VPN Cevi NV

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

NSLOOKUP

• Без VPN соединения

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

• С VPN соединением

Как вы можете увидеть в таблице вверху, этот результат довольно интересен. Во-первых, должно быть ясно, что 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 адаптеру, как показано в таблице ниже:

После более тщательного тестирования мы обнаружили, что применение 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 соединения

Файл 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

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

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

В качестве примера действия после соединения 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

• Vpn сервер Windows 2008
• Планировщик заданий Windows server 2008
• Посмотреть фрагментацию таблиц ms sql
• Установить сертификат на компьютер
• Локальная группа размеры

Tags: bind, dns, ISA Server, nat, ppp, proxy, redirect, search, vpn