Blog of Khlebalin Dmitriy

(Дорогу осилит идущий…)

Установка и настройка Project Server and Share Point Server 2007 (часть 1).

Вот наконец появилось немного времени. И пришло время написать об установке и настройке вышеперечисленного продукта. Данная инструкция была написана не мной (по моему в свое время была прислана мне моим другом сисадмином из-за бугра), по этому она будет на англицком. Но хочется сказать, что я много раз разворачивал данный продукт по этой инструкции, и все работало как часы. По этому читаем:

Before proceeding, here are a couple of assumptions:

 1. You have access to all of the required software:

  • Microsoft Virtual PC with SP1 (виртуальная машина не обязательна, если ставите сразу на жедезку)
  • Windows Server 2003 (sp2+all updates)
  • SQL Server 2005 with SP1 (а лучше на данный момент sp3)
  • Project Server 2007 (а лучше на данный момент sp1)
  • Project Professional 2007
  • Microsoft Office 2007 (sp2)
  • Internet access

2. This will not be a lesson on how to use Virtual PC; I’ll assume that you are already familiar with the tool and are capable of building a basic virtual machine using Windows Server 2003.

 That being said… let’s dive in!

 Part 1: Getting Started, Installing IIS, and Installing .NET Framework 2.0

 Start by building a VPC “base image” with a clean installation of Windows Server 2003

VPC settings:

Memory: set a value which is at least half of the physical memory on your host machine

Networking: 1 adapter, mapped to a network adapter on your local machine

 Install Virtual Machine Additions:

 VPC Actions menu > Install or Update Virtual Machine Additions

 Perform Windows Update inside the virtual machine

 Select Start > All Programs > Windows Update

 Follow the instructions and install all available updates, including Internet Explorer 7

11

Install IIS with .NET Framework 2.0

 Select Start > Control Panel > Add or Remove Programs:

22

In the Add or Remove Programs dialog box, click the Add / Remove Windows Components button on the left side:

33

In the Windows Components Wizard dialog box, highlight the Application Server option, then click the Details button:

44

In the Application Server dialog box, highlight the Internet Information Services (IIS) option, then click the Details button:

55

In the Internet Information Services (IIS) dialog box, highlight the World Wide Web Service option, then click the Details button:

66

In the World Wide Web Service dialog box, select the Active Server Pages option, the Server Side Includes option, and the World Wide Web Service option, then click the OK button:

77

Click OK twice more to close the dialog boxes and return to the Windows Components Wizard dialog box:

88

Scrolling down the list of options, locate and deselect the Internet Explorer Enhanced Security Configuration option:

99

Scrolling a bit further down the list of options, locate and select the Microsoft .NET Framework 2.0 option:

10

Click the Next button to begin the IIS installation; you may be asked to insert the Windows Server installation media.

 

When the installation is complete, click the Finish button 

Click the Next button to begin the IIS installation; you may be asked to insert the Windows Server installation media.

 When the installation is complete, click the Finish button

111

 

Продолжение следует. (To be continued…). Всем удачи.

 

21.09.2009 Posted by | ms project and sharepoint | Комментарии к записи Установка и настройка Project Server and Share Point Server 2007 (часть 1). отключены

Tiny Firewall Pro (Tiny FP).

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

Как вы уже успели заметить в заголовке статьи- это Tiny Firewall Pro.

Вопреки своему названию (tiny в переводе с английского «крохотный») продукт системной безопасности основательно проработан компанией Tiny Software и примечателен по многим параметрам, особенно системой контроля пользовательских приложений, пожалуй, даже более гибкой и фундаментальной, чем у SSF. Осуществляется контроль за запуском приложений и их дочерних процессов; проверяется целостность файлов; пресекаются разнообразные попытки вторжения в адресное пространство стороннего процесса; отслеживается загрузка dll-библиотек; проводится анализ OLE и COM-объектов, а также мониторинг множества других операций. Подтверждением надежности системы контроля служат тесты. Ни один трюк не остался незамеченным.

Еще одной примечательной чертой Tiny FP стал модуль Tracklog Analyzer, ведущий журналирование наблюдаемых операций. По истории запуска процессов, загрузки dll-библиотек, модификаций Реестра, установления сетевых соединений и тому подобных действий можно быстро восстановить картину развития инцидентов. Данная возможность будет очень полезна системным администраторам, офицерам безопасности и даже обычным параноикам.

Как брандмауэр Tiny FP также довольно привлекательна. Она обеспечивает контроль на сетевом уровне и уровне приложений, и кроме того, включает в себя систему обнаружения сетевых вторжений, построенную на базе Snort IDS.

В целом Tiny FP очень интересная и качественная система защиты. Но с учетом обширности ее настроек и англоязычного интерфейса, пожалуй, работа с ней может вызвать сложности у неподготовленного пользователя.

Помимо Tiny FP хотел бы отметить еще одну разработку компании Tiny Software — Host Security Server 2005 (HSS), представляющую собой центр управления системами персональных защит (на базе Tiny FP) подчиненных рабочих станций. Также HSS выполняет функции сбора и обработки статистики. Это кроссплатформное приложение, написанное на Java. Так что работает оно не только в Windows, но и в Linux, Unix и Solaris. Требуется пакет Java 2 Standard Edition 1.4.2.

Небольшое примечание для экспериментаторов: в Windows пакет HSS устанавливается как сервис. Для его функционирования в список системных переменных необходимо внести запись «JAVA_HOME» со значением «c:\j2sdk1.4.2_07\jre» (путь к установленному пакету Java), а также добавить строку «%JAVA_HOME%\bin» к значению переменной Path.

После успешного запуска сервиса HSS управляется посредством веб-терминала. Для подключения к консоли администратора в адресной строке браузера надо набрать адрес «https://localhost/». По умолчанию имя входа — «admin», пароль — «admin».

Разработки специалистов Tiny Software, Inc. вызывают уважение своим профессионализмом, так же как и ценой: стоимость лицензии Host Security Server 2005 с поддержкой 20 клиентских систем — 1499 долл. Эта цена соизмерима с ценой серверного программного обеспечения компаний Microsoft и Symantec.

2

Цена на мой взгляд конечно запредельная, я бы конечно предпочел ISA в данном случае, но как альтернатива, тоже не плохо . Но в инете валяется масса кряков. По этому велком.

Имеет три состояния работы:

  1. Сеть полностью недоступна — полезно тем, у кого выделенка. Например, когда ты пошел есть пирожки, к тебе никто не сможет проникнуть, т.е. будешь полностью уверенным в том, что придешь туда, откуда ушел =).
  2. Файрвол будет тебя спрашивать при каждом подключении к порту: разрешить или нет. Но если ты сидишь, допустим, в ICQ, у тебя быстро сдадут нервы. Чтобы этого не произошло, придумана галочка Don’t ask me again: ставишь галку и разрешаешь или запрещаешь действие — и все. Больше подобных вопросов не будет.
    Хочу сделать небольшое отступление по поводу ссылок на скачивание – возможно, к моменту выхода статьи их уже закроют\поменяют, тогда советую воспользоваться сайтом www.free-firewall.org или сходить на официальные сайты производителей.
  3. Все, что не запрещено — разрешено ;). Так можно сказать о третьем режиме работы проги.

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

Все попытки трояна на выход в Сеть Tiny сразу же пресекал и оставил самые хорошие впечатления.

Итог: Для обычного домашнего пользования очень и очень неплох. В настройках разберется даже младенец. К полезностям можно добавить то, что при работе под NT может писать все в syslog =). Сисадмины в восторге!

Хочется добавить, что данный продукт устанавливается как на рабочую станцию так и на серваки под управлением win2003. Так же меня реально породовал on-line монитор соединений, очень читабельный.

Из минусов, могу выделить следующее: это достаточно не простая настройка (для обычного пользователя пользоваться им будет достаточно затруднительно) , это конечно не Outpost Firewall с его тремя кнопками. А с точки зрения сисадмина-это просто реальный продукт. Что еще понравилось, это возможность использования с различными продуктами (например в свое время мы юзали е в связке Wingate 5.0+Tiny) нам очень понравилось.

Мнение других пользователей, о нем можно прочесть  например здесь: http://ksdi.ru/forum/index.php?topic=453.30 

К сожалению последнюю версию, которую мне довелось видеть , была 6.5 build 128 по моему. Искал версии по новее, но их нет, по этому сделал вывод, что данный проджект наверно уже закрыт. 

Всем удачи!

21.09.2009 Posted by | about soft | Комментарии к записи Tiny Firewall Pro (Tiny FP). отключены

Создание VPN Site-to-Site в ISA 2006 (Часть 1).

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

Одним из улучшений сервера 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. 

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

  • Выделенный сервер хранения настроек (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.
 
Всем удачи!

21.09.2009 Posted by | ms isa 2006 | Комментарии к записи Создание VPN Site-to-Site в ISA 2006 (Часть 1). отключены