Проверка конфигурации перед ее доставкой на шлюз безопасности производится в том случае, если был снят флажок Don’t test config at delivering в меню File. По умолчанию тестирование запрещено.
Окно проверки конфигурации Configuration testing (Рисунок 106) появляется, если в результате анализа конфигурации были обнаружены какие-либо ошибки.
Рисунок 106
Состав элементов окна:
· Поле с текстом вывода результатов анализа конфигурации.
· Don’t show this dialog again – флажок синхронизирован с пунктом меню Don’t test config at delivering и предназначен для той же цели – запрещает/разрешает тестировать текущую конфигурацию при доставке на шлюз.
· OK – кнопка закрывает окно и переходит к отправке конфигурации.
· Cancel – кнопка возвращает в окно главной формы.
Во время анализа конфигурации проводится последовательная проверка набора условий. Логика работы правил доступа и правил IPsec устроена так, что проверяемый IP пакет, не попавший под условие ни одного из правил фильтра, отбрасывается, т.е. эффект такой же, как если бы в каждом наборе записей последним стояло правило «deny ip any any». Алгоритм проверки учитывает эту особенность в работе и сообщает о «мнимых» правилах мешающих нормальной работе. Но поскольку необходимо различать их от явно заданных, то в текстовых сообщениях «мнимые» правила выглядят как «deny ip any any (imaginary)».
В описании синтаксиса сообщений используются специальные обозначения:
· вертикальной чертой разделяются варианты, в сообщении обязательно используется один из вариантов;
· в квадратных скобках указываются необязательные части сообщений;
· в угловых скобках указаны сущности, текстовые представления которых будут использованы в сообщении.
Проверяются только входящие фильтрующие правила, привязанные к интерфейсам, как напрямую (Access Rules), так и косвенно через политику IPsec (IPSec Rules).
Результаты проверки группируются по интерфейсам под заголовком:
Checking interface: <interface name>.
Для каждого интерфейса производятся следующие проверки:
· Выполняется анализ правил доступа привязанных к интерфейсу на предмет отсутствия в них разрешающих записей (permit). Должна быть хотя бы одна разрешающая запись, иначе выводится сообщение:
Filtering rule rrr contains only deny entries
· Выполняется анализ правил в статических и динамических криптокартах на предмет отсутствия в них разрешающих записей. Если такие записи отсутствуют, то выводится сообщение:
Crypto rule rrr in [dynamic ] crypto map <cryptomap name> <seq. num> contains only deny entries
· Определяется IP-адрес шлюза безопасности
· Определяется локальный адрес, с которого был запущен графический интерфейс для удаленной настройки шлюза безопасности
· Проверяется возможность общения со шлюзом безопасности с данного локального адреса
· Если включена отсылка сообщения о протоколируемых событиях syslog, то выполняется проверка разрешения трафика от шлюза безопасности к получателю сообщений. Критерии проверки: протокол UDP, адрес отправителя (любой порт), адрес получателя из настроек (порт 514).
· В случае если трафик блокируется фильтрующим правилом, то выводится сообщение:
Filtering rule <filter acl name> blocks syslog traffic from <server addr> to <receiver addr>:514 with entries:
<filter acl entry>
· Если трафик к получателю syslog шифруется, то выводится сообщение:
Crypto rule <crypto acl name> in [dynamic ] crypto map <cryptomap name> <seq. num> protects syslog traffic from <server addr> to <receiver addr>:514 with entries:
<filter acl entry>
· Если были заданы настройки SNMP, то проверяется разрешение трафика от шлюза безопасности к получателям SNMP-трапов. Критерии проверки: протокол UDP, адрес отправителя (любой порт), адрес получателя из конфигурации.
· В случае если трафик блокируется фильтрующим правилом, то выводится сообщение:
Filtering rule <filter acl name> blocks SNMP traps from <server addr> to <receiver addr>:<receiver port> with entries:
<filter acl entry>
· Если трафик к получателю syslog шифруется, то выводится сообщение:
Crypto rule <crypto acl name> in [dynamic ] crypto map <cryptomap name> <seq. num> protects SNMP traps from <server addr> to <receiver addr>:<receiver port> with entries:
<filter acl entry>
Выполняется поиск записей в IPsec правилах, связанных со статическими и динамическими криптокартами, которые полностью заблокированы правилами доступа.
· В данном случае подразумевается ситуация, когда весь трафик, попадающий под правило IPsec, блокируется правилом доступа. При этом отдельное фильтрующее правило может блокировать только часть IPsec правила. При оценке пересечения правил учитывается соотношение указанных в них протоколов, IP-адресов и (для протоколов TCP и UDP протоколов) портов.
Синтаксис сообщений:
Interaction between IPsec and filter ACL Interfaces:
Filter rule <filter acl name> at interface <interface name> blocks crypto maps rules
[ Dynamic templates at: <dynamic cryptomap name> <template sequence number>]
In [dyanmic] crypto map: <cryptomap name> <cm sequence number>
Blocked entries of rule: <crypto acl name>
<crypto acl entry>
В случае возникновения ошибок дальнейшая проверка не производится и выдается сообщение:
Could not estimate filter ACL – Crypto Map interaction.