На Рисунке 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.