Monday, December 11th, 2017

Полное руководство к ISA Firewall Outbound DNS (Часть 2)

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

Если вы хотите ознакомиться с остальными частями этой статьи, пожалуйста, прочитайте:

В первой части я рассказал о процессе резолюции DNS имен для названий интернет хостов. Мы потратили много времени, разбирая процесс рекурсии, и ее использование для установления связи между несколькими DNS серверами интернета с целью разрешений имен интернет хостов. Еще мы обсудили, как работает DNS forwarder, и, как путем комбинирования нескольких DNS forwarder с DNS кэшированием, мы можем значительно улучшить процесс резолюции имен хост-узлов DNS.

Во второй части статьи я более подробно остановлюсь на том, как различные виды клиентов ISA Firewall разрешают имена хостов. Это очень важная часть резолюции ваших исходящих DNS имен, и четкое понимание того, как различные виды клиентов ISA Firewall разрешают имена, поможет вам с самого начала установить проект и поможет вам разрешить резолюцию имен и выполнять задания в будущем.

Двумя главными темами будут:

  • Как клиенты, находящиеся позади ISA Firewall, разрешают имена хостов.
  • Точная настройка допуска для Web-прокси и Firewall клиентов.

Как клиенты позади от ISA Firewall разрешают имена хостов

Прежде, чем погрузиться в схему DNS инфраструктуры, было бы неплохо понять, как различные виды клиентов ISA Firewall разрешают имена хост-узлов, как для внутренних, так и для внешних ресурсов. Вот три вида клиентов ISA Firewall:

  • The SecureNET (SecureNAT) client Клиент SecureNET – это устройство, настроенное со шлюзовым адресом по умолчанию, который позволяет ограниченным запросам интернета проходить через ISA Firewall. Если клиент SecureNET расположен в той же подсети, что и ISA Firewall, то шлюзовой адрес по умолчанию будет IP адресом интерфейса ISA Firewall в той же сети ID, что и у клиента. Если клиенты принадлежат удаленным подсетям, то IP адрес станет маршрутизированным интерфейсом, который будет использовать исходящие запросы через ISA Firewall. До тех пор, пока «официальным» именем в документации ISA Firewall значится клиент SecureNAT, на него более аккуратно ссылаются как на клиент SecureNET, потому что как Network Rule описывает соединение между ресурсом и нужной сетью: оно не должно быть NAT связью, а может быть Route связью.
  • The Firewall Client Клиент Firewall – это часть программного обеспечения, которая должна быть установлена на пользовательской операционной системе (клиент Firewall не рекомендуется устанавливать на серверную операционную систему и никогда в ISA Firewall). Клиент Firewall – это клиент proxy-сервера Winsock, который перехватывает вызовы прикладной сети Winsock и отправляет их (отдаляет их) прямо в ISA Firewall. Это позволяет клиенту ISA Firewall быть доступным для сетевой маршрутной инфраструктуры и не зависеть от установленного по умолчанию шлюза или пути последней настройки сетевых маршрутов. Единственным требованием сетевой инфраструктуры является то, что клиенты имеют маршрут к ближайшим IP адресам ISA Firewall. Клиент Firewall так же допускает аутентификацию пользователя для контроля доступа и поддерживает вторичные соединения для общих протоколов, когда нет Application Filter для проведения этой поддержки. Напротив, у клиентов SecureNET должен быть Application Filter для поддержки общих протоколов, которые могут запросить основные и вторичные соединения.
  • The Web Proxy client Клиент Web-прокси сервера– это устройство, которое имеет собственный настроенный браузер для использования ISA Firewall в роли устройства Web-прокси сервера. Настройка браузера может быть сделана вручную, или может быть автоматизирована путем использования WPAD протокола и WPAD записи в DHCP и/или DNS. Настройка клиента Web-прокси сервера поддерживает только HTTP, HTTPS, и HTTP маршрутные FTP запросы и не поддерживает FTP загрузку, только FTP перекачку. Клиенты Web-прокси сервера опознаются с помощью ISA Firewall, в отличии от клиентов SecureNET, которые не могут быть опознаны ISA Firewall’ом.

Виды клиентов должны рассматриваться как «роли» клиента, так как единое устройство может быть настроено как клиент SecureNET, Firewall и Web-прокси. Однако одно устройство не может работать в различных ролях одновременно.

Например, устройство, настроенное как клиент SecureNET и клиент Web-прокси сервера не будет одновременно работать как клиент Web-прокси сервера и SecureNET при соединении с Веб-сайтом — оно будет работать либо как клиент SecureNET (если Direct Access настроен для этого сайта) или как клиент Web-прокси сервера (если Direct Access не настроен для этого сайта). О Direct Access мы поговорим более подробно чуть дальше в этой статье.

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

  • Резолюция имени для клиентов SecureNET. Клиенты SecureNET должны разрешать имена хост-узлов для их личного пользования DNS сервером, настроенном для сетевого интерфейса клиента SecureNET.
  • Резолюция имени для клиентов Firewall. Когда программное обеспечение клиента Firewall обрабатывает соединение, сделанное приложением Winsock на компьютер клиента Firewall, резолюция имени по умолчанию обрабатывается ISA Firewall. В этом случае ISA Firewall должен быть настроен с помощью DNS сервера для внутреннего интерфейса, разрешающего имена хостов.
  • Резолюция имени для клиентов Web-прокси сервера. Когда клиент Web-прокси обрабатывает запрос соединение для Web-прокси допускающим приложение, резолюция имени обрабатывается ISA Firewall. В этом случае ISA Firewall должен быть настроен с помощью DNS сервера для внутреннего интерфейса, разрешающего имена хостов.

Когда ISA Firewall обрабатывает запрос для клиентов Firewall и Web-прокси, то ISA Firewall допускает, что вы хотите пройти через ISA Firewall для достижения этих ресурсов. Могут быть периоды, когда вы хотите обойти настройки клиентов Web-прокси и Firewall, поэтому вы можете сделать прямое соединение с ресурсом и не возвращаться назад через ISA Firewall. Например, рассмотрим ситуацию на ниже приведенном рисунке.

Isa клиент fkmnthyfnbdysq

Рисунок 1

Вот описание этой последовательности событий:

  1. Firewall или Web-прокси клиент делает запрос к ресурсу, находящемуся в той же сети ISA Firewall, откуда и делается запрос клиента.
  2. ISA Firewall передает запрос, сделанный клиентом Firewall или Web-прокси ресурсу, находящемуся в той же сети ISA Firewall, что и клиент.
  3. Ответ ресурса возвращается к ISA Firewall с того момента, как ISA Firewall работает в роли передатчика между клиентом и ресурсом сети.
  4. Ответ возвращается от ISA Firewall клиенту, сделавшему запрос.

Как вы видите, существует возможность для формирования большого сетевого потока через ISA Firewall к ресурсам, расположенным в той же сети ISA Firewall. Но есть возможность довести ISA Firewall до остановки из-за отсутствия хорошей причины с тех пор, как ISA Firewall не будет больше рассматриваться как «связной» между клиентами и серверами, находящиеся в той же сети ISA Firewall. Напротив, клиенты и серверы, находящиеся в той же сети ISA Firewall будут сразу соединяться между собой. Это называется Direct Access. Direct Access может быть настроен отдельно от Firewall и Web-прокси клиентов. Когда Direct Access доступен, на настройки клиента Web-прокси и/или Firewall не обращается внимание.

Когда вы настраиваете прямой доступ клиента Web-прокси и/или Firewall, то происходит следующее:

  1. Когда клиент Web-прокси или Firewall делает запрос к ресурсу, содержащемуся в списке Direct Access этого клиента, то настройки клиентаWeb-прокси или Firewall остаются без внимания с целью доступа к ресурсу. Когда настройки клиента Web-прокси или Firewall пройдены, компьютер клиента становится ответственным за резолюцию имен хост-узлов. Клиент отправляет DNS запрос для имени целевого сервера DNS серверу, настроенному для интерфейса клиента.
  2. DNS возвращает адрес целевого сервера клиенту.
  3. Клиент делает запрос прямиком к целевому серверу, пропуская настройки клиента Firewall и/или Web-прокси.
  4. Целевой сервер отправляет ответ сразу к клиенту.

Настройки Direct Access для клиентов Firewall и Web-прокси

Direct Access настолько важный пункт, что, как я думаю, нам следует потратить несколько минут на его обсуждение. Запомните, что когда вы настраиваете сайт для Direct Access, то вы настраиваете соединения с этим сайтом, чтобы пропустить клиенты Firewall и/или Web-прокси. Когда вы обходите эти настройки клиента, у системы клиента должен быть метод для соединения с адресатом, который является самыми обычными настройками клиента SecureNET, в том случае пока соединение не направлено к ресурсу той же сети ISA Firewall, что и у клиента, соединение происходит напрямую с ресурсом и не использует какие-либо программы маршрутизации или сетевые устройства защиты.

На ниже приведенном рисунке вы видите колонку Properties для установленной по умолчанию внутренней сети ISA Firewall (Internal ISA Firewall Network). Нажав на ярлык Domains, вы входите в домен, для которого вы хотите обойти настройки клиента Firewall. Естественно, существуют домены, находящиеся в тех же сетях ISA Firewall, что и клиенты, но они не всегда бывают операторами выбора. Вы можете захотеть пропустить настройки клиента Firewall, чтобы достигнуть внешнего ресурса или ресурса, находящегося в другой сети ISA Firewall, и поэтому попытка соединения должна быть сделана через ISA Firewall.

Помните, что когда вы обходите клиент Firewall для достижения этих доменов, то клиенту будет необходимо использовать настройки SecureNET или Web-прокси клиентов для достижения ресурсов этих доменов. Если клиент SecureNET является единственным вариантом, который остается системе клиента для соединения с адресатом, то тогда вы должны убедиться, что есть Access Rule, который не требует идентификации для разрешения доступа, так как клиенты SecureNET не могут идентифицироваться.

Dns через isa

Рисунок 2

Ниже приведенный рисунок показывает колонку Web Browser в меню Properties установленной по умолчанию внутренней сети ISA Firewall. Там вы настраиваете Direct Access для клиентов Web-прокси. Здесь есть несколько опций, и они обычно не понимаются. Это:

  • Bypass proxy for Web servers in this network Это опция вводит в заблуждение, так как не имеет никакого значения находятся или нет компьютеры в той же сети ISA Firewall. Эта опция означает, что настройки клиента Web-прокси должны быть пропущены, когда пользователь соединяется, используя единственное имя метки, такое как http://server1. В общем, вам не рекомендуется использовать единственные имена меток, поэтому выбираете ее или нет – зависит полностью от вас. Лично я обычно оставляю ее выбранным.
  • Directly access computers specified in the Domains tab Эта опция отменяет настройки клиента Web-прокси для доменов, заданных в меню доменов клиента Firewall. Вам следует оставить эту опцию выбранной.
  • Directly access computers specified in the Addresses tab Меню Addresses Tab содержит адреса, которые описывают данную сеть ISA Firewall. Вам следует использовать Direct Access при соединении с ресурсами в той же сети ISA Firewall, что и у клиента, поэтому эта опция должна быть всегда выбрана.
  • Directly access these servers or domains Если есть другие серверы или домены, для которых вы хотите использовать Direct Access, то вам рекомендуется использовать кнопку Add и добавить их. Там вы введете имена интернет сайтов, которые не работают с Web-прокси серверами, такими как Java сайты. Если у вас есть проблемы с приложением Java, или другой плохо закодированный веб сайт не работает с CERN, совместимым с Web-прокси серверами, то вам следует войти на этот сайт здесь. Из-за ISA 2004 SP2 вы не можете смешивать в этом списке IP адреса с именами домена. Я рекомендую использовать только имена доменов в этом списке.
  • If ISA Server is unavailable, use this backup route to connect to the Internet Это последняя из дезориентирующих опций, смысл которой сразу непонятен. Она означает, что если Web-прокси сервис недоступен для ISA Firewall, то, что следует сделать клиенту Web-прокси сервера для входа в интернет? Вам нужно ввести имя другого Web-прокси сервера, чтобы клиент Web-прокси вошел в интернет через альтернативный Web-прокси сервер, или вы можете выбрать опцию Direct access, которая означает, что настройки клиента Web-прокси будут недоступны, и клиент будет вынужден использовать на новом уровне настройки его клиента Firewall и/или SecureNET для достижения интернет или веб ресурсов.

Необходимо, чтобы вы осознавали, что автоматическое определение должно работать для запуска списка Direct Access клиента Firewall. Это не проблема, так как клиент Firewall не может определить ISA Firewall, он вообще не будет работать, и вам немедленно следует найти и исправить причины неисправностей. С другой стороны, с целью получения списка Direct Access для клиента Web-прокси сервера вы должны настроить клиент Web-прокси сервера как для использования WPAD, основанном на autodiscovery (автоопределение), или вы должны настроить их на использование скрипта автоматической настройки (autoconfiguration script), который может быть сделан как вручную, так и через Group Policy.

Как сделать расщепленную dns isa?

Рисунок 3

Подводя итоги:

  • Клиенты SecureNET всегда разрешают имена для себя. ISA Firewall никогда не разрешает имена в интересах клиентов SecureNET.
  • Клиенты web-прокси всегда позволяют ISA Firewall разрешать имена в своих интересах. Исключением из этого правила является настройка клиента Web-прокси сервера, пропущенная из-за того, что сайт назначения находится в списке Direct Access
  • Клиенты Firewall по умолчанию всегда позволяют ISA Firewall делать резолюцию имен в своих интересах. Исключением из этого правила является соединение с сайтами из списка Direct Access.
  • Когда вы выясните, что ваши клиенты Web-прокси и Firewall могут соединяться с интернетом, а клиенты SecureNET не могут, то наиболее яркой причиной этого будет то, что нет закона, который разрешает анонимный доступ к адресату, или то, что клиент SecureNET не может разрешить имя для адресата, к которому он стремится.

Заключение

В этой статье мы выяснили, как различные виды клиентов ISA Firewall разрешают имена. По умолчанию клиенты SecureNET должны иметь возможность для резолюции своих собственных имен без помощи ISA Firewall. Клиенты Web-прокси сервера и Firewall позволяют ISA Firewall разрешать имена в своих интересах. Существуют моменты, когда вам нужно обойти ISA Firewall или тип клиента ISA Firewall для соединения с ресурсом. В этом случае вы настраиваете клиент Firewall или Web-прокси для использования Direct Access. Когда Direct Access для сайта показан, то тип клиента, для которого настроен Direct Access, обходится, и используется другой тип клиента (или «роль» клиента, как мы раньше это называли). Приобретенное знание, как клиенты ISA Firewall разрешают имена хостов интернета и как клиент Direct Access, поможет вам получить более устойчивую к сбоям инфраструктуру резолюции имен и поможет вам найти и устранить неисправности резолюции имен и проблем связанных с ISA Firewall.

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