Sunday, October 21st, 2018

Понимание Connectivity Verifiers (Верификаторов Подключаемости) ISA 2004

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

Введение

Очень хорошая возможность ISA Server 2004 — это способность верифицировать подключаемость (способность к подключению) периодическим мониторингом подключений от компьютера ISA Server до любого указанного компьютера или URL любой сети. Для достижения этого вы должны настроить верификаторы подключаемости. Однако, интересно ли вам, как они, в точности, работают, какие права доступа ими затрагиваются и как эта деятельность регистрируется? Если вы интересуетесь этими вещами, то эта статья должна дать вам несколько больше предварительной информации.

С помощью верификаторов подключаемости вы можете отслеживать соединения между ISA Server и определенными серверами на любой сети по FQDN или IP-адресу, или между ISA Server и определенным Web-Сервером по URL. Вы можете настроить метод, используемый для определения подключаемости:

  • Ping (Пинг): Когда вы выбираете это метод, ISA Server посылает ICMP ECHO_REQUEST указанному серверу и ожидает ICMP ECHO_REPLY. Используйте этот метод для контроля того, что сервер работает и может быть доступен для ISA Server.
  • TCP connect (TCP-соединение): Когда вы выбираете этот метод, ISA Server пытается установить TCP-соединение с указанным портом на указанном сервере. Используйте этот метод для контроля того, что указанный сервис работает на сервере и может быть доступен для ISA Server.
  • HTTP request (HTTP-запрос): Когда вы выбираете это метод, ISA Server посылает запросы HTTP Get и ожидает ответ. Используйте этот метод для контроля того, что Web-сервер работает и может быть доступен для ISA Server.

Примечание: По умолчанию, подключаемость проверяется каждые 30 секунд. Это глобальная установка и поэтому применяется ко всем верификаторам подключаемости. Согласно файлу справки ISA, вы можете изменить этот интервал, используя скрипт скорости Обновления (Refresh rate script), доступный на  ISA Server Coding Corner (Раздел Кодов ISA Server). Однако, этот Refresh rate script кажется пока недоступным.

В следующих разделах мы рассмотрим каждый из указанных вверху методов верификации подключаемости более подробно. Заметьте, что тестовая среда, которую мы используем для этой статьи — это работающий ISA Server 2004 Standard Edition с Service Pack 1, выпущенным 1 марта 2005. Также, рекомендуется хорошее понимание того, как ISA Server 2004 обрабатывает права доступа. Для дополнительной информации, смотрите мою статью Understanding the ISA 2004 Access Rule Processing (Понимание Обработки Прав Доступа ISA 2004).

Ping (Пинг)

Для возможности исследовать метод ping, давайте вначале настроим простой Ping верификатор подключаемости на адрес назначения www.cevi.be. Однажды сделав это и приняв изменения, вы должны увидеть что-то, похожее на рисунок внизу, когда пересматриваете свойства Ping верификатора подключаемости.

Isa server ошибка трансляции get

Когда Ping верификатор подключаемости получает допустимый ответ в течение указанного времени ожидания, и он является ответным сообщением, то в результате отображается время ping-отклика. Во всех других случаях будет показана ошибка. Измеренное время отклика — это время между посылкой ping-запроса (пакет ICMP ECHO_REQUEST) и приемом ping-ответа (пакет ICMP ECHO_REPLY packet).

Если мы начнем сейчас регистрацию жизни ISA и отфильтруем трафик по адресу назначения 193.75.143.142 (www.cevi.be), то ничего не попадет в результат регистрации. А как же это возможно, когда ping-запросы посылаются каждые 30 секунд? Вы можете это легко проверить позже с помощью захвата Network Monitor, как показано на рисунке внизу.

Connectivity verifiers

Для понимания такого поведения, вам следует знать, что любой механизм stateful packet inspection (инспекции пакетов с учетом состояния соединения) основан на концепции соединений. Регистрируется только открытие и закрытие соединений, но не каждый отдельный пакет. Однако, не все протоколы ориентированы на соединения, например, протоколы, основанные на ICMP или UDP. Для разрешения этой проблемы для таких протоколов имитируется состояние подключения соединения. Это работает, как описано ниже:

  • Когда посылается или принимается самый первый пакет и этот пакет разрешен политикой брандмауэра, в таблице соединений создается запись соединения с параметрами соединения: IP-адрес источника и приемника, протокол, номер порта источника и приемника (UDP) или тип ICMP и т.д.. Потом, запускается таймер на время 60 секунд, и, наконец, записывается запись в log о том, что новое соединение инициировано.
  • Когда прибывают следующие пакеты, вначале проверяется таблица соединений для поиска в ней уже существующего соединения с подходящими параметрами. Если параметры соответствуют, пакет принимается как следующий в это соединение и таймер перезапускается. Ничего не регистрируется, потому что пакет принадлежит подобному обмену.
  • Когда время таймера истекает, запись соединения удаляется из таблицы соединений и записывается log-запись о том, что существующее соединение закрыто. Поэтому, любой следующий пакет с подобными параметрами соединения рассматривается, как первый пакет нового соединения и весь процесс повторяется.

Вы можете проверить описанное поведение, запретив Ping верификатор подключаемости, применить изменения, подождать хотя бы одну минуту и перезапустить регистрацию событий ISA. Затем, включить Ping верификатор подключаемости и применить изменения. Если вы теперь посмотрите на ISA log, то вы должны увидеть запись, подобную первой на рисунке внизу (Initiated Connection — Начато соединение).

Как отключить верификатор драйвера?

Теперь позволим ему немного поработать и запретим Ping верификатор подключаемости опять, применим изменения. Вернемся в просмотрщик logа событий ISA и после короткого времени вы должны увидеть новую запись, подобную второй на приведенном выше рисунке (Closed Connection — Закрыто соединение). В примере выше, имитация соединения была активна около 21:30 минут.

Если вы посмотрите более внимательно на log, вы увидите, что Ping верификатор подключаемости разрешен правилом доступа Allow ICMP requests from ISA Server to selected servers (Разрешить запросам ICMP от ISA Server к выбранным серверам). Вы создавали это правило доступа? Нет, вместо этого есть System Policy rule #11 (правило номер 11 Системной Политики), которое разрешает этот трафик. Это правило Системной Политики включено по умолчанию. Для определения, как Ping верификатор подключаемости взаимодействует с правилами доступа, давайте отключим правило 11 Системной Политики и затем создадим наше собственное правило Политики брандмауэра Ping Access (Доступ Ping) для разрешения протокола Ping из Локального Hostа (Local Host) во все сети. Последовательность событий, которая будет зарегистрирована, показана на рисунке ниже.

Isa connectivity verifiers

После запрещения правила 11 Системной Политики и применения этих изменений, никакие события не будут регистрироваться. Это нормально, потому что изменения в политики брандмауэра применяются только к новым соединениям. Помните, что Ping верификатор подключаемости все еще активен и поэтому, все еще имитируется записью соединения в таблице соединений. Итак, вы должны вначале отключить верификатор и дождаться, пока истечет таймаут имитации соединения. Тогда вы увидите зарегистрированное первое событие, как показано на рисунке вверху (Closed Connection — Закрыто соединение). После этого события разрешите снова Ping верификатор подключаемости и вы увидите, что каждый индивидуальный запрос будет отклонен правилом по умолчанию Last as expected (Отклонено Соединение). Однажды сконфигурировав ваше собственное правило Политики Брандмауэра Ping Access и применив эти изменения, вы увидите, что последовательность запросов Ping верификатора подключаемости разрешены вашим собственным правилом Ping Access, как показано в последнем зарегистрированном событии на рисунке вверху (Initiated Connection — Начато Соединение).

Хотя Ping верификатор подключаемости не создает много «шума» в logе ISA, вы можете избавиться от всех этих записей, если захотите. Для этого, нажмите правую кнопку на правиле 11 Системной Политике, выберите Properties (Свойства) и запретите Log requests matching this rule (Регистрировать запросы, соответствующие этому правилу) на вкладке Action (Действие).

TCP соединения

Для возможности исследовать TCP метод, давайте, вначале, настроим простой TCP верификатор подключаемости для протокола FTP на адрес назначения www.cevi.be. Сделав это и применив изменения, вы должны увидеть что-то, похожее на изображенное на рисунке ниже, когда просматриваете свойства TCP верификатора подключаемости.

Прерывается пинг к exchange

Когда TCP верификатор подключаемости получает корректный ответ во время определенного таймаута, то это TCP соединение принимается, а результат показывает время ответа TCP соединения. Во всех других случаях будет отображена ошибка. Измеренное время ответа — это время между посылкой запроса на TCP соединение (пакет SYN) и получением пакета о принятии TCP соединения (пакет SYN, ACK).

Если мы начнем сейчас регистрацию событий ISA и отфильтруем трафик на назначение 193.75.143.142 (www.cevi.be), то вы должны увидеть что-то, похожее на показанное на рисунке ниже.

Верификаторами

Если вы внимательно посмотрите на приведенные вверху записи logа, вы увидите две интересные вещи. Первая — это последовательность в поле Log Time (Время регистрации), а вторая — это пустое поле Rule (Правило). Для поля Log Time, значение временной метки действия Closed Connection (Закрыто Соединение) каждый раз такое же как и значение следующего действия Initiated Connection (Начато Соединение). Это означает, что TCP верификатор подключаемости удерживает соединение активным до следующего интервала. Затем соединение обрывается, и сразу за этим устанавливается новое соединение. Вы можете легко проверить это с помощью захвата Network Monitor, как показано на рисунке ниже. Также, заметьте, что активное соединение завершается принудительно, другими словами, прекращается пакетом RST.

Connectivity verifiers где находится в isa

Вторая интересная вещь — это пустое поле Rule. Это означает, что ни правило Системной Политики. Ни правило Политики Брандмауэра явно не разрешают этот трафик. Однако мы можем сказать, что TCP верификатор подключаемости не следует нормальному правилу Доступа ISA 2004 и что создается некий вид скрытого динамического правила Системной Политики, когда вы конфигурируете верификатор подключаемости с TCP методом. Мое мнение, что это очень плохо и должно быть исправлено в последующем service pack’е (пакете обновления), потому что администратор брандмауэра не управляет этим. Более того, это поведение имеет несколько неожиданных эффектов.

Трафик, генерируемый TCP верификаторами подключаемости, не точно идентифицируется в регистрации (в logе). Это может быть смягчено записями поля Rule со значениями, например, Allow TCP requests from Connectivity Verifiers (Разрешить TCP запросы от Верификаторов Подключаемости). По крайней мере, это будет точно идентифицировать тип трафика. Более того, TCP верификаторы подключаемости создают много «шума» в logе ISA и, насколько я знаю, нет способа уменьшить эту проблему. Как показано выше, один TCP верификатор подключаемости генерерует каждые 30 секунд две записи в log ISA. Заметьте, слишком много шума для трафика вы неявно позволили, сконфигурировав TCP верификатор подключаемости. Поэтому будьте очень скупы в конфигурации верификаторов подключаемости TCP методом.

HTTP Соединение

Чтобы быть способными исследовать HTTP метод, давайте вначале настроим простой HTTP верификатор подключаемости на адрес назначения www.cevi.be. Заметьте, что в конце мастера конфигурации вы должны подтвердить, что правило Системной Политики будет разрешено. Сделав это и применив изменения, вы должны увидеть что-нибудь, похожее на изображенное на рисунке ниже, когда просматриваете свойства HTTP верификатора подключаемости.

Как отключить верификатор драйвера?

Конфигурацией HTTP верификатора подключаемости разрешается System Policy rule #18 (правило номер 18 Системной Политики), которое позволяет HTTP/HTTPS запросы во все сети. Вместо разрешения HTTP/HTTPS запросов во все сети, вы можете решить настроить правило 18 Системной Политики на использование пользовательского Computer Set (Множества Компьютеров), в которое включить только те компьютеры, для которых вы определили HTTP верификаторы подключаемости. После того, как вы удалите все верификаторы подключаемости, которые используют HTTP или HTTPS, правило системной политики будет автоматически запрещено, в качестве меры безопасности.

Когда HTTP верификатор подключаемости получает корректный ответ за время таймаута определенной величины, (это коды 1xx, 2xx, 3xx или 401 HTTP ответов) то результат отображает время отклика HTTP Get. Во всех других случаях будет показана ошибка. Измеренное время отклика — это время между посылкой HTTP Get запроса и приемом HTTP ответа с кодами 1xx, 2xx, 3xx или 401.

Если вы теперь посмотрите на log ISA и отфильтруете трафик на назначение 193.75.143.142 (www.cevi.be), вы должны увидеть что-то, похожее на показанное на рисунке внизу, для полной сессии HTTP верификатора подключаемости (разрешите верификатор, дайте ему время поработать и затем запретите его).

Isa connectivity verifiers result error

Записи logа с HTTP (заглавными буквами) в качестве значения в поле Protocol (Протокол) записаны компонентом Брандмауэра. Записи с http (строчными буквами) в поле Protocol приходят от фильтра Web Proxy. Насколько я знаю, компонент Брандмауэра выполняет обработку TCP соединений, а фильтр Web Proxy — реальных HTTP запросов, в нашем случае — запросов HTTP Get.

Другое интересное место — это факт, что мы видим две записи с Initiated Connection (Начато Соединение) и две записи с Close Connection (Закрыто Соединение) в поле Action (Действие). Для первых записей с Initiated Connection и Close Connection в качестве действия, поле Rule (Правило) заполнено значением Allow HTTP/HTTPS requests from ISA Server to specified sites (Разрешить HTTP/HTTPS запросы от ISA Server к указанным сайтам). Это очень странно, потому что это есть System Policy rule #17 (правило номер 17 Системной Политики) и это правило ничего не делает с верификаторами подключаемости. Для проверки этого, запретим правило 17 Системной Политики, а HTTP верификатор подключаемости будет все еще работать. Более того, для второй записи со значениями действия Initiated Connection и Close Connection, значение поля Rule будет пустым.

Как уже замечено ранее, HTTP верификатор подключаемости разрешен правилом 18 Системной Политики, названным Allow HTTP/HTTPS requests from ISA Server to selected servers for connectivity verifiers (Разрешить HTTP/HTTPS запросы от ISA Server к выбранным серверам для верификаторов продключаемости) и оно соответствует значению, записанному в поле Rule для записей logа с Allowed Connection (Разрешено Соединение) в поле Action.

Для получения немного большего удовольствия, давайте попытаемся найти соответствие приведенного выше logа с трассировкой Network Monitor trace этой же сессии, как показано на рисунке ниже.

Что такое verifier liq?

Вы можете четко видеть обмен запросами TCP соединения (SYN, SYN-ACK и ACK пакеты), следующий за пятикратным запросом HTTP Get и соответствующим HTTP ответом 200 и финальный обмен пакетами для закрытия TCP соединения (пакеты FIN-ACK и ACK в обоих направлениях). Запись logа соответствующая запросам TCP соединения в трассировке Network Monitor (порт источника TCP — 1146) — это вторая запись HTTP Initiated Connection с пустым полем Rule. Вы можете проверить, что это так, проверив поле Source Port (Порт Источника) в logе ISA. Поэтому логика, вызывающая запись протокола с правилом 17 Системной Политики в поле Rule, ускользает от меня полностью.

Для определения того, как HTTP верификатор подключаемости взаимодействует с правами доступа, давайте запретим правило 18 Системной Политики и затем создадим наше собственное правило Политики Брандмауэра HTTP Access (HTTP Доступ) для разрешения протокола HTTP/HTTPS от Local Host (локальный Host) ко всем сетям. Последовательность зарегистрированных событий показана на рисунке внизу, при условии, что правило 17 Системной Политики все еще включено.

Верификаторами

После запрещения правила 18 Системной Политики и применения изменений, вы увидите, что каждый индивидуальный запрос будет отклонен правилом по умолчанию Last as expected (последовательность Initiated Connection, Denied Connection, Closed Connection — Начато Соединение, Отклонено Соединение, Окончено Соединение). Сконфигурировав ваше собственное правило HTTP Access в Политики Брандмауэра и применив эти изменения, вы увидите, что следующие запросы HTTP верификатора подключаемости разрешены вашим собственным правилом HTTP Access, как показано в последних событиях, зарегистрированных на рисунка вверху (последовательность двухкратных Initiated Connection, Allowed Connection (Разрешено Соединение), Allowed Connection, и т.д.).

Наконец, HTTP верификатор подключаемости создает множество «шума» в logе ISA. При ближайщем рассмотрении примера вверху, один HTTP верификатор подключаемости генерирует каждые 30 секунд одну запись в logе ISA. Однако вы можете избежать всех этих записей, если захотите. Для этого, нажмите правую кнопку на System Policy rule #18, выберете Properties (Свойства) и выключите Log requests matching this rule (Регистрировать запросы, соответствующие этому правилу) на вкладке Action (Действия).

Заключение

В этой статья мы проверили большинство характеристик Верификаторов Подключаемости ISA Server 2004. На основе Ping метода мы изучили, как ISA Server обрабатывает не-TCP трафик, используя имитируемое состояние соединения. Когда использовали TCP метод, мы обнаружили, что верификатор подключаемости не следует нормальному правилу Доступа ISA 2004, и узнали о некоторых неожиданных эффектах. Наконец, мы определили некоторые неразрешимые чудеса регистрации, когда использовали метод HTTP запроса.

Источник 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 – часть ... [+]