Из многих улучшенных возможностей ведения журналов(logging), включенных в Service Pack 3 для 2004 ISA Firewall, возможно самым важным является новая диагностическая система журналирования. Новая диагностическая система журналирования добавляет 200 новых событий, которые могут быть зафиксированы, когда система активирована. Эти события появляются в новой секции, добавленной в окне Event Viewer, которую назвали ISA Server Diagnostics.
Но есть одна проблема – система может зафиксировать тысячи событий в очень короткое время. Даже, если Вы очень ограничите параметры, все равно существует опасность потерять сотни событий, которые, возможно, являются самыми важными. Для того, чтобы решить эту проблему команда ISA Firewall сделала Microsoft ISA Server Diagnostic Logging Viewer, которая позволяет отфильтровывать некоторые наименее интересные события для внесения в ISA Server Diagnostics.
ISA Server Diagnostic Logging Viewer – это инструмент, запускаемый с командной строки, для запроса и просмотра событий, фиксированных диагностической системой журналирования событий. Инструмент строит запросы на основе опций, которые вы задаете в командной строке, и затем применяет Log Parser 2.2 для фильтрации.
Результат может выводиться в командной строке, или графическом окне Log Parser-а, или может быть сохранен в HTML-файле, который можно просмотреть обычным Internet Explorer-ом. В информации, показанной Internet Explorer-ом, можно дополнительно получить информацию по определенному контексту..
Вероятно, вы уже знаете, что я не являюсь поклонником использования командной строки вместо графического интерфейса, который предоставляет больше возможностей администратору. Однако, Diagnostic Logging Viewer очень прост в использовании и не требует запоминать команды в 600 символов, которые необходимы для самых простых действий в управлении Exchange 2007 Server.
В этой статье мы рассмотрим, как применять Diagnostic Logging Viewer для диагностики проблем ISA Firewall:
- Скачайте и установите Log Parser 2.2
- Скачайте и установите ISA Firewall Diagnostic Logging Viewer
- Активируйте Diagnostic Logging (диагностику журнала событий)
- Создайте материал для проверки
- Запустите Diagnostic Logging Viewer
Скачивание и установка Log Parser 2.2
Диагностическая система использует Log Parser 2.2 для фильтрации событий. Во-первых, скачайте и установите Log Parser 2.2.
Сделайте двойной щелчок на файле LogParser.msi и следуйте указаниям мастера установки, используя опцию Complete. Вам не надо перезапускать компьютер после окончания инсталляции.
Скачивание и установка ISA Firewall Diagnostic Logging Viewer
Далее необходимо установить ISA Server Diagnostic Logging Viewer. Не пытайтесь отыскать его самостоятельно на сайте http://www.microsoft.com/ . Поиск на сайте ни чего не даст!
Двойной щелчок на dlviewer.exe, и укажите место, куда будет производиться установка. Т.к. нам придется использовать командную строку, рекомендую использовать простое и короткое имя директории, чтобы не допускать ошибок при вводе текста В этом примере я буду использовать C:\ISALOG. В процессе установка не вносятся изменения в операционную систему и не устанавливаются системные файлы. Просто, файлы распаковываются в указанную директорию.
Активация Diagnostic Logging
Теперь, когда все готово, мы можем запускать. После установки ISA 2004 SP3, Вы обнаружите на левой панели консоли ISA Firewall новый узел, который называется Troubleshooting (см. Рис.1).
Рисунок 1
В средней области консоли ISA Firewall находятся 5 ссылок. Вот они:
- Use the ISA Server Best Practice Analyzer (использовать лучший анализатор ISA Server)
- View ISA Server Alerts (просмотр предупреждений ISA Server)
- View ISA Server Logging (просмотр журнала событий ISA Server)
- Configure Diagnostic Logging (настройка диагностики журнала событий)
- Read ISA Server Documents and Troubleshooting Guides (прочитать документацию и руководство по устранению неполадок в ISA Server)
Вы можете видеть эти ссылки в числе ниже.
Рисунок 2
Нажмите на Configure Diagnostic Logging в средней части консоли ISA Firewall и увидите диалог-бокс Diagnostic Logging как показано ниже. У Вас есть два вида событий, которые можно записать в журнал:
- Firewall policy активирует журналирование информации о правилах firewall policy, которые включают трафик Web proxy.
- Authentication активирует журналирование информации о правиле идентификации firewall policy.
Еще есть три кнопки:
- Start Logging запускает журналирование событий
- Clear Log Data очищает информацию (очищается раздел ISA Server Diagnostics в Event Viewer)
- View Log Data открывает Windows Event Viewer и показывает содержание раздела ISA Server Diagnostic
Рисунок 3
После нажатия кнопки Start Logging, в Event Log будет записываться подробнейшая информация. Это может привести к существенной загрузке процессора. Поэтому, применяйте диагностику только тогда, когда Вы в этом действительно нуждаетесь. После запуска нажмите кнопку Close. Покажется диалоговое окно предупреждения как показано ниже. Нажмите No, чтобы продолжить работу.
Рисунок 4
Консоль ISA Firewall информирует, что идет процесс журналирование, чтобы Вы не удивлялись, что производительность процессора упала. Это демонстрируется в средней части консоли ISA Firewall, как показано на рисунке 5.
Рисунок 5
Создание трафика
Теперь давайте сгенерируем некоторый трафик для исследования. В этом примере я создал три правила, один позволяющий выходной трафик SMTP, второй позволяющий выходной трафик NNTP, и третий SMTP Server Publishing Rule.
Как вы видите ниже, я попытался обратиться через telnet к внешнему серверу SMTP и произошел сбой подключения. Почему? Давайте применим нашу систему журналирования.
Рисунок 6
На рисунке ниже я обратился через telnet к published SMTP server с внешнего клиента. Произошел сбой попытки подключения. И все, что мы видим – пустой экран. Не очень много, что бы понять проблему. Возможно, наша система поможет решить эту задачу?
Рисунок 7
На рисунке ниже видно несколько неудачных попыток подключения к серверу NNTP. Поможет наша система выяснить – почему?
Рисунок 8
Запускаем Diagnostic Logging Viewer для диагностики
Есть четыре способа для просмотра информации:
- Непосредственно в окне Event Viewer
- В командной строке (эта информация может быть записана в текстовый файл)
- В окне Log Parser-а
- Как Web-страница
На рисунке 9 показано окно Event Viewer. Нам не нужно использовать специальные средства, что бы увидеть эту информацию. Но эта информация не отфильтрована. Необходимая информация теряется в общей массе. Обратите внимание, что зафиксировано почти 6000 событий в течении не более 10 минут в условиях очень не нагруженной лабораторной сети.
Рисунок 9
Средство просмотра лог-файла ISA Firewall позволяет Вам разгрести эти завалы. Так как это базируется на Log Parser 2.2, Вы можете применять запросы SQL, если к Вашему счастью Вы еще являетесь и администратором баз данных. Но даже если Вы не знакомы с базами данных, Вы можете легко отыскать информацию в текстовых строках.
Описание команд, как использовать diagnostic log viewer, содержаться в текстовом файле, который находится в том же каталоге, где и остальные файлы. На рисунке ниже показано содержание этого файла.
Рисунок 10
Давайте рассмотрим несколько примеров. Как показано на рисунке ниже, мы ввели команду:
Dlviewer “nntp outbound”
Где nntp outbound является названием Access Rule (Правило Доступа), которое позволяет исходящие подключения NNTP.
Результат этой команды виден ниже. Мы видим сообщения, говорящие о том, что NNTP пытается совершить внешнее подключение. Эта информация не очень интересна. Единственное, что можно узнать, ISA Firewall получила запрос на установление соединения.
Рисунок 11
Другой способ увидеть диагностическую информацию – использовать окно Log Parser. На рисунке ниже я ввел команду:
dlviewer –ogrid “smtp outbound”
Где “smtp outbound” название Access Rule (Правило Доступа), которое позволяет внешние подключения SMTP.
Рисунок 12
В результате этой команды мы видим в таблице Log Parser некоторую информацию о внешних подключениях SMTP, соответствующих названию Access Rule. Столбец Context включает число, которое идентифицирует каждую попытку подключения, соответствующую SMTP Access Rule. Теперь мы видим причину неудачного подключения — требуется идентификация пользователя (user authentication). Обратите внимание на столбец Log Source. Этот столбец предоставляет информацию относительно того, кто принимал решение по подключению — Firewall Engine или Firewall Service. Если фильтр Firewall Engine не может принять однозначное решение, то он передает запрос на установление соединения на Firewall Service.
Рисунок 13
На рисунке ниже я ввел команду:
dlviewer –odir tst1 “smtp outbound”
Где “smtp outbound”название Access Rule (Правило Доступа), позволяющего внешние подключения SMTP.
Рисунок 14
После выполнения этой команды Вы можете заглянуть в каталог, который Вы включили в команду, и обнаружить там файлы HTML. В этом примере, я поместил файлы в каталог tst1, который будет размещен внутри папки, где находятся наши рабочие файлы.
Web-страница предоставляет Вам подробную информацию о попытках подключения, соответствующих правилу, включенному в запрос. Обратите внимание на столбец Context. Вы можете нажать на число и получить исчерпывающую информацию о том, какое решение принял ISA Firewall на попытку подключения.
Рисунок 15
Рисунок ниже дает частичное представление о том, что записал ISA Firewall для одиночной попытки установки внешнего SMTP соединения. Если Вы внимательно ознакомитесь с этой информацией, то увидите порядок, в котором ISA Firewall оценивает правила. Часть информации непонятна и кажется не относящейся к данному подключению. Эта «посторонняя» информация, говорит о том, что ISA Firewall оценивает подключения не только по тем критериям, которые определены в Firewall Policy. Или говорит о том, что многие события в лог-фале не опубликованы для «широких масс» (пока?).
В этом примере, мы увидим, что подключение SMTP не удалось, потому что была затребована идентификация, а клиент не смог идентифицироваться на ISA Firewall.
Если Вы нажмете на число в столбце Context, то увидите более детальное описание того, что случилось этим подключением.
Рисунок 16
На рисунке ниже я ввел следующую команду:
dlviewer –odir tst5 “nntp outbound”
Где “nntp outbound”является названием Access Rule (Правило Доступа), которое позволяет внешние подключения NNTP.
Рисунок 17
На рисунке ниже виден результат этого запроса. Нет ничего похожего на то, что поможет решить нашу проблему. Может быть, стоит нажать на число в столбце Context, связанное с конкретной попыткой подключения.
Рисунок 18
Вот здесь есть подсказка. В нескольких местах лог-файла отмечаем, что source does not match the packet. Что это значит? Ваше предположение столь же правильно, как и мое. Это может означать, что исходящий IP-адрес не соответствует требованиям Access Rule. Если это так, то система диагностики помогла нам. Потому что, причина неудачного подключения в том, что Access Rule ограничило внешние подключения NNTP для определенного IP.
Рисунок 19
На рисунке ниже, я ввел следующую команду:
dlviewer –odir tst “smtp server”
Где “smtp server” название Server Publishing Rule, находящегося на SMTP сервер, во внутренней сети, за ISA Firewall.
Рисунок 20
На рисунке ниже показаны результаты запроса. Мы видим, что SMTP Server Publishing Rule принял пакет. O’кей. Если так, значит все в порядке и с конфигурацией ISA Firewall. Так в чем причина? На сервере SMTP не запущен сервис SMTP!
Рисунок 21
Заключение
В целом, новая система диагностики и журналирования событий, и средства просмотра, являются великолепной новой составляющей Service Pack 3 для ISA 2004 firewall. Однако, имеющаяся документация (которая включает очень короткий текстовый файл) крайне скудна и не позволяет использовать все возможности инструмента. Есть очень много информации, которая фиксируется в лог-файлах, но эта информация не понятна. Что означает «source doesn’t match the packet» («источник не соответствует пакету»), или «the source port doesn’t match the rule» («исходный порт не соответствует правилу»)? Если бы была полная документация на все более, чем 200 диагностирующих событий, мы бы смогли получить больше пользы от этого нового инструмента.
www.isaserver.org