Дополнительные настройки 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, а за этой сетью располагается сеть 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-сервера.

Рисунок 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-сервер может переадресовывать ответы прямо клиенту, и для этого ему не нужен адрес шлюза.

Рисунок 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.