Если вы пропустили первую часть данной серии статей, пожалуйста, прочитайте Ваш новый брандмауэр ISA Firewall: ISA 2006 Service Pack 1 – часть 1
В первой части этой серии статей о ISA 2006 Service Pack 1 мы познакомились со свойством отслеживания изменений (Change Tracking) и свойством тестовой кнопки (Test button), которые вы можете использовать с правилами публикования Web. В этой статье мы продолжим изучение свойств ISA 2006 SP1 разбором двух очень приятных и полезных свойств – симулятором трафика и улучшенным средством просмотра диагностики.
Когда вы щелкнете на узле Troubleshooting в левой панели консоли брандмауэра ISA firewall, вы заметите новую вкладку — Traffic Simulator. Симулятор трафика может помочь вам решить проблемы с правилами доступа и публикования симулированием трафика, с которым возникают проблемы, а затем сравниванием этого трафика с текущим набором правил.
Когда вы щелкаете на вкладку Traffic Simulator, вы увидите, что есть возможность проверки четырех сценариев:
Давайте взглянем на каждый из этих сценариев, чтобы узнать, какие именно параметры доступны в каждом из них.
Начнем с выбора сценария Web access. После выбора этого сценария у вас есть несколько опций в окне Source Parameters(параметры источника). Среди них:
В окне Destination Parameters (параметры назначения) вы вводите URL сайта, при подключении к которому испытываются проблемы.
В данном примере мы попробуем увидеть, может ли клиент во внутренней сети за брандмауэром по адресу 10.0.0.2 соединиться с Web-сайтом www.isaserver.org. Поскольку я также предполагаю способность клиентов аутентифицироваться, я введу имя пользователя Administrator.
Затем я щелкаю на кнопку Start для запуска тестирования. В нижней части рисунка снизу вы видите, что трафик был разрешен правилом доступа под названием Allow HTTP.
Рисунок 1
Давайте попробуем другой тест. В этом примере мы будем использовать тот же IP-адрес клиента, расположенного за брандмауэром. Но теперь изменим сценарий так, чтобы можно было проверить не Web протокол. Такие протоколы не проходят через Web-прокси фильтр брандмауэра ISA firewall и обрабатываются только службой брандмауэра и фильтрами приложений.
Я настраиваю тест так, чтобы трафик был разрешен через анонимного пользователя на целевой адрес 192.150.87.2 через UDP порт 53. Я хочу проверить, может ли клиент за брандмауэром выполнять DNS запросы на конкретный DNS сервер.
Но перед этой проверкой нужно обратить внимание на опцию Apply diagnostic logging to simulated traffic. Нам нужно поставить рядом галочку, чтобы в случае неудачи теста мы могли ознакомиться с деталями соединения в диагностическом журнале.
На этот раз после нажатия кнопки Start мы видим, что результаты не столь хороши, как в первом случае. Теперь трафик был отклонен. Но предоставленная информация не очень полезна. Все, что известно, — это что трафик проходил извне наружу, что это было сетевое правило, соединявшее клиента с сервером, что протокол был опознан как DNS, и что никакой фильтр приложений не применялось к правилу. Однако, известно, что правило, отказавшее в соединении, было правило «All Open»(все открыто), что может оказаться полезным при ближайшем рассмотрении.
Поскольку вся эта информация не дает нам возможности идентифицировать проблему, есть необходимость заглянуть в журнал диагностики, чтобы копнуть глубже, и решить проблему.
Нажмите на кнопку View Log для просмотра симулированного трафика.
Рисунок 2
Ага! Это было почти слишком просто. Здесь можно увидеть, что правило «All Open», которое, согласно ожиданиям, должно было разрешить трафик, не пускало его из-за того, что The rule does not match because the rule requires authentication and no user is specified in the packet (правило не было применено, так как оно требует аутентификации, а никакой пользователь не был указан в пакете) и The rule All Open requires user authentication(данное правило требует аутентификации пользователя). Вы также можете видеть далее, что со всеми остальными аспектами попытки соединения все было хорошо, и единственной проблемой была нехватка аутентификации. Таким образом, чтобы разрешить DNS соединения с целевым сервером, мне необходимо либо создать клиента брандмауэра на сервере DNS для исходящего запроса (что не рекомендуется), либо создать другое правило, которое разрешало бы серверу DNS создавать анонимный исходящий доступ к DNS запросам в Интернет (что рекомендуется).
Что хорошо при работе с симулятором трафика и его соединением с улучшенным журналом диагностики, — это то, что вы видите только тот трафик, который генерируется симулятором трафика. Вам не нужно рыскать по всему журналу диагностики в поиске нужного соединения. Однако если мы хотим посмотреть на реальный сетевой трафик, мы увидим, что найти соответствующую информацию не так уж и сложно.
Однако Traffic Simulator с журналом диагностики имеют некоторые ограничения, которые не позволяют решить все конфигурационные проблемы. К примеру, я выбираю сценарий Web Publishing из списка. Затем я ввожу IP-адрес источника 192.168.1.70, расположенный во внешней сети для данного брандмауэра ISA firewall. Поскольку правило публикования Web требует аутентификации, я ввожу Administrator. Наконец, я ввожу URL http://ssl.msfirewall.org, чтобы убедиться, что брандмауэр ISA firewall разрешает ssl.msfirewall.org в IP-адрес во внешнем интерфейсе брандмауэра, как Web-слушателя, используемого для прослушивания соединения для данного правила.
Если вы помните из предыдущей части этой серии статей, мы создавали неработающее правило публикования Web. Оно не работало по двум причинам:
То есть, данное правило все еще должно не работать, верно? Давайте нажмем на кнопку Start и посмотрим, что произойдет. Симулятор трафика говорит, что все в порядке. Забавно, поскольку этого не должно быть, ведь имя на сертификате несоответствующее.
Давайте нажмем на кнопку View Log. Может, журнал диагностики отметил проблему, не идентифицированную симулятором трафика.
Рисунок 3
Нет. И тут, кажется, все в порядке. The rule Secure Web Site matches the packet. The packet is allowed (Пакет соответствует правилу Secure Web Site. Пакет разрешен).
То есть, кажется, что симулятор трафика также попал впросак, как и кнопка Test. Однако, нельзя сказать, что ISA никак не дал нам знать о наличии проблемы: новый мастер правила публикования Web предупредил нас о том, что существовала проблема с правилом.
И, если быть справедливым, соединение действительно разрешено правилом. Всего лишь несовпадение имени сертификата между публичным именем в правиле публикования Web и общим именем или именем субъекта на слушателе не означает, что соединение не разрешено. Это означает, что клиентский браузер получит ошибку при попытке соединения, но, если пользователь игнорирует эту ошибку, соединение состоится. Но если пользователь использует небраузерный клиент, например, клиент Outlook RPC/ HTTP, предупреждающее окно не появится, и соединение не состоится (по крайней мере, так было с предыдущими версиями Outlook’а. Я верю, что Outlook 2007 RPC/ HTTP обеспечивает механизм обхода такой ошибки).
Имея в виду все это, я утверждаю, что симулятор трафика совсем не ошибся. Соединения с защищенным Web-сайтом разрешены, и, если других проблем нет, все будет в порядке и с клиентской стороны.
Давайте проведем еще одно тестирование симулятора трафика. В данном случае выбираем сценарий Server Publishing. Я введу IP-адрес 192.168.1.70 в качестве адреса источника, который является внешний IP-адресом для нашего брандмауэра. В качестве цели я введу IP-адрес сервера во внешней сети за брандмауэром 10.0.0.2. Протоколом назначения у нас будет TCP, а портом назначения будет 25. В данном примере мы хотим проверить, можно ли установить входящее SMTP соединение с 10.0.0.2.
Я нажимаю на кнопку Start, и результаты теста показывает, что трафик отклоняется правилом по умолчанию default rule. Давайте нажмем на кнопку View Log, чтобы посмотреть, есть ли что-нибудь для нас интересное в журнале диагностики, что могло бы помочь понять, в чем проблема.
Просматривая файл журнала диагностики, мы видим, что брандмауэр ISA firewall проверяет правила системной политики и другие правила. Вы увидите строчку, утверждающую, что The rule Default rule blocked the packet(правило Default rule заблокировало пакет). Предполагается, что нет правила для разрешения пакета. Когда я возвращаюсь к политике брандмауэра на данной машине, я вижу, что, действительно, нет такого правила публикования сервера, разрешающего входящие SMTP к 10.0.0.2. Журнал диагностики спасает еще один день!
К этому времени уже понятно, что улучшения журнала диагностики тесно связаны с симулятором трафика. Использование журнала диагностики вместе с симулятором трафика очень удобно, поскольку можно смотреть только на чистый трафик, и нет необходимости отсеивать лишний трафик. Но иногда вам нужно просмотреть трафик, проходящий через живую сеть с сотнями машин, соединяющимися через брандмауэр ISA firewall. В данном случае вам необходима помощь в разделении леса на деревья.
Для решения этой проблемы сделана новая вкладка Diagnostic Logging в узле Troubleshooting в консоли брандмауэра ISA firewall, которая позволяет легко настроить фильтры для нахождения нужной информации. Давай рассмотрим несколько примеров.
Но перед тем, как вы сможете использовать возможности журнала диагностики, нужно включить журнал диагностики до воспроизведения проблемы. Щелкните на вкладку Tasks в панели задач в узле Troubleshooting. Здесь есть две опции. Одна — Enable Diagnostic Logging(включить журнал диагностики), а другая Delete Diagnostic Log(удалить журнал диагностики). Нужно включить журнал. После воспроизведения проблемы первая опция изменится на Disable Diagnostic Logging(отключить журнал диагностики), которую вам и надо выбрать после завершения воспроизведения.
После завершения воспроизведения, возвращайтесь к консоли брандмауэра и введите какой-нибудь фильтрующий критерий, который поможет найти что-нибудь в файле журнала, что помогло бы решению проблемы. В нашем примере один из пользователей имеет проблемы при соединении с www.bluecoat.com. Наш пользователь хочет соединиться с этим сайтом для проведения исследования набора свойств Blue Coat.
Есть два способа установки фильтра:
Давайте предположим, что я не знаю, что именно я ищу, но подозреваю, что сообщение будет содержать www.bluecoat.com. В данном случае я ввожу www.bluecoat.com в текстовое окно message contains, а затем нажимаю на кнопку Apply Filter.
Оп! Мне повезло. Оказывается, в файле журнала есть соединение, содержащее такую строку. Вы заметите, что обе записи имеют одинаковые значение в колонке контекста. Давайте воспользуемся этой информацией.
Помните, что вы ищете строки, поэтому нет необходимости вводить целое значение, если вы уверены в том, что у вас есть уникальная строка. Смотря на значение контекста, я собираюсь угадать, что других контекстов, содержащих строку c15, нет. Может, я и ошибаюсь; в таком случае надо поискать другую строку, могущую быть уникальной.
Я ввожу c15 в текстовое окно Context contains и нажимаю на Apply Filter.
Теперь журнал показывает все записи с верным контекстом (я вырезал колонку контекста на графике, так чтобы вам легче было видеть все записи). Теперь, когда у нас есть вся информация о соединении, в котором содержится сообщение www.bluecoat.com, давайте посмотрим, что мы сможем выяснить.
Читая файл журнала, вы можете заметить, что есть правило доступа, запретившее соединение. Имя такого правила — Deny Bluecoat(отказать Bluecoat). Теперь я знаю, что у меня есть такое правило в политике брандмауэра, и я могу сменить это правило на разрешение доступа или создать новое правило, разрешающее доступ к сайту www.bluecoat.com отдельному пользователю.
Давайте рассмотрим другой пример. У меня проблема с тестовым опросом внешнего клиента от клиента в сети по умолчанию брандмауэра. Во-первых, надо включить журнал диагностики и начать опрашивать этого клиента. После воспроизведения проблемы я выключаю журнал диагностики и ввожу ping в текстовом окне Message contains и нажимаю на Apply Filter.
Похоже, тут есть пара контекстов, включающих опрос. Давайте введем строку 5949 в текстовом окне Context contains и нажмем на Apply Filter, чтобы увидеть детали соединений.
Рисунок 4
Вы можете увидеть запись, содержащую Protocol: PING. Двигаясь вниз от этой строки, вы закончите на записи, которую я отметил, говорящую: The rule does not match because the rule requires authentication and no user is specified in the packet(правило не соответствует, так как правило требует аутентификации, и ни один пользователь не был указан в пакете). Также есть определение правила, утверждающего, что The rule All Open requires user authentication(Правило All Open требует аутентификации пользователя).
Ого! Свойства журнала диагностики снова спасло нас. Теперь я знаю, что мне нужно убрать требования аутентификации для правила All Open или создать новое правило, разрешающее анонимный доступ к исходящим PING запросам.
Теперь давайте пройдем еще один тест. У моих внутренних клиентов проблемы с отправкой исходящих SMTP сообщений на их Internet SMTP сервер. Для начала включаем журнал диагностики, воспроизводим проблему и выключаем журнал диагностики.
Идем в раздел Filter Criteria и вводим smtp в текстовом окне Message Contains. Поскольку это проблема с SMTP, есть шанс, что “SMTP” появится в сообщениях, касающихся попытки соединения.
Фильтр показывает число записей SMTP с различными номерами контекста. Вместо возвращения в раздел Filter Criteria(что вы тоже можете сделать) щелкните на номер контекста в Context Column, после этого вы увидите все записи с данным номером контекста, как это видно из картинки ниже.
Похоже на то, что проблема с SMTP аналогична проблеме с PING. Если вы внимательно просмотрели записи, относящиеся к данной попытке соединения, вы поняли, что правило All Open требует аутентификации, а при попытке соединения никакой информации о пользователе не отправлялось. Для решения проблемы нужно установить на клиент брандмауэр, чтобы можно было аутентифицировать исходящие сообщения SMTP.
В этой, второй, части нашей двухчастной серии статей о брандмауэре ISA 2006 Service Pack 1 мы углубленно рассмотрели свойства – симулятор трафика и журнал диагностики. Мы убедились, что мы можем использовать симулятор трафика для проб и испытаний проблем, связанных с соединениями, а затем использовать тесно интегрированный журнал диагностики для того, чтобы разобраться с деталями проблемы. Затем мы внимательно рассмотрели возможности журнала диагностики и узнали, как можно использовать фильтрацию в живой, работающей сети для поиска и решения проблем. В обсуждении также рассмотрели несколько случаев в качестве примера решения проблемы с помощью указанных свойств для понимания работы этих свойств и внедрения их в работающую сеть. Спасибо за внимание!.
www.isaserver.org