Monday, December 11th, 2017

Создание VPN по схеме Site-to-Site с помощью Мастера настройки соединения с филиалом сервера ISA 2006 (Часть 1)

Published on Февраль 11, 2009 by   ·   Комментариев нет

Сценарий с контроллером домена филиала

Одним из улучшений сервера ISA 2006 Enterprise Edition стал мастер настройки соединений с филиалом. В состав сервера ISA 2000 входил мастер создания VPN-соединений по схеме site-to-site, который облегчал создание VPN-соединений. Однако, в сервер ISA 2004 этот мастер не вошел, и у всех стали возникать нескончаемые трудности, связанные с созданием VPN-соединений между двумя ISA-серверами. Команда разработчиков ISA-сервера услышала наши призывы, и мы получили прекрасный мастер создания VPN-соединений, который теперь называется Мастер настройки соединения с филиалом (Branch Office Connectivity Wizard).

Если вы хотите ознакомиться с остальными частями этой статьи, пожалуйста, прочитайте:

Для облегчения процесса создания соединений Мастер настройки соединения с филиалом использует информацию, хранящуюся в файле настроек удаленного сайта, который создается в главном офисе. После окончания работы с мастером вы можете перенести созданный файл на ISA-сервер филиала и создать VPN-соединение с его стороны. Помимо создания VPN-соединения мастер дает возможность сделать ISA-сервер филиала членом домена, что является лучшей рекомендацией по использованию ISA-сервера, поскольку общая безопасность ISA-сервера как члена домена значительно выше, чем безопасность автономного ISA-сервера.

В данной статье об использовании Мастера настройки соединения с филиалом для создания VPN-соединения по схеме site-to-site я опишу весь процесс создания такого типа соединения с помощью мастера, а после создания соединения мы создадим правила доступа, которые будут разрешать соединения контроллера домена филиала и клиентов членов домена, расположенных в филиале, с использованием минимальных привилегий.

Ниже изображена общая схема примерной сети, которую мы будем использовать в нашей статье.

Схема подключения сервера

Рисунок 1

В данной схеме мы будем использовать пять компьютеров:

  • Выделенный сервер хранения настроек (css2006.msfirewall.org) Выделенный сервер хранения настроек будет использоваться как сервер хранения настроек массива ISA-сервера Enterprise Edition. Мы будем использовать два массива: один для главного офиса и один для филиала. Мы не сможем поместить ISA-серверы главного офиса и филиала в один массив, поскольку адреса соединений внутри массива должны находиться в одной подсети, а это невозможно, если члены массива находятся в филиале. Однако мы можем применять политики предприятия на все массивы ISA-серверов
  • Контроллер домена (dc.msfirewall.org) Все компьютеры в данной схеме принадлежат одному домену: msfirewall.org.
  • ISA-сервер главного офиса (isa2006se.msfirewall.org) Это ISA-сервер главного офиса. Он принадлежит массиву Main. Он является членом домена и имеет внутренний и внешний интерфейс.
  • ISA-сервер филиала (isa2006branch.msfirewall.org) Это ISA-сервер филиала, который будет сделан членом домена с помощью мастера настройки соединения с филиалом. На компьютере установлена система Windows Server 2003. Изначально компьютер является изолированным сервером. Затем на нем будет установлен сервер ISA 2006. После этого мы запустим Мастер настройки соединения с филиалом, который создаст VPN-соединение и присоединит компьютер к домену. Также мастер соединит ISA-сервер филиала с массивом филиала, настроенным на сервере хранения настроек главного офиса.
  • Контроллер домена филиала Это контроллер домена филиала, который пользователи филиала используют для аутентификации. Мы создадим правила доступа, которые будут разрешать контроллеру домена соединяться с контроллером домена главного офиса.

Кроме этого мы выполним изменения в DNS ISA-сервера филиала для того, чтобы тот после окончания настройки использовал контроллер домена филиала.

Выполняемые процедуры:

  • Настройки DNS-сервера главного офиса на отклонение динамического обновления и добавление статических DNS-записей для имен массивов и ISA-сервера филиала
  • Установка сервера хранения настроек
  • Установка служб брандмауэра на ISA-сервер главного офиса
  • Создание VPN в главном офисе
  • Создание файла ответов, который далее будет использоваться в филиале
  • Установки сервера хранения настроек и служб брандмауэра на ISA-сервер филиала
  • Запуск Мастера настройки соединения с филиалом на ISA-сервера филиала
  • Создание правил доступа, разрешающих междоменные соединения между контроллерами домена главного офиса и филиала
  • Установка контроллера домена в филиале
  • Внесение изменений в DNS филиала для того, чтобы ISA-сервер филиала использовал контроллер домена филиала

Замечания по VPN-соединениям по схеме Site-to-Site

Одним из самых востребованных разделов сайта ISAserver.org является раздел, посвященный проблемам VPN-соединений. Я думаю, что причина в том, что многие не понимают, как работают VPN-соединения по схеме Site-to-site, и какие основные требования их использования.

VPN-шлюз — это VPN-маршрутизатор

Если ISA-сервер настроен как VPN-шлюз, он становится маршрутизатором к сетям, расположенным за удаленным VPN-шлюзом. Например, предположим, что главный офис располагается в подсети 10.1.0.0/16, а филиал использует IP-адреса 10.2.0.0/16. Если узлу главного офиса необходимо соединиться с удаленной подсетью (10.2.0.0/16), это можно сделать только через VPN-шлюз главного офиса.

Для того, чтобы такая схема работала, клиенты главного офиса должны быть настроены на использование в качестве шлюза того адреса, который «знает» маршрут в сеть 10.2.0.0/16. Естественно, ISA-сервер знает такой маршрут, поэтому клиенты, настроенные на использование ISA-сервера в качестве шлюза по умолчанию, смогут соединиться с удаленной сетью через VPN-шлюз ISA-сервера. Системы, не использующие ISA-сервер в качестве шлюза по умолчанию, должны быть настроены на использование LAN-маршрутизатора, который использует таблицу маршрутизации для перенаправления соединений в подсеть ID 10.2.0.0/16 на IP-адрес ISA-сервера.

Я встречаю множество вопросов о том, как решить проблему, когда локальный и удаленный сайты используют одну подсеть. Обычно хотят знать, есть ли способ решения проблемы. А ответ состоит в том, что такого способа, с точки зрения маршрутизации, нет, поскольку системы клиентов соединяются с адресами локальной подсети, и соединения никогда не будут перенаправлены на адрес шлюза. Зачем же переадресовывать соединения к адресу локальной подсети, если это не требуется и не нарушает никакие принципы маршрутизации TCP/IP?

Разрешение имен

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

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

Разрешение Интернет-узлов – это отдельная задача. Некоторые организации позволяют клиентам самим разрешать имена Интернет-узлов (что требуется при использование клиентов SecureNET). Другие организации желают жестче контролировать разрешение имен Интерне-узлов, и потому только ISA-сервер может производить разрешение от лица клиентов.

Существует множество методов разрешения имен Интернет-узлов, и мне трудно выделить какой-либо из них как самый лучший. Однако, чаще всего я настраиваю ISA-сервер и узлы корпоративной сети на использование встроенного DNS-сервера Active Directory, а затем настраиваю этот DNS-сервер на использование устройства разрешения имен Интернет-узлов.

Одна из важных проблем при разрешении имен в филиале связана с WPAD-записями. Как вы знаете, клиенты Web-прокси и брандмауэра используют записи типа WPAD для автоматического поиска локальных адресов ISA-сервера для использования их при соединении с ISA-сервером. Проблема может возникнуть при использовании единой инфраструктуры DNS для главного офиса и филиала, т.к. вы не можете использовать одну WPAD-запись для всех мест расположения при условии, что все узлы соединяются со своим локальным ISA-сервером, что и происходит в этом случае. С другой стороны, если вы хотите, чтобы все узлы соединялись с Интернетом только через ISA-сервер главного офиса, тогда использование одной записи типа WPAD возможно.

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

И, наконец, проблема с DNS, которую тоже следует принять к сведению: эффект динамической DNS-регистрации VPN-шлюзов. При включенной DDNS на DNS-сервере RAS-интерфейс ISA-сервера будет регистрировать себя в DNS и создавать проблемы соединения для клиентов Web-прокси и брандмауэра, поскольку они соединяются с RAS-интерфейсом, а не с реальным LAN-адресом ISA-сервера. По этой причине в данной статье мы не будем использовать на наших DNS-серверах DDNS при создании VPN-шлюзов, а затем мы посмотрим, можно ли отключить DDNS-регистрацию на интерфейсе соединения по запросу с помощью консоли RRAS.

VPN-протоколы

ISA-сервер поддерживает три VPN-протокола: IPSec в туннельном режиме, L2TP/IPSec и PPTP.

Поддержка IPSec в туннельном режиме была представлена в сервере ISA 2004, чтобы ISA-сервер мог использоваться в качестве VPN-шлюза совместно с VPN-шлюзами сторонних производителей. Это единственный вариант использования IPSec в туннельном режиме, поскольку он считается наименее защищенным и наименее производительным в сравнении с L2TP/IPSec. Кроме того, поддержка маршрутизации для IPSec в туннельном режиме неудобна, трудоемка и ограничена.

L2TP/IPSec –это предпочтительный протокол для VPN при наличии на обоих концах соединения ISA-серверов или при использовании VPN-шлюзов с поддержкой L2TP/IPSec сторонних производителей. Поскольку L2TP/IPSec поддерживает открытые ключи, в безопасном окружении вы можете использовать аутентификацию с помощью сертификатов, как для учетных записей компьютеров, так и для учетных записей пользователей при аутентификации VPN-туннеля. Хотя такая схема достаточно защищена, в большинстве компаний, в которых я работал, предпочитают использовать не- EAP аутентификацию для интерфейса соединения по запросу для учетных записей пользователей, и аутентификацию с помощью сертификатов для учетных записей компьютеров.

PPTP – это самый простой протокол для поддержки VPN-соединений. Никаких сертификатов не требуется, а большинство администраторов ISA-сервера считают, что PPTP “просто работает ”. Недостаток PPTP в том, что он менее защищен, чем L2TP/IPSec, поскольку учетные данные посылаются по нешифрованному каналу. Поэтому уровень безопасности PPTP-соединений напрямую зависит от сложности паролей. Кроме того, PPTP не предоставляет функций строгого выполнения задач и защиты от повторов, что дает использование L2TP/IPSec.

Использовать IPSec в туннельном режиме для связи с VPN-шлюзами сторонних производителей не так-то просто. Вначале ознакомьтесь с информацией по использованию ISA-сервера совместно с VPN-шлюзами сторонних производителей, представленной на сайте Microsoft.

Если это руководство ничего не имеет общего с вашей схемой внедрения, вам придется полагаться только на собственные знания о протоколе IPSec. Убедитесь, что все параметры IPSec корректно выставлены на обоих концах соединения. Однако, даже если параметры верны, у вас могут возникнуть проблемы с RFC-несовместимыми VPN-шлюзами. К примеру, я встречал отзывы о брандмауэрах Sonicwall, которые не работали с VPN-шлюзами ISA-сервера, поскольку они RFC–несовместимы и не разрешают использовать для IKE (Internet Key Exchange – Обмен ключами Интернета) отличный от 500 порт UDP. Поскольку ISA-сервер является RFC-совместимым, он может использовать альтернативный порт и потому не соединяется с устройством Sonicwall. В случае с Sonicwall для того, чтобы сделать устройство RFC-совместимым, можно попробовать найти обновление программного обеспечения.

Другой распространенной проблемой является то, что учетные записи VPN-пользователей не настроены на соответствие именам на интерфейсе соединения по запросу. В этом случае может случиться, что соединение VPN есть, но никакие данные через шлюз не проходят, или же может появиться впечатление, что соединения из одной сети разрешены, а из другой нет. Причина в том, что VPN-соединение не было установлено. Это можно проверить, открыв консоль RRAS и отметив узел Remote Access Clients (Клиенты удаленного доступа) в левой части консоли. Если вы увидите, что соединения клиента удаленного доступа с VPN-шлюзом есть, это значит, что VPN-соединение клиента удаленного доступа было выполнено, но не создалось VPN-соединение site-to-site. Соединения клиентов удаленного доступа не могут быть маршрутизированы через VPN-шлюз.

Я всегда рекомендую использовать L2TP/IPSec с аутентификацией компьютеров с помощью сертификатов. Однако, в большинстве случаев во время первичного внедрения я устанавливаю VPN по схеме site-to-site с помощью общего ключа для того, чтобы построить надежное решение и избежать сложностей, связанных с PKI (Public Key Infrastructure – Инфраструктура открытого ключа). После небольшой утряски работы VPN я перевожу пользователей на использование аутентификации компьютеров с помощью сертификатов и убираю общие ключи.

Выводы

Это первая часть статьи о создании VPN по схеме site-to-site с помощью мастера настройки соединения с филиалом. В данном сценарии в главном офисе и филиале мы используем ISA-серверы и контроллеры домена. Мы рассмотрим, как использовать мастер настройки соединения с филиалом, входящий в состав сервера ISA 2006 Enterprise Edition, для создания соединения, а затем изменим правила доступа, DNS и другие параметры настройки для полной поддержки VPN-соединений по схеме site-to-site. Увидимся!

www.isaserver.org


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

Tags: , , , ,

Readers Comments (Комментариев нет)




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

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 – часть ... [+]