Обзор работы с ISA и TMG сетями и анализ конкретного примера ISA Networking (часть 2)

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

Введение

В нашей предыдущей статье о сетях с брандмауэрами ISA и TMG я рассказывал о том, как брандмауэры ISA и TMG используют сети для управления трафиком, проходящим через брандмауэр и на брандмауэр. Чтобы освежить информацию в памяти скажу, что сети с брандмауэрами ISA и TMG Firewall Networks представляют собой собрание IP адресов, расположенное за определенной сетевой картой NIC на брандмауэре. Эти адреса могут принадлежать или не принадлежать подсети для определенной сетевой карты, но чтобы клиент за любой сетевой картой на брандмауэрах TMG или ISA имел возможность достигать адреса назначения через брандмауэр, IP адрес этого клиента должен быть включен в дефиницию сети ISA или TMG Firewall Network, с которой он подключается. Если клиентский IP адрес не является частью ISA Firewall Network дефиниции для NIC, которая получает запрос, соединение будет воспринято как ложное и будет прервано.

Если вы не читали первую часть этой серии статей о сетях ISA и TMG Networking, или хотите вспомнить, что собой представляют сети ISA/TMG Firewall Networks, нажмите сюда.

Теперь, когда вы понимаете подробности сетей ISA/TMG Firewall Networks, следующим шагом будет понимание того, как соединять эти сети. Чтобы хост в одной сети ISA/TMG Firewall Network мог подключиться к хосту в другой сети ISA/TMG Firewall Network, сеть источника и целевая сеть должны быть соединены. Соединение сетей ISA/TMG Firewall Networks осуществляется путем создания сетевого правила (Network Rule).

Сетевые правила соединяют сети ISA/TMG Firewall Networks одним из двух способов: NAT или Route. Когда вы подключаете сети ISA/TMG Firewall Networks друг к другу, вы также определяете отношения маршрутизации между ними.

Заметка:Обратите внимание на форму написания слова сети, когда я пишу о сетях. Слово сеть (‘network’), написанное с маленькой буквы ‘n’, означает сеть в общем смысле, тогда как слово сеть (Network), написанное с большой буквы ‘N’, означает именно сети ISA/TMG Firewall Network.

Когда вы определяете взаимоотношения NAT между Сетью-источником и целевой Сетью, все IP адреса в Сети-источнике скрыты от целевого узла. Целевой узел видит IP адрес источника в качестве основного IP адреса внешнего интерфейса брандмауэра ISA/TMG. Основной IP адрес представляет собой IP в самом верху списка IP адресов (когда внешнему интерфейсу брандмауэра ISA/TMG присвоено более одного IP адреса). Взаимоотношение маршрутизации NAT однонаправленное. Когда вы транслируете сетевые адреса (NAT) с источника в целевую сеть, вы не транслируете их с целевой сети в источник. Например, когда вы транслируете адреса из стандартной внутренней Сети в стандартную внешнюю Сеть, вы не транслируете адреса из стандартной внешней Сети в стандартную внутреннюю Сеть.

В общем, где есть NAT взаимодействие между Сетью-источником и целевой Сетью, вы создаете правила доступа (Access Rules), разрешающие соединения с NAT Сетей в не-NAT Сети (например, со стандартной внутренней Сети к стандартной внешней Сети), и правила публикации (Publishing Rules), разрешающие соединения с не-NAT Сети к NAT Сети (например, со стандартной внешней Сети в стандартную внутреннюю Сеть).

Когда вы определяете взаимоотношения маршрутизации (route relationship) между двумя сетями ISA/TMG Firewall Networks, то эти отношения двусторонние. Другими словами, если вы создаете взаимодействия маршрутизации с Сети-источника к целевой Сети, то такие же отношения наличествуют и между целевой Сетью и Сетью-источником. Когда есть отношения маршрутизации, отсутствуют скрытые IP адреса, и IP адрес источника всегда сохраняется.

В общем, вы используете правила доступа для разрешения трафика в обоих направлениях при наличии отношений маршрутизации между Сетью-источником и целевой Сетью. Например, если между вашей стандартной внутренней Сетью и Сетью DMZ установлены отношения маршрутизации, то вы можете использовать правила доступа для разрешения подключений со стандартной внутренней Сети к Сети DMZ, а также использовать правила доступа для разрешения подключений с Сети DMZ к стандартной внутренней Сети.

Примерное сетевое правило показано на рисунке 1. В этом примере показано сетевое правило, соединяющее Сеть DMZ со стандартной внутренней Сетью, а взаимоотношения маршрутизации – это Route (маршрут).

Tmg 2010 правило разрешить внутреннюю сеть

Рисунок 1

Помните, всегда должно быть сетевое правило, соединяющее Сеть-источник и целевую Сеть. Даже если вы создаете правило доступа, разрешающее подключение узла в одной Сети к узлу в другой Сети, попытки соединения будут безуспешными, так как Сети не соединены сетевым правилом. Эту проблему довольно трудно обнаружить и исправить, так как если вы проверите журналы регистрации событий брандмауэра ISA/TMG, то в них вы лишь найдете информацию о том, что попытка подключения была отвергнута, но не найдете никакой информации о том, что проблема заключается в отсутствующем сетевом правиле. По крайней мере, так было с брандмауэрами ISA. У меня еще не было возможности проверить это на брандмауэрах TMG. Однако данная проблема должна быть менее частой в брандмауэрах TMG, поскольку при создании новой Сети TMG Network, мастер потребует, чтобы вы создали сетевое правило до того, как будет создана Сеть. С брандмауэрами ISA все было наоборот, можно было создать Сеть, не создавая при этом сетевого правила.

Примеры сетевых правил

Чтобы лучше понять принцип работы сетевых правил при соединении Сетей ISA/TMG Firewall Networks, давайте рассмотрим несколько примеров. На рисунке 2 ниже показана типичная конфигурация брандмауэра ISA/TMG со стандартной внутренней Сетью и стандартной внешней Сетью. В этом примере есть сетевое правило, соединяющее стандартную внутреннюю Сеть со стандартной внешней Сетью, и сетевое правило, определяющее NAT взаимодействие между Сетями.

Когда клиенты стандартной внутренней Сети пытаются подключиться к узлам в стандартной внешней Сети, IP адрес источника, который виден для узла в стандартной внешней Сети, будет основным IP адресом внешнего интерфейса брандмауэра ISA/TMG. На самом деле брандмауэр ISA/TMG ‘скрывает’ IP адреса клиента источника.

Isa или tmg

Рисунок 2

Брандмауэры ISA и TMG можно настроить с несколькими сетевыми картами. Количество сетевых карт, которые можно установить на брандмауэрах ISA или TMG, неограниченно. На самом деле, можно даже создавать виртуальные карты с помощью 802.1q VLAN тегирования, если ваши сетевые карты и драйверы сетевых карт поддерживают такую конфигурацию. Когда на брандмауэрах ISA у вас установлено несколько сетевых карт, вы можете создавать Сеть ISA/TMG Firewall Network для каждой сетевой карты (помните наш разговор о Сетях ISA/TMG Firewall Networks в первой части этой серии о том, что каждая сетевая карта представляет корень (‘root’) каждой Сети ISA/TMG Firewall Network).

На рисунке ниже видно, что на брандмауэре ISA установлено три сетевых карты. Одна карта подключена к стандартной внешней Сети, одна – к стандартной внутренней Сети, и одна – к Сети DMZ. На брандмауэре настроено два сетевых правила:

  • Сетевое правило, соединяющее стандартную внутреннюю Сеть со стандартной внешней Сетью, а отношения маршрутизации — NAT
  • Сетевое правило, соединяющее стандартную внутреннюю Сеть с Сетью DMZ, а а отношения маршрутизации — Route

В этой конфигурации подключения со стандартной внутренней Сети к стандартной внешней Сети будут осуществляться с трансляцией сетевых адресов (NAT), а принимающие узлы будут видеть IP адрес источника, как основной IP адрес на внешнем интерфейсе брандмауэра ISA. Когда узлы стандартной внутренней Сети подключаются к узлам Сети DMZ, узлы приемника в Сети DMZ будут видеть IP адрес источника, как действительный IP адрес узла стандартной внутренней Сети. Таким же образом (поскольку взаимоотношения маршрутизации двусторонние), когда узел в Сети DMZ пытается подключиться к узлу стандартной внутренней Сети, узел стандартной внутренней Сети будет видеть IP адрес источника как действительный IP адрес узла Сети DMZ.

В этом примере (рисунок 3) подключения со стандартной внутренней Сети к стандартной внешней Сети разрешены с помощью правила доступа. Подключения со стандартной внешней Сети к стандартной внутренней Сети разрешены правилами публикации (правилом веб публикации или правилом публикации сервера {Web or Server Publishing Rules}). Подключения с Сети DMZ к стандартной внутренней Сети и со стандартной внутренней Сети к Сети DMZ разрешены правилами доступа.

Примеры использования tmg

Рисунок 3

Что, по-вашему, произойдет, если узел Сети DMZ попытается подключиться к узлу стандартной внешней Сети? Поскольку отсутствует сетевое правило, соединяющие узлы Сети DMZ с узлами стандартной внешней Сети, попытка подключения будет отвергнута, как показано на рисунке 4 ниже. Даже если есть правило доступа, позволяющее подключение, попытка подключения будет безуспешной, так как отсутствует сетевое правило, обеспечивающее соединение между этими Сетями.

Анализ портов tmg

Рисунок 4

Допустим, мы создали сетевое правило, обеспечивающее подключение Сети DMZ к основной внешней Сети, и определили взаимоотношения маршрутизации как NAT. Когда есть взаимоотношения NAT, мы можем использовать либо публичные, либо частные адреса в Сети источника. Подключения с узлов Сети DMZ к основной внешней Сети разрешены правилами доступа, а подключения основной внешней Сети к Сети DMZ разрешены правилами публикации.

Tmg command line IP

Рисунок 5

На рисунке 6 ниже показано легкое изменение этой конфигурации. В данном случае есть сетевое правило, соединяющее Сеть DMZ со стандартной внешней Сетью. Поскольку там есть отношения маршрутизации, нам нужно использовать публичные адреса в Сети DMZ, так как частные адреса не передаются по сети интернет. Мы также можем использовать правило доступа для разрешения соединений с Сети DMZ к стандартной внешней Сети, и мы также можем использовать правила доступа для разрешения соединений со стандартной внешней Сети к Сети DMZ.

До этого момента я говорил вам о том, что когда у вас есть взаимодействия маршрутизации, вы можете использовать правила доступа для управления трафиком в обоих направлениях. Однако можно использовать и правила публикации. В случае использования правил веб публикации (Web Publishing Rules), взаимодействия маршрутизации не представляют никаких проблем, так как подключения постоянно передаются (proxied) с источника на приемник, поэтому никакой действительной маршрутизации (‘routing’) не происходит на уровне IP. Но с правилами публикации сервера (Server Publishing Rules) дело обстоит несколько иначе.

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

Например, в конфигурации, приведенной выше на рисунке 5, есть отношения маршрутизации между основной внешней Сетью и Сетью DMZ. Допустим, у вас есть SMTP сервер в Сети DMZ. Вы хотите разрешить входящие SMTP сообщения из интернета на SMTP сервер в Сети DMZ. В этом случае нужно создать правило доступа, разрешающее входящие SMTP соединения с основной внешней Сети к Сети DMZ, или же можно создать правило публикации сервера, которое опубликует SMTP сервер в Сети DMZ.

Преимуществом использования правила публикации сервера в данной ситуации является то, что фильтр SMTP может быть привязан к протоколу ‘SMTP Server’. Протоколы ‘Server’ используются только для входящих соединений. Фильтр SMTP нельзя связать с ‘SMTP’ протоколом, который используется для правил доступа. Таким образом, правило публикации сервера, использующее SMTP Server протокол, позволяет нам применить осмотр входящих соединений на прикладном уровне.

Здесь следует отметить, что когда вы используете правило публикации сервера для публикации серверов в ситуации, где есть отношения маршрутизации между Сетью-источником и Сетью-приемником, вы публикуете машину, использующую действительный IP адрес публичного сервера. Однако затем брандмауэр ISA или TMG делает немного чуда для перехвата соединения, чтобы можно было выполнять осмотр на прикладном уровне. Брандмауэр выполняет действие, известное как кража порта (‘port stealing’) на правиле публикации сервера с тем, чтобы, когда создаются подключения, предназначенные для целевого действительного IP адреса публичного сервера, брандмауэр мог «воровать» (‘steal’) соединение и передавать его на фильтры осмотра прикладного уровня. Если соединение проходит осмотр, оно перенаправляется на публичный сервер. Если соединение не проходит осмотр, оно прерывается.

Isa или tmg

Рисунок 6

Теперь давайте сменим центр внимания и посмотрим на подключения между Сетью DMZ и основной внутренней Сетью. На рисунке 7 ниже видно, что у нас есть сетевое правило, соединяющее основную внутреннюю Сеть и Сеть DMZ, а отношения маршрутизации – это трансляция сетевых адресов (NAT). Поскольку отношения маршрутизации – это NAT, когда узлы основной внутренней Сети пытаются подключиться к узлам Сети DMZ, узлы Сети DMZ будут видеть в качестве IP адреса источника подключения основной IP адрес сетевой карты DMZ.

Чтобы разрешить подключения к Сети DMZ с основной внутренней Сети, нужно создать правила доступа. Чтобы разрешить подключения с узлов Сети DMZ к узлам основной внутренней Сети, нужно создать правила публикации. Однако когда у вас есть отношения NAT с основной внутренней Сети к Сети DMZ, вы не можете создавать правила доступа, разрешающие подключения с Сети DMZ к основной внутренней Сети.

Публикация внутреннего сервера в tmg

Рисунок 7

На рисунке 8 показано реверсирование сетевого правила, соединяющего Сеть DMZ с основной внутренней Сетью. В данном случае сетевое правило определяет отношения NAT с Сети DMZ к основной внутренней Сети. Когда узлы Сети DMZ пытаются подключиться к узлам основной внутренней Сети, узлы основной внутренней Сети будут видеть IP адрес источника соединения в виде основного IP адреса сетевой карты основной внутренней Сети. Правила доступа разрешают подключения с узлов Сети DMZ к основной внутренней Сети, а правила публикации обеспечивают соединения с узлов основной внутренней Сети к узлам Сети DMZ. Нельзя создавать правила доступа для обеспечения соединений с основной внутренней Сети к Сети DMZ, поскольку узлы основной внутренней Сети находятся в не-NATed Сети (то есть в сети без трансляции сетевых адресов).

Внутренняя сетевая карта isa

Рисунок 8

Следующая ситуация обычно вызывает трудности: конфигурация брандмауэра ISA/TMG соединений внутренних интерфейсов (back to back). В конфигурации соединений внутренних интерфейсов есть внешний (front-end) брандмауэр ISA/TMG, подключенный к интернету, а также внутренний (back-end) брандмауэр ISA/TMG, который подключен к Сети DMZ за внешним брандмауэром и внутренней сети за внутренним брандмауэром.

В типичной ситуации внешний брандмауэр ISA/TMG имеет отношения маршрутизации NAT между сетью DMZ за внешним брандмауэром и основной внешней Сетью. Внутренний брандмауэр ISA/TMG имеет NAT отношения маршрутизации между основной внутренней Сетью и основной внешней Сетью.

Здесь нужно понять, что сеть DMZ перед внутренним брандмауэром ISA/TMG является частью основной внешней Сети внутреннего брандмауэра ISA/TMG. Поскольку она является частью его основной внешней Сети, отношения маршрутизации будут NAT. Таким образом, если узлы за внутренним брандмауэром ISA/TMG нуждаются в подключении к машинам сети DMZ между брандмауэрами, вам нужно создавать правила доступа для обеспечения таких подключений. Если есть машины в сети DMZ между брандмауэрами, которым нужно подключиться к узлам за внутренним брандмауэром ISA/TMG, то нужно создавать правила публикации для обеспечения таких подключений.

Tmg анализатор

Рисунок 9

Теперь давайте рассмотрим разновидность вышеприведенного сценария. В этом случае на внутреннем брандмауэре ISA/TMG мы создадим Сеть ISA/TMG Firewall Network для DMZ между брандмауэрами. Затем мы создадим сетевое правило, обеспечивающее подключение основной внутренней Сети на внутреннем брандмауэре ISA/TMG к Сети DMZ и зададим Route отношения маршрутизации между Сетями. Теперь, когда узлы подключаются к ресурсам Сети DMZ, правило доступа используется для обеспечения соединений и узлы Сети DMZ видят IP адрес источника, как оригинальный клиентский IP адрес. Такая конфигурация также позволяет создавать правило доступа для разрешения узлам Сети DMZ подключаться к узлам основной внутренней Сети за внутренним брандмауэром ISA/TMG.

Этот сценарий важен, так как многие люди любят блокировать VPN соединения на внешних брандмауэрах. Когда VPN клиенты блокируются на внешнем брандмауэре ISA/TMG, им присваиваются IP адреса, которые являются частью Сети DMZ. Таким образом, они действуют в качестве узлов Сети DMZ. Затем можно создать правила доступа, которые предоставляют доступ VPN клиентам к ресурсам основной внутренней Сети за внутренним брандмауэром ISA/TMG. Основным моментом здесь является то, что поскольку клиентам VPN присваиваются IP адреса, принадлежащие дефиниции Сети DMZ на внутреннем брандмауэре ISA/TMG, можно использовать правила доступа вместо правил публикации благодаря отношениям маршрутизации между двумя Сетями.

Есть еще кое-что, о чем вы должны знать относительно такой конфигурации, где есть отношения маршрутизации между основной внутренней Сетью внутреннего брандмауэра ISA/TMG и Сетью DMZ. Когда узлы основной внутренней Сети внутреннего брандмауэра ISA/TMG пытаются подключиться к интернету, соединения должны проходить через оба брандмауэра. Когда внешний брандмауэр ISA/TMG принимает запрос исходящего соединения с узлов основной внутренней Сети внутреннего брандмауэра ISA/TMG, IP адрес источника будет представлять собой действительный IP адрес узла, делающего запрос.

Обычно основная внутренняя Сеть внешнего брандмауэра ISA/TMG будет включать IP адреса Сети DMZ. Однако, так как есть отношения маршрутизации между Сетью DMZ и основной внутренней Сетью внутреннего брандмауэра ISA/TMG, вам нужно будет включить адреса основной внутренней сети внутреннего брандмауэра ISA/TMG в список адресов, определяющих основную внутреннюю Сеть внешнего брандмауэра ISA/TMG. Если этого не сделать, внешний брандмауэр ISA/TMG будет воспринимать адрес источника, как не принадлежащий к адресам его основной внутренней Сети и будет разрывать подключения, считая адреса ложными.

Правило isa для voip

Рисунок 10

Заключение

В этой части серии о концепции Сетей ISA/TMG Network я рассказал о некоторых сценариях, которые были созданы, чтобы помочь вам понять концепцию сетевых правил. Сетевые правила требуются для соединения Сетей. Если Сеть-источник и Сеть-приемник не подключены, никакого взаимодействия между ними не будет разрешено, даже если правило доступа настроено на разрешение соединений. При определении сетевого правила для соединения Сети-источника и Сети-приемника вы также определяете отношения маршрутизации. Отношения маршрутизации могут быть либо NAT (трансляция сетевых адресов), либо Route (маршрут). Правила доступа и правила публикации поддерживаются различными способами, в зависимости от отношений маршрутизации между источником и приемником.

В следующей статье мы рассмотрим ситуацию, в которой нам необходимо отчетливо понимать то, как Сети ISA/TMG firewall Networks работают, чтобы получить рабочее решение. Мы рассмотрим процесс перехода со старого брандмауэра ISA 2000 на ISA 2006. Миграция также включает переход с брандмауэра с одной привязкой (unihomed ISA firewall) на брандмауэр с двойной привязкой (dual-homed firewall). Как вы уже догадываетесь, возникло несколько проблем с сетями, которые требуют решения. О том, что это были за проблемы и как с ними бороться, мы узнаем в следующей части. Увидимся

www.isaserver.org


Смотрите также:

Tags: ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)



https://lyskovo-nnov.sredi-cvetov.ru доставка цветов Лысково.

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