Создание Site-to-Site VPN с помощью мастера подключения филиала брандмауэра ISA 2006 (часть 1)

Опубликовано: 11 Апреля, 2023

  • Создание Site-to-Site VPN с помощью мастера подключения филиала брандмауэра ISA 2006 (часть 3)
  • Создание Site-to-Site VPN с помощью мастера подключения филиала брандмауэра ISA 2006 (часть 4)
  • Создание Site-to-Site VPN с помощью мастера подключения филиала брандмауэра ISA 2006 (часть 5)
  • Создание Site-to-Site VPN с помощью мастера подключения филиала брандмауэра ISA 2006 (часть 6)
  • Создание Site-to-Site VPN с помощью мастера подключения филиала брандмауэра ISA 2006 (часть 7)

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

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

Обсудить эту статью

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

В этой серии статей об использовании Мастера подключения брандмауэра ISA Firewall Branch Office для создания VPN типа «сеть-сеть» я сначала рассмотрю процесс создания VPN-соединения «сеть-сеть» с помощью мастера, а затем после того, как По завершении мы создадим правила доступа, которые позволяют контроллеру домена филиала и клиентам-членам домена располагаться в филиале и использовать для этого минимальные привилегии.

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

Изображение 25334
фигура 1

В этом сценарии используются пять машин:

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

Мы также внесем изменения в конфигурацию DNS брандмауэра ISA Firewall филиала, чтобы он использовал DC филиала после завершения настройки.

Процедуры включают:

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

Примечания к Site-to-Site VPN

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

Обсудить эту статью

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

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

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

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

Запомнить разрешение имени

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

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

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

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

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

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

Для получения дополнительной информации о том, как это сделать, ознакомьтесь со статьей Stefaan Pouseele.

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

VPN-протоколы

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

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

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

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

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

Если это руководство не относится к вашему сценарию развертывания, вам придется вернуться к своему пониманию IPSec и убедиться, что все параметры IPSec верны на обеих сторонах. Даже если вы получите правильные параметры IPSec с обеих сторон, вы можете столкнуться с проблемами с VPN-шлюзами, не соответствующими RFC. Например, я слышал несколько сообщений о том, что брандмауэры Sonicwall не работают с VPN-шлюзом брандмауэра ISA, потому что они не соответствуют RFC и не позволяют исходному порту для IKE быть чем-либо, кроме UDP 500. Поскольку брандмауэр ISA совместим с RFC, он может использовать альтернативный порт и, следовательно, не подключаться к устройству Sonicwall. В случае Sonicwall может быть обновление программного обеспечения, чтобы сделать устройство совместимым с RFC.

Другая распространенная проблема заключается в том, что учетные записи пользователей VPN-соединения «сайт-сайт» неправильно настроены для соответствия именам интерфейсов вызова по требованию. Когда это происходит, бывают случаи, когда может показаться, что соединение между сайтами VPN установлено, но трафик не проходит через VPN-шлюзы из одной сети в другую, или может показаться, что соединения разрешены из одной сети, но не из другой. другая сеть. Причина этого в том, что VPN-соединение между сайтами не было установлено. Вы можете убедиться в этом, открыв консоль RRAS и проверив узел «Клиенты удаленного доступа» на левой панели консоли RRAS. Если вы видите клиентское подключение удаленного доступа к удаленному VPN-шлюзу, значит, вы знаете, что было выполнено клиентское VPN-подключение удаленного доступа, а не VPN-подключение между сайтами. Клиентские подключения удаленного доступа не позволяют маршрутизироваться через VPN-шлюзы.

Что касается моей рекомендации, я всегда рекомендую администраторам брандмауэра ISA использовать L2TP/IPSec с аутентификацией машинного сертификата. Однако в большинстве случаев во время первоначального развертывания я настраиваю VPN типа «сеть-сеть» с использованием предварительно общего ключа, чтобы повысить доверие к решению и устранить некоторые сложности, присущие PKI. После того, как решение Site-to-Site VPN завершит короткий период адаптации, я переведу клиента на аутентификацию с помощью сертификата машины и откажусь от предварительно общих ключей.

Обсудить эту статью

Резюме

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

  • Создание Site-to-Site VPN с помощью мастера подключения филиала брандмауэра ISA 2006 (часть 3)
  • Создание Site-to-Site VPN с помощью мастера подключения филиала брандмауэра ISA 2006 (часть 4)
  • Создание Site-to-Site VPN с помощью мастера подключения филиала брандмауэра ISA 2006 (часть 5)
  • Создание Site-to-Site VPN с помощью мастера подключения филиала брандмауэра ISA 2006 (часть 6)
  • Создание Site-to-Site VPN с помощью мастера подключения филиала брандмауэра ISA 2006 (часть 7)