Monday, December 11th, 2017

Дополнительные настройки ISA-сервера: Схема «Сеть за сетью»

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

Мультисетевые функции сервера 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, а за этой сетью располагается сеть 172.16.0.0/16, проблем в настройках не возникнет. Вы просто включаете все адреса обоих сетей в определение сети ISA-сервера, за которую отвечает данный сетевой интерфейс.

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

Пример сети внутри сети ISA-сервера

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

Инструкция vipnet для настройки 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-сервера, находящегося в одной сети с клиентом.

На Рисунке 1 клиент с адресом 10.0.0.5/24 настроен как клиент брандмауэра, и его программное обеспечение настроено на использование в качестве шлюза по умолчанию адреса 10.0.0.1. Клиент брандмауэра внутри сети 10.10.10.2/24 также использует адрес 10.0.0.1. Компьютер клиента соединяется через программное обеспечение клиента брандмауэра с ISA-сервером напрямую. Это значит, что клиент брандмауэра не зависит от текущей инфраструктуры маршрутизации в организации. Единственным требованием к инфраструктуре маршрутизации является то, что все маршруты к сетям интерфейса ISA-сервера известны.

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

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

Инструкция vipnet для настройки isa

Рисунок 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-клиента и соединиться с узлом внутренней сети. Конечно, целью использования клиента брандмауэра является разрешение аутентификации на основе пользователей/групп.

Local address table isa пример

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

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

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

Local address table isa пример

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

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

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

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

Isa дополнительные соединения

Рисунок 5: Использование альтернативного адреса шлюза по умолчанию для узлов из подсети

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

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

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

Резюме

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

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