TECH DOC

Категории

OS Windows [17]
ISA [3]
Sharepoint [1]
Exchange Server [3]
System Center [1]
Другие программные продукты [2]
C# [0]

Map

Теги

Статистика

Онлайн всего: 1
Гостей: 1
Пользователей: 0

Поделиться

Каталог статей

Главная » Статьи » Windows » ISA

Дополнительные настройки ISA-сервера: Схема "Сеть за сетью"
Мультисетевые функции сервера ISA 2006 значительно отличаются от того, что было в сервере ISA 2000. При работе с сервером ISA 2000 сети подразделялись только на доверительные и недоверительные. Также существовала необходимость создания отношений между доверительными сетями и Таблицей локальных адресов (Local Address Table - LAT). Отдельно эти две составляющие иметь нельзя. Доверительные сети определяются сетями, указанными в LAT: все сети, не включенные в LAT считаются недоверительными. Соединения между узлами LAT (узлы, чьи IP-адреса находятся в LAT) не затрагиваются механизмами сервера ISA 2000 проверки на уровне обычных пакетов и приложений.
 
В сервере ISA 2006 нет LAT, но здесь представлена концепция нескольких сетей, основным принципом которой является предположение, что по умолчанию нет доверительных сетей, и все соединения, проходящие через ISA-сервер, подвергаются обработке механизмами проверки обычных пакетов и проверки на уровне приложений. Таким образом, достигается более высокий уровень безопасности и контроля доступа по сравнению с тем, что было при использовании сервера ISA 2000. Устранение отношений между LAT и доверительными сетями дает администраторам сервера более серьезный уровень контроля соединений между сетями.
 

Объект Network (Сеть) (сеть ISA-сервера) – одна из ключевых концепций, важных для понимания при работе с ISA-сервером. Вот основные моменты, относящиеся к сети ISA-сервера:
 
Интерфейс может принадлежать только одной сети
Интерфейс не может принадлежать двум или более сетям
ISA-сервер может работать с столькими сетевыми картами, сколько поддерживает аппаратное обеспечение
Все IP-адреса, расположенные за сетевым интерфейсом, являются частью одной сети
Все IP-адреса, определенные на ISA-сервере, считаются Защищенными сетями (Protected Networks)
Любой IP-адрес, не определенный на ISA-сервере, считается частью внешней сети по умолчанию
 
Сети VPN-клиентов и Изолированных VPN-клиентов создаются виртуально или динамически, и потому адреса добавляются и удаляются в эти сети при каждом соединении или отсоединении VPN-клиентов.
 

Сеть, напрямую соединенная с отдельным интерфейсом, может считаться корнем отдельной сети ISA-сервера. Например, если вы используете сеть 10.0.0.0/16 как внутреннюю сеть по умолчанию, то другими сетями за ней будут 10.1.0.0/16, 10.2.0.0/16 и т.д. Вы можете определить всю сеть, связанную с данным адаптером, как 10.0.0.0/8, и тогда в нее будут входить все сети за интерфейсом.
 

Сеть, напрямую соединенная с отдельным интерфейсом, может считаться корнем отдельной сети ISA-сервера. Например, если вы используете сеть 10.0.0.0/16 как внутреннюю сеть по умолчанию, то другими сетями за ней будут 10.1.0.0/16, 10.2.0.0/16 и т.д. Вы можете определить всю сеть, связанную с данным адаптером, как 10.0.0.0/8, и тогда в нее будут входить все сети за интерфейсом.
 
 
 
 
 
 
Пример сети внутри сети ISA-сервера
 

На Рисунке 1 изображена базовая модель тестовой сети, которую я буду использовать для иллюстрации тех задач, которые возникают при работе с настройками сети внутри сети. Подсетью является сеть 10.0.0.0/24, а сетью за Checkpoint-сервером является 10.10.10.0/24. Я использовал Checkpoint-сервер только потому, что он уже был у меня установлен, однако, вы можете использовать любое устройство или маршрутизатор с функцией фильтрации пакетов. Вы можете заменить Checkpoint-сервер любым аппаратным маршрутизатором, коммутатором 3-го уровня или даже VPN-шлюзом, соединяющим какую-либо сеть с одной из защищенных сетей ISA-сервера.

Рисунок 1: Внутренняя архитектура «сети внутри сети»
 

Просто для напоминания: SecureNAT-клиент – это любой компьютер, настроенный со шлюзом по умолчанию, переводящим соединения с Интернетом на ISA-сервер. Если SecureNAT-клиент располагается в сети, напрямую соединенной с ISA-сервером, то шлюзом по умолчанию SecureNAT-клиента будет IP-адрес ближайшего интерфейса ISA-сервера. Если SecureNAT-клиент расположен в сети, отличной интерфейса ISA-сервера, тогда адресом шлюза по умолчанию для SecureNAT-клиента будет адрес шлюза, переадресовывающего запросы в Интернет на ISA-сервер.
 

На Рисунке 1 узел с адресом 10.0.0.5/24 использует в качестве шлюза по умолчанию адрес 10.0.0.1, поскольку он находится в той же подсети, что и локальный интерфейс ISA-сервера. У узла с адресом 10.10.10.224 шлюзом по умолчанию является адрес 10.10.10.1, который переадресует запросы в Интернет на локальный интерфейс Checkpoint-сервера. Шлюзом по умолчанию Checkpoint-сервера является адрес 10.0.0.1, т.е. интерфейс ISA-сервера, находящийся в одной сети с Checkpoint-сервером. Checkpoint-сервер переадресует запросы в Интернет на ISA-сервер, а ISA-сервер отсылает их на узлы Интернета.
 

Клиент брандмауэра работает немножко по-другому: он настроен на IP-адрес или имя ISA-сервера. Программное обеспечение клиента обрывает все TCP и UDP соединения, инициированные Winsock-приложениями компьютера клиента, и отправляет их напрямую на IP-адрес приемника клиента брандмауэра на интерфейсе ISA-сервера, находящегося в одной сети с клиентом.
 

Клиент брандмауэра работает немножко по-другому: он настроен на IP-адрес или имя ISA-сервера. Программное обеспечение клиента обрывает все TCP и UDP соединения, инициированные Winsock-приложениями компьютера клиента, и отправляет их напрямую на IP-адрес приемника клиента брандмауэра на интерфейсе ISA-сервера, находящегося в одной сети с клиентом.
 

Хотя все эти различия кажутся простыми и понятными, при работе со схемой «сеть внутри сети» следует принять во внимание несколько моментов. Если вы не поймете эти различия, эта схема не будет работать.
 

На Рисунке 2 показаны пути запросов и откликов между SecureNAT-клиентом и сервером внутри сети (сети внутри сети). Когда SecureNAT-клиент из подсети отсылает запросы соединения к узлу во внутренней сети, вначале запрос отсылается на интерфейс ISA-сервера, находящийся в той же сети, что и SecureNAT-клиент. ISA-сервер переадресует запрос на интерфейс Checkpoint-сервера, который знает маршрут во внутреннюю сеть, а Checkpoint-сервер, в свою очередь, переадресует соединение на необходимый узел. Ответ проходит через Checkpoint-сервер, а далее идет напрямую к SecureNAT-клиенту, поскольку Checkpoint-сервер может переадресовывать ответы прямо клиенту, и для этого ему не нужен адрес шлюза.
 
 
Рисунок 2: Соединения SecureNAT-клиента с сетью внутри сети
 

Теперь рассмотрим, как работает клиент брандмауэра. На Рисунке 3 показаны два варианта: первый – клиент брандмауэра соединяется с не-локальной сетью. Не-локальной сетью является любая сеть, отличная от сети компьютера клиента. Не-локальная сеть может находиться как в Интернете, так и за иным интерфейсом ISA-сервера. Второй вариант показывает соединение клиента брандмауэра с локальной сетью, т.е. с той же сетью, в которой находится и клиент, отправляющий запрос.
 

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

Во втором варианте компьютер клиента брандмауэра находится в той же сети, что и локальный интерфейс ISA-сервера, но в этот раз RDP-соединение происходит с узлом, находящимся в «сети внутри сети».
 

Здесь могут возникнуть проблемы. Программное обеспечение клиента брандмауэра автоматически скачивает список всех IP-адресов, определенных для сети, к которой принадлежит клиент. В нашем примере сеть ISA-сервера клиента брандмауэра содержит все адреса из диапазонов 10.0.0.0/24 и 10.10.10.0/24. Программное обеспечение клиента брандмауэра сравнивает адрес назначения в запросе на соединение с адресами, определенными для сети, к которой принадлежит клиент. Если адрес назначения не из локальной сети, соединение переадресуется на локальный интерфейс ISA-сервера, и ISA-сервер создает соединение с не-локальной сетью. Однако, если адрес назначения является адресом узла в той же сети, в которой находится и клиент, программное обеспечение клиента игнорирует соединение.
 
Если клиент игнорирует соединение, узел назначения должен находиться в одной сети с клиентом или компьютер клиента брандмауэра одновременно должен быть настроен как SecureNAT-клиент со шлюзом по умолчанию, способным маршрутизировать соединения в сеть назначения. Во втором варианте клиент брандмауэра также является и SecureNAT-клиентом.
 

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

Обратите внимание, что если правило доступа не требует аутентификации, то второй вариант будет работать, поскольку клиент брандмауэра сможет откатиться к настройкам SecureNAT-клиента и соединиться с узлом внутренней сети. Конечно, целью использования клиента брандмауэра является разрешение аутентификации на основе пользователей/групп.
 
 
 

Рисунок 3: Пути клиента брандмауэра через локальные и не-локальные сети
 

Записи файла журнала (Рисунок 4) показывают соединения с удаленным RDP-сервером и RDP-сервером, находящимся в той же самой сети. Вторая и третья строка в журнале показывают RDP-соединения к узлу другой сети. Клиент брандмауэра определяет, что соединение происходит с узлом из другой сети, прерывает соединение и отсылает его вместе с учетными данными на ISA-сервер. Информацию пользователя можно увидеть в столбце Client Username (Имя пользователя клиента), что подтверждает, что соединение управлялось клиентом брандмауэра.
 

На 5, 8 и 9 строках журнала вы видите попытки RDP-соединения с компьютером во внутренней сети, которая является частью той же сети, где находится и компьютер клиента брандмауэра. Поскольку узел назначения находится в одной сети с клиентом, клиент игнорирует запрос, и начинает работу SecureNAT-клиент. Вы видите, что правило, разрешающее соединения с внутренней сетью, отклонило соединение, поскольку правило было настроено на аутентификацию до соединения. SecureNAT-клиент никогда не сможет отослать учетные данные на ISA-сервер, поэтому соединение не устанавливается.
 
 

Рисунок 4: Файл журнала, показывающий соединения клиентов брандмауэра и SecureNAT
 
 

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

Рекомендованная конфигурация показана на Рисунке 5. Компьютеры настроены как клиенты брандмауэра. При соединениях с другими сетями ISA-сервера, управлять соединениями будет клиент брандмауэра. При соединении с узлами этой же сети ISA-сервера начнет работу SecureNAT-клиент, а шлюзом по умолчанию станет адрес внутреннего интерфейса маршрутизатора внутренней сети. Поскольку внутренний маршрутизатор в качестве шлюза по умолчанию использует интерфейс этой же сети ISA-сервера, любые запросы SecureNAT-клиента, которые нужно маршрутизировать в Интернет, могут быть обработаны внутренним маршрутизатором. Это требовалось бы в том случае, если бы узлам подсети необходимо было бы использовать не-Winsock протокол (не-TCP или UDP), например, ICMP (для команд ping и tracert).
 

В нашем случае вам не нужно вносить изменения во внутреннюю сеть внутри сети. Клиенты брандмауэра этой сети передают свои Winsock-запросы для других сетей на интерфейс этой же сети ISA-сервера. SecureNAT-клиент настроен на использование внутреннего маршрутизатора, который знает маршруты ко всем внутренним подсетям, поэтому ISA-сервер не будет отклонять запросы, поскольку он их и не увидит. Настройки внутреннего SecureNAT-клиента разрешают прямые соединения с другими узлами этой же сети.
 
 
Рисунок 5: Использование альтернативного адреса шлюза по умолчанию для узлов из подсети
 

Схема «сеть внутри сети» - абсолютно рабочая. Все, что требуется, это включить все адреса за определенным интерфейсом в эту сеть. Главное ограничение этой схемы – невозможность использования для клиента брандмауэра контроля доступа, основанного на пользователях/группах, для контроля трафика между сетями, расположенными в одной и той же сети ISA-сервера.
 

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

Примером таких настроек может служить использование объектов Subnet (Подсеть) или Address Range (Диапазон адресов) для контроля доступа к компьютерам, расположенным к одной и той же сети. На самом деле, более серьезный контроль можно получить и с использованием объектов Computer (Компьютер). Обратите внимание, что такой вариант полезен только в том случае, если компьютеры расположены в подсети. Для получения контроля подобного уровня вам потребуется создать списки ACL во всех подсетях.
 
Резюме

В данной статье мы рассказали о работе мультисетевых возможностей ISA-сервера при работе по схеме «сеть внутри сети». В частности, мы рассмотрели разницу между поведением клиентов SecureNAT и брандмауэра и описали настройки, которые нужно использовать для компьютеров, настроенных одновременно как клиенты брандмауэра и SecureNAT.


Источник: http://Isadocs.ru
Категория: ISA | Добавил: Kogr (24.11.2009) | Автор: Томас Шиндер (Thomas Shinder) W
Просмотров: 3048 | Рейтинг: 0.0/0

Поиск

Vir Actiy

IP

Узнай свой IP адрес

Scan File

Scan URL

+

Бесплатный анализ сайта

Статьи , новости информационных технологий , обзоры , описание ошибок , Операционные системы , системные ошибки , новые технологии , аутсорсинг , windows , Linux , VoIP , FreeBSD , Cisco , информационная безопасность , Win7 , Win8 , server , проблемы с серверами , ИТ , управление инфраструктурой и многое другое…