ClusterXL Administration Guide R75 - rrc.rurrc.ru/uploads/20180627/CP_R75.40VS_ClusterXL_AdminGuide_RUS.… · Title: ClusterXL Administration Guide R75.40VS Author: Check Point Software

ClusterXL

R75.40VS

Руководство администратора

25 октября 2012 г.

© 2012 Check Point Software Technologies Ltd.

Все права защищены. Данное изделие и документация по нему охраняются авторским правом и распространяются по лицензии с ограничением их использования, копирования, распространения и декомпиляции. Воспроизведение любой части данного изделия и документации по нему в любой форме и любыми средствами без предварительного письменного разрешения компании Check Point запрещено. Хотя при подготовке этого материала были приняты все меры предосторожности, компания Check Point не несет ответственности за ошибки и пропуски. Это издание и описываемые в нем средства могут быть изменены без уведомления.

ИНФОРМАЦИЯ ОБ ОГРАНИЧЕНИИ ПРАВ:

Использование, размножение и разглашение государством осуществляется с ограничениями, установленными п. (с)(1)(ii) статьи "Права на технические данные и компьютерное программное обеспечение" приложения к Федеральному положению о военных закупках DFARS 252.227-7013 и Постановления о федеральных закупках FAR 52.227-19.

ТОРГОВЫЕ ЗНАКИ:

Список наших торговых знаков см. на странице об авторском праве (http://www.checkpoint.com/copyright.html).

Список соответствующих авторских прав и лицензий третьих лиц см. в уведомлениях об авторских правах третьих лиц (http://www.checkpoint.com/3rd_party_copyright.html).

http://www.checkpoint.com/copyright.html

http://www.checkpoint.com/3rd_party_copyright.html

Важная информация Последняя версия ПО

Мы рекомендуем установить самую последнюю версию ПО, чтобы иметь возможность пользоваться последними функциональными улучшениями, исправлениями стабильности, улучшенными средствами безопасности и защитой от новых и развивающихся атак.

Последняя версия документации

Последняя версия документации размещена на странице: http://supportcontent.checkpoint.com/documentation_download?ID=16221

Для получения дополнительной технической информации посетите центр поддержки Check Point (http://supportcenter.checkpoint.com).

Подробнее об этом издании см. на главной странице R75.40VS (http://supportcontent.checkpoint.com/solutions?id=sk76540).

История изменений

Дата Описание

25 октября 2012 г. Улучшенное форматирование и разбивка. Без изменений в содержании

15 июля 2012 г. Первое издание этого документа

Обратная связь

Check Point ведет непрерывную работу над усовершенствованием своей документации.

Мы просим вас помочь нам, отправив свои комментарии (mailto:[email protected]?subject=Feedback on ClusterXL R75.40VS Administration Guide).

http://supportcontent.checkpoint.com/documentation_download?ID=16221

mailto:[email protected]

mailto:[email protected]

Оглавление

Важная информация ...................................................................................................................... 3 Знакомство с ClusterXL ................................................................................................................. 8

Необходимость в кластерах ......................................................................................................... 8 Решение ClusterXL ........................................................................................................................ 8 Как работает ClusterXL ................................................................................................................. 8

Протокол управления кластером ............................................................................................. 9 Установка и поддерживаемые платформы ................................................................................ 9 Лицензии на ClusterXL .................................................................................................................. 9 Синхронизация часов в ClusterXL.............................................................................................. 10 Термины и определения ............................................................................................................. 10 Панель инструментов SmartDashboard ..................................................................................... 11

Синхронизация информации о соединениях в кластере ..................................................... 12 Решение State Synchronization от Check Point ......................................................................... 12

Сеть синхронизации ................................................................................................................ 12 Как работает State Synchronization ........................................................................................ 13 Несинхронизируемые сервисы .............................................................................................. 13 Конфигурирование несинхронизируемых сервисов ............................................................ 13 Синхронизация с ограничением продолжительности .......................................................... 14 Соединения без привязки ....................................................................................................... 14 Пример соединения без привязки: трехэтапное TCP-квитирование .................................. 15 Синхронизация соединений без привязки ............................................................................ 15 Синхронизация кластеров в глобальной компьютерной сети ............................................. 15 Ограничения синхронизации кластеров ................................................................................ 16

Конфигурирование State Synchronization .................................................................................. 16 Конфигурирование несинхронизируемого сервиса ............................................................. 16 Создание синхронизируемых и несинхронизируемых версий ............................................ 17 Конфигурирование синхронизации с ограничением продолжительности ......................... 17

Соединения с привязкой ............................................................................................................. 18 О соединениях с привязкой ........................................................................................................ 18 Опция Sticky Decision Function ................................................................................................... 18 VPN-туннели со сторонними равноправными узлами и распределением нагрузки ............. 18 Сторонние шлюзы в развернутых системах Hub and Spoke ................................................... 19 Конфигурирование опции Sticky Decision Function .................................................................. 20 Создание стороннего шлюза в развернутой системе Hub and Spoke .................................... 21

Высокая доступность и распределение нагрузки в ClusterXL ............................................ 22 О режимах High Availability и Load Sharing ............................................................................... 22

Режим Load Sharing ................................................................................................................. 22 Пример топологии ClusterXL ...................................................................................................... 22

Определение IP-адресов элементов кластера ..................................................................... 23 Определение виртуальных IP-адресов элементов кластера .............................................. 24 Сеть синхронизации ................................................................................................................ 24 Настройка адресов кластера в разных подсетях ................................................................. 24

Режимы ClusterXL ....................................................................................................................... 24 Режим Load Sharing Multicast ................................................................................................. 25 Режим Load Sharing Unicast ................................................................................................... 25 Режим High Availability ............................................................................................................. 26 Таблица сравнения режимов ................................................................................................. 27

Аварийное переключение .......................................................................................................... 28

Когда происходит аварийное переключение? ...................................................................... 28 Что происходит при восстановлении шлюза? ...................................................................... 29 Как восстановленный элемент кластера получает политику безопасности ...................... 29

Факторы, учитываемые при планировании реализации ......................................................... 29 High Availability или Load Sharing ........................................................................................... 29 Выбор режима Load Sharing ................................................................................................... 29 Миграция IP-адресов............................................................................................................... 30

Требования к аппаратному обеспечению, совместимость и пример Cisco ........................... 30 Требования к аппаратному обеспечению ClusterXL ............................................................ 30 Аппаратная совместимость ClusterXL ................................................................................... 31 Пример конфигурации маршрутизирующего коммутатора Cisco Catalyst ......................... 32

Программная совместимость Check Point ................................................................................ 33 Совместимость с операционными системами ...................................................................... 33 Совместимость ClusterXL (кроме IPS) ................................................................................... 33 Совместимость ClusterXL с IPS.............................................................................................. 34 Механизм Forwarding Layer .................................................................................................... 35

Конфигурирование топологии кластера .................................................................................... 35 Конфигурирование ClusterXL ..................................................................................................... 37

Подготовка элементов кластера ................................................................................................ 37 Конфигурирования маршрутизации для машин-клиентов ...................................................... 37 Выбор режима передачи CCP на элементах кластера ........................................................... 38 Конфигурирование объектов и элементов кластера ............................................................... 38

Использование мастера ......................................................................................................... 39 Конфигурирование в классическом режиме ......................................................................... 39

ClusterXL High Availability для IPv6 ............................................................................................ 41 ClusterXL High Availability ........................................................................................................ 41 Конфигурирование кластеров IPv6 ........................................................................................ 41

Работа с продуктами кластеризации, имеющими сертификат OPSEC .............................. 42 О продуктах кластеризации, имеющих сертификат OPSEC ................................................... 42 Конфигурирование продуктов кластеризации, имеющих сертификат OPSEC ..................... 42

Подготовка коммутаторов и конфигурирование маршрутизации ....................................... 42 Подготовка машин — элементов кластера ........................................................................... 42 Конфигурация SmartDashboard для кластеров OPSEC ....................................................... 43

Особенности работы командной строки CPHA в кластерах OPSEC ..................................... 45 Команды cphastart и cphastop в кластерах OPSEC .............................................................. 45 Команда cphaprob в кластерах OPSEC ................................................................................. 45

Мониторинг и диагностика неполадок кластеров шлюзов .................................................. 46 Проверка исправной работы кластера ...................................................................................... 46

Команда cphaprob .................................................................................................................... 46 Мониторинг состояния кластера ............................................................................................ 47 Мониторинг интерфейсов кластера ....................................................................................... 49 Мониторинг критических устройств ....................................................................................... 50 Регистрация критического устройства .................................................................................. 51 Регистрация критических устройств, перечисленных в файле ........................................... 51 Отмена регистрации критического устройства ..................................................................... 51 Информирование ClusterXL о состоянии критического устройства ................................... 52 Пример скрипта cphaprob ....................................................................................................... 52

Мониторинг состояния кластера с помощью клиентов SmartConsole ................................... 52 SmartView Monitor .................................................................................................................... 52 SmartView Tracker .................................................................................................................... 53

Команды конфигурирования ClusterXL ..................................................................................... 55 Команда cphaconf .................................................................................................................... 55 Команды cphastart и cphastop ................................................................................................ 55

Как инициировать аварийное переключение ........................................................................... 56 Выключение элемента кластера ............................................................................................ 56

Запуск элемента кластера ...................................................................................................... 56 Мониторинг синхронизации (fw ctl pstat) ................................................................................... 56 Диагностика проблем синхронизации ....................................................................................... 58

О команде cphaprob [-reset] syncstat ...................................................................................... 58 Вывод команды cphaprob [-reset] syncstat ............................................................................. 59 Опции диагностики проблем синхронизации ........................................................................ 65

Сообщения об ошибках ClusterXL ............................................................................................. 67 Общие сообщения об ошибках ClusterXL ............................................................................. 67 Сообщения в активном режиме SmartView Tracker ............................................................. 68 Сообщения об ошибках, связанные с синхронизацией ....................................................... 68 Сообщения о несоответствии TCP таблице состояний ....................................................... 69 Сообщения об ошибках, специфические для платформ ..................................................... 69

Отказ запуска элемента после перезагрузки ........................................................................... 70 Дополнительное конфигурирование ClusterXL ..................................................................... 72

Работа с сетями VPN и кластерами .......................................................................................... 72 Конфигурирование VPN и кластеров ..................................................................................... 72 Определение равноправных кластеров VPN c отдельными серверами

управления безопасностью .................................................................................................... 73 Работа с NAT и кластерами ....................................................................................................... 73

Трансляции Cluster Fold и Cluster Hide .................................................................................. 73 Настройка NAT на кластере шлюзов ..................................................................................... 73 Настройка NAT на элементе кластера .................................................................................. 73

Работа с VLAN и кластерами ..................................................................................................... 74 Поддержка VLAN в ClusterXL ................................................................................................. 74 Подключение нескольких кластеров в одной VLAN ............................................................. 74

Мониторинг состояния канала интерфейса .............................................................................. 76 Активация мониторинга состояния канала интерфейса ...................................................... 76

Агрегирование каналов и кластеры ........................................................................................... 77 Общий обзор ............................................................................................................................ 77 Агрегирование каналов: режим High Availability ................................................................... 78 Агрегирование каналов: режим Load Sharing ....................................................................... 81 Определение VLAN-сетей в агрегации интерфейсов .......................................................... 83 Рекомендации по производительности агрегирования каналов ........................................ 83 Команды ClusterXL для агрегаций интерфейсов .................................................................. 84 Диагностика неполадок агрегированных интерфейсов ....................................................... 85

Дополнительное конфигурирование кластера ......................................................................... 86 Как настроить параметры конфигурации шлюза .................................................................. 86 Как сконфигурировать шлюз, чтобы настройки сохранялись после перезагрузки ........... 87 Настройка модульных переменных в IPSO 6.1 и последующих версиях .......................... 87 Управление таймерами кластеризации и синхронизации ................................................... 87 Блокировка новых соединений при нагрузке ........................................................................ 88 Работа со SmartView Tracker в активном режиме ................................................................ 89 Уменьшение количества ожидающих пакетов ..................................................................... 89 Настройка дополнительных опций полной синхронизации ................................................. 89

Определение отключенных интерфейсов ................................................................................ 90 Определение отключенного интерфейса в Unix .................................................................. 90 Определение отключенного интерфейса в Windows ........................................................... 90

Настройка тайм-аута обновления политики ............................................................................. 90 Расширенное применение трехэтапного TCP-квитирования ................................................. 91 Настройка адресов кластера в разных подсетях ..................................................................... 91

Об адресах кластера в разных подсетях .............................................................................. 91 Настройка адресов кластера в разных подсетях ................................................................. 91 Пример адресов кластера в разных подсетях ...................................................................... 92 Ограничения при настройке адресов кластера в разных подсетях .................................... 93

Переход от одного шлюза к кластеру ClusterXL ....................................................................... 94

На одной машине-шлюзе ........................................................................................................ 94 На машине "В" ......................................................................................................................... 94 На панели инструментов SmartDashboard для машины "В" ................................................ 95 На машине "А" ......................................................................................................................... 95 На панели инструментов SmartDashboard для машины "А" ................................................ 95

Добавление элемента в существующий кластер ..................................................................... 95 Настройка ISP-резервирования на кластере ............................................................................ 96 Активация протоколов динамической маршрутизации в развернутом кластере .................. 97

Компоненты системы .............................................................................................................. 97 Динамическая маршрутизация в ClusterXL ........................................................................... 97

Режим High Availability Legacy ................................................................................................... 99 О режиме High Availability Legacy .............................................................................................. 99 Пример развернутой системы в режиме совместимости ...................................................... 100 Факторы, учитываемые при планировании ............................................................................ 101

Миграция IP-адресов............................................................................................................. 101 Расположение сервера управления безопасностью ......................................................... 101 Настройка маршрутизации ................................................................................................... 101 Коммутаторы (передача 2-го уровня) как влияющий фактор ............................................ 101

Настройка режима High Availability Legacy ............................................................................. 101 Настройка маршрутизации ................................................................................................... 102 Конфигурация SmartDashboard ............................................................................................ 102

Переход с High Availability Legacy при минимуме усилий ..................................................... 103 На шлюзах .............................................................................................................................. 104 На панели инструментов SmartDashboard .......................................................................... 104

Переход с High Availability Legacy с минимизацией простоя ................................................ 104 Пример скрипта cphaprob ......................................................................................................... 106

Дополнительная информация ................................................................................................. 106 Скрипт clusterXL_monitor_process ........................................................................................... 106

Алфавитный указатель ............................................................................................................. 109

Руководство администратора ClusterXL R75.40VS | 8

Глава 1

Знакомство с ClusterXL

В этой главе Необходимость в кластерах 8

Решение ClusterXL 8

Как работает ClusterXL 8

Установка и поддерживаемые платформы 9

Лицензии на ClusterXL 9

Синхронизация часов в ClusterXL 10

Термины и определения 10

Панель инструментов SmartDashboard 10

Необходимость в кластерах Шлюзы и VPN-соединения являются критически важными устройствами для бизнеса. Отказ шлюза безопасности или VPN-соединения может привести к потере активных соединений и доступа к критическим данным. Шлюз между организацией и миром должен оставаться открытым при любых обстоятельствах.

Решение ClusterXL Кластер ClusterXL — это группа идентичных шлюзов безопасности Check Point, соединенных таким образом, что в случае отказа одного шлюза его место немедленно занимает другой.

ClusterXL — это программное решение распределения нагрузки и высокой доступности, предназначенное для распределения сетевого трафика между кластерами резервных шлюзов безопасности и обеспечения прозрачного аварийного переключения между машинами кластера.

Кластер высокой доступности обеспечивает резервирование шлюза и VPN-соединения путем прозрачного аварийного переключения на резервный шлюз в случае отказа.

Кластер c распределением нагрузки обеспечивает надежность, а также повышает производительность, благодаря тому, что все элементы кластера остаются активными.

Как работает ClusterXL В ClusterXL для элементов кластера используются уникальные физические IP- и MAC-адреса, а сам кластер представлен виртуальными IP-адресами. Виртуальные IP-адреса не относятся к реальному машинному интерфейсу (исключение составляет режим High Availability Legacy, описываемый ниже).

ЛВС

Внутренний коммутатор

Кластер шлюзов

Маршрутизатор

Внешний коммутатор Кластер шлюзов

Интернет



ClusterXL обеспечивает инфраструктуру, которая позволяет предотвратить потерю данных в результате отказа, так как каждому элементу кластера известно о соединениях, проходящих через другие элементы. Передача информации о соединениях и состояниях других шлюзов безопасности между элементами кластера называется синхронизацией состояний.

Создание кластеров шлюзов безопасности также возможно с помощью продуктов высокой доступности и распределения нагрузки, имеющих сертификат OPSEC. В продуктах кластеризации, имеющих сертификат OPSEC, используется такая же инфраструктура синхронизации состояний, как в ClusterXL.

Примечание: в данном руководстве решение ClusterXL рассматривается только в

режиме Security Gateway (Шлюз безопасности). Подробнее о режиме VSX см. в "Руководстве администратора R75.40VS VSX" (http://supportcontent.checkpoint.com/solutions?id=sk76540).

Протокол управления кластером Протокол управления кластером (CCP) является связующим звеном, объединяющим машины в кластере шлюзов Check Point. CCP-трафик отличается от обычного сетевого трафика, и его можно просматривать с помощью любого сетевого анализатора. CCP выполняется на UDP-порте 8116 и выполняет следующие функции:

Он позволяет элементам кластера сообщать о собственных состояниях и узнавать о состояниях других элементах с отправкой пакетов подтверждения активности (это относится только к кластерам ClusterXL).

Синхронизация состояний.

CCP-протокол от Check Point используется во всех режимах ClusterXL, а также кластерами OPSEC. Однако задачи, выполняемые этим протоколом, и способы их реализации могут отличаться в зависимости от типов кластеризации.

Примечание: вам не нужно добавлять в базу правил политики безопасности правило о принятии CCP.

Установка и поддерживаемые платформы ClusterXL должен быть установлен в распределенной конфигурации, в которой сервер управления безопасности и элементы кластера установлены на разных машинах. ClusterXL входит в стандартный пакет установки шлюза безопасности.

Инструкции по установки см. в "Руководстве по установке и модернизации R75.40VS" (http://supportcontent.checkpoint.com/solutions?id=sk76540).

Платформы, поддерживаемые ClusterXL, приведены в "Примечаниях к изданию R75.40VS" (http://supportcontent.checkpoint.com/solutions?id=sk76540).

Лицензии на ClusterXL Чтобы использовать ClusterXL для повышения доступности, каждый шлюз в конфигурации должен иметь регулярную лицензию на шлюз, а каждая машина управления должна иметь лицензию на каждый определенный кластер.

Чтобы использовать ClusterXL для распределения нагрузки, каждый шлюз в конфигурации должен иметь регулярную лицензию на шлюз, а каждая машина управления должна иметь лицензию на каждый определенный кластер и одну дополнительную простую лицензию cluster-1.

При этом количество шлюзов, включенных в кластер, значения не имеет. Если нужные лицензии не установлены, операция по установке политики выполнена не будет.

Для получения дополнительной информации о лицензиях посетите центр поддержки Check Point (http://usercenter.checkpoint.com).

http://supportcontent.checkpoint.com/solutions?id=sk76540

http://usercenter.checkpoint.com/



Синхронизация часов в ClusterXL При использовании ClusterXL обязательно синхронизируйте часы всех элементов кластера. Вы можете синхронизировать часы вручную или с помощью протокола, например NTP. Такие опции, как VPN, правильно функционируют, только если часы всех элементов кластера синхронизированы.

Термины и определения Разные поставщики по-разному определяют термины, касающиеся кластеров шлюзов, высокой доступности и распределения нагрузки. Check Point при описании кластеров использует следующие термины и определения:

Режим Active Up — когда машина высокой доступности, которая была активной и перенесла отказ, снова

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

Кластер — группа машин, совместная работа которых обеспечивает распределение нагрузки и/или высокую доступность.

Критическое устройство — устройство, определенное администратором как имеющее критическое значение для работы элемента кластера. Критическое устройство также называется сообщением о проблеме (pnote). Критические устройства находятся под постоянным контролем. Если критическое устройство перестает работать, это определяется как отказ. Устройство может быть как аппаратурой, так и

процессом. Процессы fwd и cphad по умолчанию предопределены как критические устройства. Политика

безопасности тоже предопределена как критическое устройство. Администратор может добавить список

критических устройств, используя команду cphaprob.

Отказ — проблема, связанная с аппаратным или программным обеспечением, которая приводит к неспособности машины фильтровать пакеты. Отказ активной машины приводит к аварийному переключению.

Аварийное переключение — переход функции фильтрации пакетов от отказавшей машины кластера к другой машине.

Высокая доступность — способность поддерживать соединение при отказе путем его передачи другой машине кластера без потери подключения. Фильтрация пакетов осуществляется только активной машиной. Активной машиной является одна из машин кластера. В случае отказа активной машины ее обязанности переходят одной из других машин кластера.

Горячий резерв — или "Активный/Резервный". Имеет такое же значение, что и "высокая доступность".

Распределение нагрузки — на кластере шлюзов с распределением нагрузки фильтрация пакетов выполняется всеми машинами кластера. Распределение нагрузки обеспечивает высокую доступность, прозрачное аварийное переключение на любую из других машин кластера при отказе, а также повышенную надежность и производительность. Распределение нагрузки также называют режимом Active/Active (Активный/Активный).

Многоадресное распределение нагрузки — в режиме многоадресного распределения нагрузки ClusterXL каждый элемент кластера получает все пакеты, отправляемые на IP-адрес кластера. Маршрутизатор или коммутатор 3-го уровня пересылает пакеты всем элементам кластера, работающим в многоадресном режиме. Алгоритм решения ClusterXL на всех элементах кластера определяет, какой элемент кластера будет выполнять принудительную обработку пакета.

Одноадресное распределение нагрузки — в режиме одноадресного распределения нагрузки ClusterXL одна (главная) машина получает весь трафик от маршрутизатора с одноадресной конфигурацией и переадресует пакеты на другие машины кластера. Главную машину ClusterXL выбирает автоматически.



Панель инструментов SmartDashboard C помощью панели SmartDashboard вы можете выполнять следующие действия:

Иконка Описание

Открытие меню SmartDashboard.

Если вам нужно выбрать опции меню, сначала щелкните по этой кнопке.

Например, если вам нужно выбрать Manage > Users and Administrators (Управление > Пользователи и администраторы), щелкните по этой кнопке, откройте меню Manage, а затем выберите опцию Users and Administrators.

Сохранение текущей политики и всех системных объектов.

Обновление политики с сервера управления безопасностью.

Изменение общих свойств.

Проверка непротиворечивости базы правил.

Установка политики на шлюзах безопасности или шлюзах VSX.

Открытие SmartConsole.


Глава 2

Синхронизация информации о соединениях в кластере

В этой главе

Решение State Synchronization от Check Point 12

Конфигурирование State Synchronization 16

Решение State Synchronization от Check Point Отказ брандмауэра приводит к немедленной потере активных входящих и исходящих соединений организации. Многие из этих соединений, например, финансовые транзакции, предназначены для решения ответственных задач, и их потеря приведет к потере критической информации. ClusterXL обеспечивает инфраструктуру, которая предотвращает потерю данных в результате отказа, так как каждому элементу кластера известно о соединениях, проходящих через другие элементы. Передача информации о соединениях и состояниях других шлюзов безопасности между элементами кластера называется синхронизацией состояний.

Синхронизации подвергается каждый IP-сервис (включая TCP и UDP), распознанный шлюзом безопасности.

Синхронизация состояний используется как кластером ClusterXL, так и сторонними продуктами кластеризации, имеющими сертификат OPSEC.

Машины в конфигурации ClusterXL Load Sharing (Распределение нагрузки) должны быть синхронизированы в обязательном порядке. Машины в конфигурации ClusterXL High Availability (Высокая доступность) необязательно синхронизировать, но, если они не синхронизированы, то при отказе соединения будут потеряны.

Сеть синхронизации Сеть синхронизации используется для передачи синхронизирующей информации о соединениях и состояниях других шлюзов безопасности между элементами кластера.

Поскольку сеть синхронизации передает наиболее ценную для организации информацию политики безопасности, крайне важно защитить ее от вредоносных и непреднамеренных угроз. Для защиты интерфейсов синхронизации мы рекомендуем использовать один из следующих методов:

Использование выделенной сети синхронизации

Прямое подключение физических сетевых интерфейсов элементов кластера кросс-кабелем. В кластере с тремя и более элементами используйте выделенный хаб или коммутатор

Примечание: вы можете синхронизировать элементы по глобальной компьютерной сети (WAN), выполнив инструкцию по синхронизации кластеров в глобальной компьютерной сети (см. "Синхронизация кластеров в глобальной компьютерной сети" на стр. 15).

Следование этим рекомендациям гарантирует безопасность сети синхронизации, потому что в других сетях синхронизирующая информация отсутствует.

Вы можете определить несколько сетей синхронизации для целей резервирования. Рекомендуется выделить для резерва специальную сеть.

В Cluster XL сеть синхронизации поддерживается на самом низком VLAN-теге VLAN-интерфейса. Например, если на интерфейсе eth1 настроено три сети VLAN с тегами 10, 20 и 30, то для синхронизации можно использовать интерфейс eth1.10.



Как работает State Synchronization Синхронизация работает в двух режимах:

Full sync (Полная синхронизация) передает всю информацию из таблиц ядра шлюзов безопасности от одного элемента кластера другому. Она осуществляется демоном fwd посредством зашифрованного TCP-соединения.

Delta sync (Дельта-синхронизация) обеспечивает обмен изменениями в таблицах ядра между элементами кластера. Дельта-синхронизация осуществляется ядром шлюза безопасности с использованием многоадресной и широковещательной UDP-передачи на порте 8116.

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

Трафик State Synchronization обычно составляет около 90% от всего трафика протокола управления кластером (CCP). Пакеты State Synchronization отличаются от остального CCP-трафика, передаваемого через код операции в заголовке UDP-данных.

Примечание: вы можете изменить MAC-адрес источника для CCP-пакетов (см.

"Синхронизация кластеров в глобальной компьютерной сети" на стр. 15).

Несинхронизируемые сервисы В кластере шлюзов все соединения на всех элементах кластера обычно синхронизируются. Однако не все сервисы, пересекающие кластер шлюзов, обязательно синхронизировать.

Вы можете отказаться от синхронизации TCP, UDP и других типов сервисов. По умолчанию все эти сервисы синхронизируются.

Протоколы VRRP и IP Clustering, а также IGMP-протокол не синхронизируются по умолчанию (но вы можете включить синхронизацию для этих протоколов). Протоколы, которые выполняются только между элементами кластера, не требуют синхронизации. Хотя вы можете их синхронизировать, это не принесет пользы. Эта синхронизирующая информация не поможет аварийному переключению при отказе. Следующие протоколы не синхронизируются по умолчанию: IGMP, VRRP, IP clustering и некоторые другие протоколы управления кластером OPSEC.

Широковещательная и многоадресная передача данных не синхронизируется и не может синхронизироваться.

Вы можете иметь синхронизируемый сервис и одновременно несинхронизируемое определение сервиса и использовать их в базе правил по своему выбору.

Конфигурирование несинхронизируемых сервисов Синхронизация влияет на производительность. Вы можете отказаться от синхронизации сервиса, если верны следующие условия:

Через определенный сервер в кластере проходит большое количество трафика. Если сервис не синхронизируется, это уменьшает количество трафика синхронизации и потому увеличивается производительность кластера.

Сервис обычно открывает короткие соединения, потеря которых может остаться незамеченной. Как правило, большинство соединений приходится на DNS (по UDP-протоколу) и HTTP, которые зачастую характеризуются кратковременностью и возможностью восстановления на уровне приложения. Сервисы, которые обычно открывают долговременные соединения, такие как FTP, всегда должны синхронизироваться.

Конфигурации, обеспечивающие двустороннюю привязку всех соединений, не требуют синхронизации для работы (только для поддержания высокой доступности). К таким конфигурациям относятся:

Любой кластер в режиме высокой доступности (например, ClusterXL New HA или IPSO VRRP).

ClusterXL в режиме распределения нагрузки с прозрачными соединениями (кроме соединений VPN и Static NAT).

Кластеры OPSEC, обеспечивающие полную привязку (см. документацию о кластерах OPSEC).

Соединения VPN и Static NAT, передаваемые через кластер ClusterXL в режиме распределения нагрузки (многоадресном или одноадресном), не поддерживают двустороннюю привязку. Для таких сред должна быть включена синхронизация состояний.



Синхронизация с ограничением продолжительности Некоторые TCP-сервисы (например, HTTP) характеризуются соединениями с очень короткой продолжительностью. Синхронизировать такие соединения не имеет смысла, потому что каждое синхронизированное соединение потребляет ресурсы шлюза, при этом весьма вероятно, что к моменту аварийного переключения соединение будет завершено.

Для всех TCP-сервисов с типом протокола (заданным в графическом пользовательском интерфейсе) HTTP или None (Отсутствует) вы можете использовать эту опцию, чтобы сообщение о соединении приходило на шлюз безопасности с задержкой и благодаря этому его синхронизация осуществлялась бы только в том случае, если оно продолжает существовать через х секунд после инициирования. Эта опция требует наличия устройства SecureXL, поддерживающего "уведомления с задержкой" и текущую конфигурацию кластера (например, Performance Pack c ClusterXL LS Multicast).

Эта возможность доступна, только если на шлюзе безопасности, через который проходит соединение, установлено устройство с активированным SecureXL.

Настройка игнорируется, если с устройства с активированным ClusterXL не выгружены шаблоны соединений. См. дополнительную информацию в документации по SecureXL.

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

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

В конфигурациях Load Sharing (Распределение нагрузки) все элементы кластера активны, и в соединениях Static NAT и зашифрованных соединениях IP-адреса источника и назначения изменяются. Поэтому соединения Static NAT и зашифрованные соединения, осуществляемые через кластер с распределением нагрузки, могут не иметь привязки. Отсутствие привязки также возможно с Hide NAT, но ClusterXL имеет механизм для его привязки.

В конфигурациях High Availability (Высокая доступность) все пакеты достигают активную машину, поэтому все соединения имеют привязку. В случае если при установлении соединения произошло аварийное переключение, соединение теряется, но синхронизация может быть выполнена позднее.

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

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



Пример соединения без привязки: трехэтапное TCP-квитирование Трехэтапное квитирование, инициирующее все TCP-соединения, очень часто приводит к возникновению соединения без привязки (часто называемого асимметричной маршрутизацией). Это может привести к ситуации, показанной на следующей иллюстрации:

Клиент А инициирует соединение, отправив пакет SYN на сервер B. SYN проходит через шлюз С, но ответ SYN/ACK возвращается через шлюз D. Это соединение без привязки, потому что ответный пакет возвращается через другой шлюз, нежели исходный пакет.

Сеть синхронизации направляет уведомление шлюзу D. Если обновление шлюза D произойдет прежде, чем он получит пакет SYN/ACK, отправленный сервером B, то соединение будет обработано, как обычно. Но в случае задержки синхронизации и если пакет SYN/ACK поступит на шлюз D до обновления флага SYN, то шлюз примет пакет SYN/ACK за не соответствующий таблице состояний и сбросит соединение.

Для решения этой проблемы вы можете настроить расширенное применение трехэтапного TCP-квитирования (см. "Расширенное применение трехэтапного TCP-квитирования" на стр. 91).

Синхронизация соединений без привязки Механизм синхронизации предотвращает попадание пакетов, не соответствующих таблице состояний, в допустимые соединения без привязки. Этот процесс лучше всего проиллюстрировать на примере трехэтапного квитирования, инициирующего все соединения TCP-данных. Трехэтапное квитирование осуществляется в следующем порядке:

1. SYN (от клиента серверу)

2. SYN/ACK (от сервера клиенту)

3. ACK (от клиента серверу)

4. Данные (от клиента серверу)

Для предотвращения попадания пакетов, не соответствующих таблице состояний, выполняется следующая последовательность (т.н. "Flush and Ack").

1. Элемент кластера получает первый пакет (SYN) соединения.

2. Подозревает, что у соединения нет привязки.

3. Удерживает пакет SYN.

4. Отправляет обновления синхронизации, ожидающие очереди, всем элементам кластера (включая все изменения, связанные с этим пакетом).

5. Ждет подтверждения информации, содержащейся в пакете синхронизации, от всех других элементов кластера.

6. Отпускает удерживаемый пакет SYN.

7. Все элементы кластера готовы к SYN-ACK.

Синхронизация кластеров в глобальной компьютерной сети Иногда перед организациями возникает необходимость размещать элементы кластера в географически удаленных местах. Типичным примером является центр тиражированных данных, узлы которого расположены далеко друг от друга для целей восстановления в аварийных ситуациях. Очевидно, что в

Сервер B Клиент A

Шлюз D

Шлюз C



такой конфигурации использование кросс-кабеля для сети синхронизации невозможно.

Сеть синхронизации можно разнести по удаленным узлам, тем самым упростив развертывание географически распределенного кластера. Эта возможность имеет два ограничения:

1. Задержка в сети синхронизации не должна превышать 100 мс, а потеря пакетов должна составлять не более 5%.

2. В сеть синхронизации могут входить только коммутаторы и хабы. Наличие маршрутизаторов в сети синхронизации недопустимо, потому что маршрутизаторы сбрасывают пакеты протокола управления кластером.

Вы можете осуществлять мониторинг и диагностику неполадок (см. "Диагностика неполадок синхронизации" на стр. 58) географически распределенных кластеров с помощью интерфейса командной строки.

Ограничения синхронизации кластеров На синхронизацию элементов кластера распространяются следующие ограничения:

Можно синхронизировать только те элементы кластера, которые работают на одной платформе.

Все элементы кластера должны использовать одну версию программного обеспечения Check Point.

Соединение с аутентификацией пользователя, проходящее через элемент кластера, будет потеряно в случае выхода из строя элемента кластера. Другие синхронизированные элементы кластера не смогут возобновить соединение.

При этом соединение с аутентификацией клиента или сеанса потеряно не будет.

Эти ограничения обусловлены тем, что состояние аутентификации пользователя хранится на серверах безопасности, которые являются процессами, поэтому его невозможно синхронизировать на разных машинах подобно тому, как синхронизируются данные ядра. Состояние же аутентификации клиента и сеанса хранится в таблицах ядра, поэтому его синхронизация возможна.

Состояние соединений с использованием ресурсов хранится на сервере безопасности, поэтому синхронизация этих соединений невозможна по той же причине, по которой невозможна синхронизация соединений с аутентификацией пользователя.

Учетная информация накапливается на каждом элементе кластера и по отдельности направляется на сервер управления безопасности, где информация объединяется. В случае аварийного переключения учетная информация, накопленная на отказавшем элементе, но еще не отправленная на сервер управления безопасности, будет потеряна. Чтобы свести эту проблему к минимуму, можно уменьшить период, в который происходит "сброс" учетной информации. Для этого на странице Logs and Masters > Additional Logging (Журналы и образцы > Дополнительная регистрация) объекта-кластера настройте признак Update Account Log every (Обновлять журнал регистрации учетных данных каждые):

Конфигурирование State Synchronization Настройте синхронизацию состояний одновременно с настройкой ClusterXL и продуктов кластеризации, имеющих сертификат OPSEC. Конфигурирование синхронизации состояний осуществляется в следующем порядке:

1. Настройка сети синхронизации на кластер шлюзов

2. Установка шлюза безопасности и активация синхронизации во время процесса конфигурирования

3. Активация State Synchronization на странице ClusterXL для объекта-кластера

Процедуры конфигурирования рассматриваются в разделах о конфигурировании ClusterXL (см. "Конфигурирование ClusterXL" на стр. 37) и кластеров, имеющих сертификат OPSEC, (см. "Конфигурирование продуктов кластеризации, имеющих сертификат OPSEC" на стр. 42).

Конфигурирование несинхронизируемого сервиса Для настройки несинхронизируемого сервиса:

1. В ветви Services (Сервисы) дерева объектов дважды щелкните по TCP, UDP или Other (Другой), чтобы выбрать тип сервиса, который не хотите синхронизировать.

2. В окне Service Properties (Свойства сервиса) щелкните Advanced (Дополнительно), чтобы открыть окно Advanced Services Properties (Дополнительные свойства сервиса).

3. Снимите галочку рядом с опцией Synchronize connections on the cluster (Синхронизировать соединения в кластере).



Создание синхронизируемых и несинхронизируемых версий Сервис может быть одновременно определен как синхронизируемый и несинхронизируемый, и вы можете использовать их в базе правил безопасности по своему выбору.

1. Определите новый тип сервиса TCP, UDP или Other (Другой). Дайте ему имя, отличающее его от существующего сервиса.

2. Скопируйте все определения из существующего сервиса в окно Service Properties нового сервиса.

3. В новом сервисе щелкните Advanced, чтобы открыть окно Advanced Services Properties.

4. Скопируйте все определения из существующего сервиса в окно Advanced Service Properties нового сервиса.

5. Установите Synchronize connections on the cluster в новом сервисе, чтобы он отличался от настройки в существующем сервисе.

Конфигурирование синхронизации с ограничением продолжительности Перед началом этой процедуры ознакомьтесь с понятием синхронизации с ограничением продолжительности (см. "Синхронизация с ограничением продолжительности" на стр. 14).

Примечание: эта опция ограничена HTTP-сервисами. Для других сервисов опция Start synchronizing (Начать синхронизацию) не отображается.

Для конфигурирования синхронизации с ограничением продолжительности:

1. В ветви Services дерева объектов дважды щелкните по TCP, UDP или Other, чтобы выбрать тип сервиса, который хотите синхронизировать.

2. В окне Service Properties щелкните Advanced, чтобы открыть окно Advanced Services Properties.

3. Выберите Start synchronizing x seconds after connection initiation (Начать синхронизацию через х секунд после инициирования соединения).

4. В поле seconds (секунды) введите количество секунд, отражающее задержку синхронизации после инициирования соединения, или выберите количество секунд из списка.


Глава 3

Соединения с привязкой В этой главе

О соединениях с привязкой 18

Опция Sticky Decision Function 18

VPN-туннели со сторонними равноправными узлами и распределением нагрузки 18

Сторонние шлюзы в развернутых системах Hub and Spoke 19

Конфигурирование опции Sticky Decision Function 20

Создание стороннего шлюза в развернутой системе Hub and Spoke 21

О соединениях с привязкой Соединение имеет привязку, когда обработка всех пакетов в любом направлении осуществляется одним элементом кластера. Это имеет место в режиме High Availability (Высокая доступность), в котором все соединения маршрутизируются через один и тот же элемент кластера, т.е. имеют привязку. Это также имеет место в режиме Load Sharing (Распределение нагрузки) при отсутствии равноправных узлов VPN, правил статической NAT-трансляции или SIP.

Однако в режиме Load Sharing бывают ситуации, когда необходимо, чтобы соединение, инициированное на определенном элементе кластера, было в обязательном порядке обработано тем же элементом кластера в обоих направлениях. Для этой цели можно привязать некоторые соединения, активировав опцию Sticky Decision Function.

Примечание: последняя информация об элементах, требующих привязки

соединений, приведена в "Примечаниях к изданию R75.40VS" (http://supportcontent.checkpoint.com/solutions?id=sk76540).

Опция Sticky Decision Function Sticky Decision Function (Функция принятия решений о привязке) позволяет использовать определенные сервисы в развернутой системе с распределением нагрузки. Например, это требуется для трафика L2TP или когда кластер участвует в VPN-туннеле типа сеть-сеть со сторонним равноправным узлом.

Теперь благодаря Sticky Decision Function поддерживаются следующие типы сервисов и соединений:

Развернутые VPN-сети со сторонними равноправными VPN-узлами

Зашифрованные соединения SecureClient/SecuRemote/SSL Network Extender, в том числе в режиме посетителя SecureClient

Sticky Decision Function имеет следующие ограничения:

Sticky Decision Function не поддерживается при использовании пакета Performance Pack или аппаратного ускорителя. Активация Sticky Decision Function отключает эти продукты ускорения.

При использовании Sticky Decision Function совместно с VPN-элементам кластера запрещено открывать более одного соединения для определенного равноправного узла. Открытие еще одного соединения привело бы к генерированию другого адреса назначения, который сторонний узел во многих случаях не смог бы обработать.

VPN-туннели со сторонними равноправными узлами и распределением нагрузки

Check Point обеспечивает возможность взаимодействия со шлюзами сторонних поставщиков, активируя их взаимодействие со шлюзами Check Point в качестве равноправных узлов. Особая ситуация возникает, когда некоторые сторонние равноправные узлы (шлюзы и клиенты Microsoft LT2P, IPSO Symbian и Cisco) пытаются установить VPN-туннели со шлюзами ClusterXL в режиме Load Sharing (Распределение нагрузки). Эти узлы ограничены в своей способности сохранять адреса назначения, а это означает, что


Соединения с привязкой


VPN-сеанс, который начинается на одном элементе кластера, а на обратном пути маршрутизируется через другой элемент в результате распределения нагрузки, не распознается и сбрасывается.

Это показано на следующей иллюстрации.

В данном сценарии:

Сторонний равноправный узел (шлюз или клиент) пытается создать VPN-туннель.

Элементы кластера A и B относятся к шлюзу ClusterXL в режиме распределения нагрузки.

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

Эта проблема решается для некоторых сторонних узлов или любых шлюзов, которые могут сохранять только один набор адресов назначения, путем привязки соединения. Активация Sticky Decision Function приводит к тому, что все VPN-сеансы, инициируемые одним и тем же сторонним шлюзом, обрабатываются одним элементом кластера.

Для активации Sticky Decision Function:

1. На панели инструментов SmartDashboard отредактируйте объект-кластер на странице ClusterXL > Advanced (ClusterXL > Дополнительно).

2. Активируйте свойство Use Sticky Decision Function (Использовать Sticky Decision Function).

Сторонние шлюзы в развернутых системах Hub and Spoke

Еще одна ситуация, когда в режиме Load Sharing требуется Sticky Decision Function, возникает при объединении некоторых сторонних шлюзов в развернутую систему с топологией hub and spoke. Не имея способности хранить несколько наборов адресов назначения, сторонний шлюз должен поддерживать свои VPN-туннели на одном элементе кластера во избежание дублирования адресов назначения.


ЛВС ЛВС


Элемент кластера B

Элемент кластера А

Сторонний шлюз

Сторонний клиент

или или

Сторонний шлюз




Интернет Интернет



Пример такой развернутой системы приведен на следующей схеме:


Смысл такой развернутой системы состоит в том, чтобы позволить хостам, расположенными за споком А, взаимодействовать с хостами, расположенными за споком B.

Шлюз ClusterXL находится в режиме Load Sharing, состоит из элементов кластера A и B и выполняет функцию VPN-хаба.

Спок А — это сторонний шлюз, который соединен VPN-туннелем, проходящим к споку В через хаб.

Спок B может быть либо другим сторонним шлюзом, либо шлюзом безопасности Check Point.

Споки А и В необходимо настроить так, чтобы их взаимодействие всегда осуществлялось с использованием одного и того же элемента кластера. Активация Sticky Decision Function решает половину проблемы: тем, что все VPN-сеансы, инициированные любым из сторонних шлюзов, обрабатываются одним элементом кластера.

Для того чтобы взаимодействие между споками A и B всегда осуществлялось одним элементом кластера, необходимо внести некоторые изменения в файл user.def. Этот шаг обеспечивает соединение обоих сторонних шлюзов с одним и тем же элементом кластера (см. "Создание стороннего шлюза в развернутой системе Hub and Spoke" на стр. 21).

Конфигурирование опции Sticky Decision Function Для конфигурирования Sticky Decision Function:

1. Выберите объект-кластер из дерева Network Object (Сетевой объект).

2. Выберите ClusterXL из дерева и щелкните Advanced.

3. В окне Advanced Load Sharing (Дополнительное распределение нагрузки) выберите одну из следующих опций:

Опция IPs, Ports, SPIs (по умолчанию) обеспечивает наилучшее распределение и рекомендуется для использования. Это конфигурация распределения с наименьшей привязкой.

IPs, Ports следует использовать только в случае возникновения проблем при рассылке пакетов

IPSec на несколько машин, хотя у них одинаковые IP-адреса источника и назначения.

IPs следует использовать только в случае возникновения проблем при рассылке пакетов IPSec или разных пакетов на несколько машин, хотя у них одинаковые IP-адреса источника и назначения. Это конфигурация распределения с наибольшей привязкой.

4. Активируйте опцию Sticky Decision Function или снимите галочку для ее деактивации. По умолчанию опция Sticky Decision Function выключена.

Если опция активирована, как входящее, так и исходящее соединение будет проходить через один элемент кластера.




Интернет

Шлюз ClusterXL в роли VPN-хаба

Спок A Спок В



Создание стороннего шлюза в развернутой системе Hub and Spoke

Для создания стороннего шлюза в развернутой системе hub and spoke в качестве спока выполните следующие действия на сервере управления безопасностью:

1. Активируйте опцию Sticky Decision Function, если она еще не активирована. На панели инструментов SmartDashboard отредактируйте объект-кластер на странице > ClusterXL > Advanced (ClusterXL > Дополнительно) и активируйте свойство Use Sticky Decision Function (Использовать Sticky Decision Function).

2. Создайте группу туннелей для обработки трафика от определенных равноправных узлов. Отредактируйте файл $FWDIR/lib/user.def с помощью текстового редактора и добавьте строку, подобную следующей:

Эта конфигурация состоит из следующих элементов:

Элемент Описание

all Означает все интерфейсы шлюза кластера

member1,member 2 Имена элементов кластера на панели инструментов SmartDashboard

vpn_sticky_gws Имя таблицы

10.10.10.1 IP-адрес спока A

20.20.20.1 IP-адрес спока B

;1 Идентификатор группы туннелей, который означает, что трафик с IP-адресов должен обрабатываться одним и тем же элементом кластера

3. Вы можете добавить в группу туннелей другие равноправные узлы, включив их IP-адреса в вышеуказанном формате. Так, в вышеприведенном примере добавление спока С имело бы следующий вид:

Обратите внимание, что идентификатор группы туннелей ;1 не изменился, что означает, что указанные равноправные узлы всегда будут соединяться через один и тот же элемент кластера.

Примечание: количество заданных групп туннелей может превышать количество

элементов кластеров.

Эта процедура по определению выключает Load Sharing для соответствующих соединений. Если реализация подразумевает соединение друг с другом нескольких наборов сторонних шлюзов, некоторое распределение нагрузки возможно путем настройки пар шлюзов на совместную работу с определенными элементами кластера. Например, чтобы настроить соединение между двумя другими споками (C и D), просто добавьте их IP-адреса в строку и замените идентификатор группы туннелей ;1 на ;2. При этом строка будет иметь следующий вид:

Обратите внимание, что теперь идентификаторов равноправных узлов стало два: ;1 и ;2. Теперь споки А и B будут соединяться через один элемент кластера, а споки С и D — через другой.

Примечание: совместное использование групп туннелей осуществляется активными элементами кластера. В случае изменения состояния кластера (например, аварийного переключения или присоединения/отсоединения элемента) произойдет переназначение с учетом нового состояния.


Глава 4

Высокая доступность и распределение нагрузки в ClusterXL


О режимах High Availability и Load Sharing 22

Пример топологии ClusterXL 22

Режимы ClusterXL 24

Аварийное переключение 28

Факторы, учитываемые при планировании реализации 29

Требования к аппаратному обеспечению, совместимость и пример Cisco 30

Программная совместимость Check Point 33

Конфигурирование топологии кластера 35

О режимах High Availability и Load Sharing ClusterXL — это программное решение распределения нагрузки и высокой доступности, предназначенное для распределения сетевого трафика между кластерами резервных шлюзов безопасности.

ClusterXL обеспечивает:

Прозрачное аварийное переключение в случае отказа машин

Нулевой простой в средах, предназначенных для решения ответственных задач (при использовании State Synchronization)

Увеличение скорости (в режимах Load Sharing)

Прозрачность обновлений

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

Связующим элементом, объединяющим машины в кластере ClusterXL, является протокол управления кластером (CCP), который используется для передачи синхронизирующей и другой информации между элементами кластера.

Режим Load Sharing ClusterXL Load Sharing распределяет трафик в кластере шлюзов, что приводит к увеличению общей скорости нескольких машин.

В конфигурациях Load Sharing все работающие машины кластера являются активными и обрабатывают сетевой трафик (операция Active/Active).

Если какой-либо из шлюзов Check Point в кластере становится недоступным, происходит прозрачное аварийное переключение на остальные рабочие машины кластера, что обеспечивает высокую доступность. Все соединения совместно используются остальными шлюзами без прерывания.

Пример топологии ClusterXL В ClusterXL для каждого элемента кластера используются уникальные физические IP- и MAC-адреса, а для самого кластера используются виртуальные IP-адреса. Адреса интерфейсов кластера не относятся к реальному машинному интерфейсу.



На следующей схеме представлен кластер ClusterXL, состоящих из двух элементов, с указанием виртуальных IP-адресов кластера и физических IP-адресов его элементов. Такая развернутая система используется во многих примерах, приведенных в этой главе.

У каждого элемента кластера есть три интерфейса: один внешний, один внутренний и один для синхронизации. Интерфейсы элементов кластера, направленные во все стороны, соединяются через коммутатор, маршрутизатор или VLAN-коммутатор.

Все интерфейсы элементов кластера, направленные в одну сторону, должны находиться в одной сети. Например, между элементами кластера не должно быть маршрутизатора.

Сервер управления безопасностью может быть расположен в любом месте с возможностью маршрутизации либо на внутренние, либо на внешние адреса кластера.

В следующих разделах представлены понятия конфигурации ClusterXL, показанные в данном примере.

Примечание

1. В режиме High Availability Legacy применяется другая топология (см. "Режим High Availability Legacy" на стр. 99). 2. В примерах, приведенных в этом и последующих разделах, адреса в диапазоне от

192.168.0.0 до 192.168.255.255, которые относятся к частным адресам RFC 1918,

представляют маршрутизируемые (публичные) IP-адреса.

Определение IP-адресов элементов кластера Рекомендации по настройке каждой машины — элемента кластера сводятся к следующему:

Все машины в составе кластера должны иметь не менее трех интерфейсов:

Интерфейс, направленный в сторону внешнего интерфейса кластера, который в свою очередь направлен в сторону Интернета.

Интерфейс, направленный в сторону внутреннего интерфейса кластера, который в свою очередь направлен в сторону внутренней сети.

Интерфейс, предназначенный для синхронизации.

Все интерфейсы, обращенные в определенную сторону, должны находиться в одной сети.

Например, на предыдущей иллюстрации имеется два элемента кластера: элемент А и элемент В. У каждого есть интерфейс с IP-адресом, выходящим в Интернет через хаб или коммутатор. Это внешний интерфейс с IP-адресом 192.168.10.1 на элементе A и 192.168.10.2 на элементе B, и именно его видит внешний интерфейс кластера.

ЛВС





Интернет

Элемент B

Внутренний интерфейс

Внешний интерфейс

Интерфейс синхронизации




Внутренний интерфейс кластера


Элемент A

Внешний интерфейс кластера

(маршрутизируемый адрес)



Примечание: в этом издании представлена опция с использованием всего двух

интерфейсов для каждого элемента: одного внешнего и одного внутреннего, — и с выполнением синхронизации через внутренний интерфейс. Эта конфигурация не относится к рекомендуемым, и ее следует использовать только в качестве резерва (см. "Синхронизация информации о соединениях в кластере" на стр. 12).

Определение виртуальных IP-адресов элементов кластера На предыдущей иллюстрации IP-адресом кластера является 192.168.10.100.

У кластера есть один внешний виртуальный IP-адрес и один внутренний виртуальный IP-адрес. Внешним IP-адресом является 192.168.10.100, а внутренним IP-адресом является 10.10.0.100.

Сеть синхронизации Синхронизация состояний между элементами кластера обеспечивает сохранение соединений, которые обрабатывались отказавшей машиной, в случае аварийного переключения. Сеть синхронизации используется для обмена синхронизацией соединений и другой информацией о состояниях между элементами кластера. Таким образом, эта сеть переносит всю самую ценную информацию о политике безопасности организации, и поэтому важно обеспечить безопасность сети. Вы можете определить несколько сетей синхронизации для целей резервирования.

Для защиты интерфейсов синхронизации их следует подключить напрямую кросс-кабелем, а в кластере с тремя и более элементами использовать выделенный хаб или коммутатор.

Машины в кластере Load Sharing должны быть синхронизированы, потому что синхронизация используется в нормальном потоке трафика. Машины в кластере High Availability, необязательно синхронизировать, но, если они не синхронизированы, то при отказе соединения могут быть потеряны.

На предыдущей иллюстрации представлен интерфейс синхронизации с уникальным IP-адресом на каждой машине: 10.0.10.1 на элементе A и 10.0.10.2 на элементе B.

Настройка адресов кластера в разных подсетях Для кластера ClusterXL требуется всего один маршрутизируемый IP-адрес — для виртуального интерфейса кластера, направленного в сторону Интернета. Все физические IP-адреса элементов кластера могут быть немаршрутизируемыми.

Настройка разных подсетей на IP-адреса кластера и адреса элементов полезна, поскольку она:

Позволяет многомашинному кластеру заменить одномашинный шлюз в предварительно сконфигурированной сети без необходимости в присвоении новых адресов к элементам кластера.

Позволяет организациям использовать только один маршрутизируемый адрес для кластера шлюзов ClusterXL. Благодаря этому вы экономите маршрутизируемые адреса.

Режимы ClusterXL ClusterXL имеет четыре рабочих режима. В этом разделе приведено краткое описание каждого режима и его относительных преимуществ и недостатков.

Режим Load Sharing Multicast (Многоадресное распределение нагрузки)

Режим Load Sharing Unicast (Одноадресное распределение нагрузки)

Режим New High Availability (Высокая доступность в новом режиме)

Режим High Availability Legacy (Высокая доступность в режиме совместимости)

Подробное описание функционала High Availability Legacy приведено в приложении (см. "Режим High Availability Legacy" на стр. 99). Во избежание проблем с обратной совместимостью рекомендуется использовать режим High Availability New.

Примечание: во многих примерах, приведенных в этом разделе, используется

развернутая система из примера топологии ClusterXL ("Пример топологии ClusterXL" на стр. 22).



Режим Load Sharing Multicast Load Sharing позволяет распределять сетевой трафик между элементами кластера. В отличие от решения High Availability, в котором в любой момент времени активен только один элемент, в решении Load Sharing активны все элементы кластера и кластер отвечает за назначение части трафика каждому элементу. Такое назначение является задачей функции принятия решений, которая проверяет каждый пакет, проходящий через кластер, и определяет, какому элементу поручить обработку этого пакета. Таким образом, кластер Load Sharing использует все элементы кластера, что обычно приводит к увеличению общей скорости.

Важно понимать, что в сочетании со State Synchronization ClusterXL Load Sharing также обеспечивает полноценное решение High Availability. Когда все элементы кластера активны, трафик равномерно распределяется между машинами. В случае аварийного переключения, вызванного отказом одного из элементов, обработка всех соединений, которая осуществлялась отказавшей машиной, немедленно передается другим элементам.

В ClusterXL предусмотрено два режима Load Sharing: Multicast (Многоадресное) и Unicast (Одноадресное). Эти два режима отличаются способом получения элементами пакетов, отправленных на кластер. В этом разделе рассматривается режим Multicast.

Многоадресный механизм, обеспечиваемый уровнем сети Ethernet, позволяет связать несколько интерфейсов с одним физическим (MAC-) адресом. В отличие от широковещательного режима, который связывает все интерфейсы одной подсети с одним адресом, Multicast допускает группировку в пределах сетей. Это означает, что вы можете выбрать интерфейсы одной подсети, которые будут получать пакеты, отправленные на указанный MAC-адрес.

ClusterXL использует многоадресный механизм, чтобы связать виртуальные IP-адреса кластера со всеми элементами кластера. Связывая эти IP-адреса с групповым MAC-адресом, он обеспечивает доставку всех пакетов, отправленных на кластер, выступающий в роли шлюза, на все элементы кластера. Затем каждый элемент принимает решение об обработке пакетов. Это решение является ключевым в механизме Load Sharing: он должен обеспечивать обработку каждого пакета как минимум одним элементом (во избежание блокировки трафика) и не допускать обработку одних и тех же пакетов двумя элементами (во избежание дублирования трафика).

Дополнительным требованием функции принятия решений является маршрутизация каждого соединения через один шлюз, что обеспечивает обработку пакетов, относящихся к одному соединению, одним и тем же элементом. К сожалению, это требование не всегда выполнимо и в некоторых случаях пакеты одного и того же соединения будут обрабатываться разными элементами. ClusterXL решает эту проблему с помощью своего механизма синхронизации состояний, который зеркально отражает соединения на все элементы кластера.

Пример В данном сценарии пользователь осуществляет вход в Интернет с веб-сервера, расположенного за кластером Firewall, настроенным в режиме Load Sharing Multicast.

1. Пользователь запрашивает соединение с 192.168.10.78 (его компьютер) на 10.10.0.34 (веб-сервер).

2. Маршрутизатор сети 192.168.10.x распознает 192.168.10.100 (виртуальный IP-адрес кластера) как шлюз в сеть 10.10.0.x.

3. Маршрутизатор посылает ARP-запрос на 192.168.10.100.

4. Один из активных элементов перехватывает ARP-запрос и в ответ отправляет групповой MAC-адрес, присвоенный IP-адресу кластера 192.168.10.100.

5. Когда веб-сервер отвечает на запросы пользователя, он распознает 10.10.0.100 как свой шлюз в Интернет.

6. Веб-сервер посылает ARP-запрос на 10.10.0.100.

7. Один из активных элементов перехватывает ARP-запрос и в ответ отправляет групповой MAC-адрес, присвоенный IP-адресу кластера 10.10.0.100.

8. Все пакеты между пользователем и веб-сервером достигают каждый элемент кластера, и каждый элемент принимает решение об обработке или сбрасывании каждого пакета.

9. При аварийном переключении один из элементов кластера выходит из строя. Однако трафик все равно достигает все активные элементы кластера, поэтому нет необходимости вносить изменения в ARP-маршрутизацию сети. Изменяется только функция принятия решений кластера, которая учитывает новое состояние элементов.

Режим Load Sharing Unicast Режим Load Sharing Unicast (Одноадресное распределение нагрузки) обеспечивает адаптацию решения Load Sharing к средам, в которых невозможно использовать Mulsticast Ethernet. В этом режиме с виртуальными IP-адресами кластера связан один элемент кластера, назначенный главным, поэтому он является единственным элементом, получающим пакеты, отправляемые на кластер. При этом главный



элемент отвечает за рассылку пакетов другим элементам кластера, тем самым создавая механизм Load Sharing. Распределение осуществляется путем применения функции принятия решений к каждому пакету так, как это происходит в режиме Load Sharing Multicast. Отличие состоит в том, что решение принимается только одним элементом: любой элемент, кроме главного, получивший переадресованный пакет, выполнит его обработку, не применяя функцию принятия решений. Обратите внимание, что неглавные элементы все равно считаются "активными", так как они выполняют маршрутизацию и задачи Firewall в своей части трафика (хотя и не принимают решений).

Несмотря на то, что главный элемент отвечает за процесс принятия решений, он продолжает выступать в роли шлюза безопасности, занимающегося обработкой пакетов (например, он может принять решение об обработке пакета на локальной машине). Однако поскольку дополнительные задачи могут отнимать у него время, как правило, ему назначается меньшая доля от общей нагрузки.

Когда происходит аварийное переключение при отказе неглавного элемента, обрабатываемые им соединения перераспределяются между активными элементами кластера, что обеспечивает такую же высокую доступность, как в режимах New High Availability и Load Sharing Multicast. Когда проблема возникает на главном элементе, происходит обычное аварийное переключение, а кроме того, другой элемент берет на себя роль нового главного элемента. Главный элемент всегда является активным элементом с наивысшим приоритетом. Это означает, что когда бывший главный элемент восстановится, он вернет себе свою прежнюю роль.

Пример В данном сценарии мы используем кластер Load Sharing Unicast в качестве шлюза между компьютером пользователя и веб-сервером.


2. Маршрутизатор сети 192.168.10.x распознает 192.168.10.100 (виртуальный IP-адрес кластера) как шлюз в сеть 10.10.0.x.


4. Главный элемент перехватывает ARP-запрос и в ответ отправляет MAC-адрес, соответствующий его собственному уникальному IP-адресу 192.168.10.1.



7. Главный элемент перехватывает ARP-запрос и в ответ отправляет MAC-адрес, соответствующий его собственному уникальному IP-адресу 10.10.0.1.

8. Пакет с запросом пользователя достигает главный элемент на интерфейсе 192.168.10.1.

9. Главный элемент принимает решение о том, что этот пакет будет обрабатывать второй элемент, и переадресует его на 192.168.10.2.

10. Второй элемент распознает пакет как переадресованный и выполняет его обработку.

11. Дальнейшие пакеты либо обрабатываются главным элементом, либо переадресуются и обрабатываются неглавным элементом.

12. Когда на главном элементе происходит аварийное переключение, второй элемент берет на себя роль главного.

13. Новый главный элемент отправляет самообращенные ARP-запросы как в сети 192.168.10.x, так и в сети 10.10.0.x. Эти запросы связывают виртуальный IP-адрес 192.168.10.100 с MAC-адресом, соответствующим уникальным IP-адресом 192.168.10.2, а виртуальный IP-адрес 10.10.0.100 — с MAC-адресом, соответствующим уникальному IP-адресу 10.10.0.2.

14. Теперь трафик, отправляемый на кластер, принимается новым главным элементом и обрабатывается локальной машиной (так как в данный момент времени она является единственной активной машиной в кластере).

15. После восстановления первой машины она возвращает себе роль главного элемента, связав IP-адреса кластера со своими собственными уникальными MAC-адресами.

Режим High Availability Режим High Availability обеспечивает основные возможности High Availability в среде кластера. Это означает, что кластер способен обеспечивать сервисы Firewall даже при возникновении проблемы, которая на отдельном шлюзе привела бы к полной потере соединений. В сочетании с решением State Synchronization от Check Point режим ClusterXL High Availability может сохранять соединения при аварийных переключениях с полной прозрачностью для пользователя, тем самым обеспечивая безупречную связь. Таким образом, High-Availability представляет резервный механизм, который позволяет организациям уменьшить риск непредвиденных простоев, особенно в средах, предназначенных для решения ответственных задач (например, для проведения финансовых транзакций по Интернету).



Для достижения этой цели режим New High Availability назначает один из элементов кластера активной машиной, в то время как остальные элементы остаются в режиме готовности. Виртуальные IP-адреса кластера связываются с физическими сетевыми интерфейсами активной машины (путем согласования виртуального IP-адреса с уникальным MAC-адресом соответствующего интерфейса). Таким образом, весь трафик, направляемый на кластер, фактически маршрутизируется (и фильтруется) активным элементом. Роль каждого элемента кластера определяется в зависимости от его приоритета, при этом наивысший приоритет имеет активный элемент. Приоритеты элементов соответствуют порядку их появления на странице Cluster Members (Элементы кластера) окна Gateway Cluster Properties (Свойства кластера шлюзов). Верхний элемент имеет наивысший приоритет. Вы можете изменить эту очередность в любое время.

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

Каждый раз при обнаружении проблемы в активном элементе, которая является достаточно серьезной, для того чтобы привести к аварийному переключению, кластер передает роль активного элемента одной из резервных машин (элементу, имеющему наивысший приоритет в данный момент времени). Если применяется State Synchronization, любые открытые соединения распознаются новой активной машиной и обрабатываются с учетом их последнего известного состояния. После восстановления элемента с более высоким приоритетом роль активной машины может быть возвращена, а может быть не возвращена этому элементу в зависимости от пользовательской конфигурации.

Обратите внимание, что проблемы могут возникнуть и на резервных машинах кластера. При этом в случае аварийного переключения такие машины не рассматриваются как кандидаты на роль активных элементов.

Пример В данном сценарии пользователь осуществляет вход в Интернет с веб-сервера, расположенного за кластером Firewall.


2. Маршрутизатор сети 192.168.10.x распознает 192.168.10.100 (виртуальный IP-адрес кластера) как

шлюз в сеть 10.10.0.x.


4. Активный элемент перехватывает ARP-запрос и в ответ отправляет MAC-адрес, соответствующий его собственному уникальному IP-адресу 192.168.10.1.



7. Активный элемент перехватывает ARP-запрос и в ответ отправляет MAC-адрес, соответствующий его собственному уникальному IP-адресу 10.10.0.1.

8. Теперь весь трафик между пользователем и веб-сервером направляется через активный элемент.

9. Когда происходит аварийное переключение, резервный элемент заключает, что теперь он должен заменить отказавший активный элемент.

10. Резервный элемент отправляет самообращенные ARP-запросы как в сети 192.168.10.x, так и в сети 10.10.0.x. Эти запросы связывают виртуальный IP-адрес 192.168.10.100 с MAC-адресом, соответствующим уникальным IP-адресом 192.168.10.2, а виртуальный IP-адрес 10.10.0.100 — с MAC-адресом, соответствующим уникальному IP-адресу 10.10.0.2.

11. Теперь резервный элемент переключился на роль активного элемента, и весь трафик, направляемый через кластер, маршрутизируется через эту машину.

12. Бывший активный элемент считается вышедшим из строя и находится в ожидании восстановления после проблемы, вызвавшей аварийное переключение.

Таблица сравнения режимов В этой таблице обобщены все сходства и различия режимов ClusterXL.

Таблица сравнения режимов ClusterXL

Высокая доступность в режиме совместимости

Высокая доступность в новом режиме

Многоадресное распределение нагрузки

Одноадресное распределение нагрузки

Высокая доступность

Да Да Да Да

Распределение нагрузки

Нет Нет Да Да



Высокая доступность в режиме совместимости

Высокая доступность в новом режиме

Многоадресное распределение нагрузки

Одноадресное распределение нагрузки

Производитель-ность

Высокая Высокая Превосходная Очень высокая

Аппаратная поддержка

Все Все Поддерживаются не все маршрутизаторы

Все

Поддержка SecureXL

Да Да

Да, при наличии Performance Pack или SecureXL Turbocard

Да

Обязательная синхронизация состояний

Нет Нет Да Да

Поддержка VLAN-тегирования

Да Да Да Да

Примечание: подробная информация о поддержке VLAN-тегирования приведена в "Примечаниях к изданию R75.40VS" (http://supportcontent.checkpoint.com/solutions?id=sk76540).

Аварийное переключение Аварийное переключение происходит тогда, когда шлюз больше не может выполнять порученные ему функции. Когда это происходит, обязанности отказавшего шлюза берет на себя другой шлюз кластера.

В конфигурации Load Sharing, если один шлюз безопасности в кластере шлюзов выходит из строя, его соединения распределяются между остальными шлюзами. Все шлюзы в конфигурации Load Sharing синхронизированы, поэтому соединения не прерываются.

В конфигурации High Availability, если один шлюз в синхронизированном кластере выходит из строя, другой шлюз становится активным и "берет на себя" соединения отказавшего шлюза. Если вы не используете State Synchronization, при аварийном переключении существующие соединения закрываются, хотя вы можете открыть новые соединения.

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

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

Обратите внимание, что один элемент кластера может столкнуться с проблемой, приводящей к аварийному переключению. В случаях, когда с такими проблемами сталкиваются все элементы кластера, ClusterXL попытается выбрать один элемент для продолжения работы. Выбранному элементу присваивается состояние Active Attention (Внимание). Такая ситуация сохраняется до полного восстановления другого элемента. Например, в случае неисправной работы кросс-кабеля, соединяющего элементы кластера, оба элемента обнаружат неисправность интерфейса. Состояние одного из них изменится на Down (Не работает), состояние другого — на Active Attention.

Когда происходит аварийное переключение? Аварийное переключение происходит, когда на активном элементе кластера возникает одна из следующих ситуаций:

Отказ любого критического устройства (такого как fwd). Критическое устройство представляет собой

процесс, выполняемый на элементе кластера, который позволяет элементу уведомлять другие элементы кластера о своей неспособности играть роль элемента. Устройство должно сообщать




механизму ClusterXL о своем текущем состоянии, в противном же случае ClusterXL решает, что произошло аварийное переключение, и обязанности передаются другому элементу кластера.

Отказ интерфейса или кабеля.

Выход машины из строя.

Деинсталляция политики безопасности. При деинсталляции политики безопасности шлюз не может больше играть роль брандмауэра. Если он не может играть роль брандмауэра, то он не может быть элементом кластера и происходит аварийное переключение. Обычно деинсталляция политики не происходит сама по себе, а инициируется пользователем. Для ознакомления с подробностями об аварийных переключениях см. sk62570 (http://supportcontent.checkpoint.com/solutions?id=sk62570).

Что происходит при восстановлении шлюза? В конфигурации Load Sharing при восстановлении отказавшего шлюза кластера все соединения перераспределяются между всеми активными элементами.

В конфигурации High Availability при восстановлении отказавшего шлюза кластера метод восстановления зависит от установленной настройки кластера. Опции включают:

Maintain Current Active Gateway (Оставить текущий активный шлюз) означает, что если одна машина

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

Switch to Higher Priority Gateway (Переключиться на шлюз с более высоким приоритетом) означает, что если контроль осуществляется машиной с меньшим приоритетом, то в случае восстановления машины с более высоким приоритетом контроль будет возвращен машине с более высоким приоритетом. Этот режим рекомендуется, если один элемент лучше подходит для обработки соединений, в случае чего он будет шлюзом по умолчанию.

Как восстановленный элемент кластера получает политику безопасности Администратор устанавливает политику безопасности не на отдельных элементах кластера, а на самом кластере. Политика автоматически устанавливается на всех элементах кластера. Политика отправляется на IP-адрес, определенный на странице General Properties (Общие свойства) объекта — элемента кластера.

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

Факторы, учитываемые при планировании реализации

High Availability или Load Sharing Выбор конфигурации Load Sharing (Active/Active) или High Availability (Active/Standby) зависит от потребности и требований организации. Кластер шлюзов High Availability обеспечивает возможность отказоустойчивого подключения для организации. Load Sharing дает дополнительное преимущество в виде повышения производительности.

Примечание: при работе в сети синхронизации рекомендуется использовать

сетевую плату с такой же пропускной способностью, как у сетевых плат, используемых для общего трафика.

Выбор режима Load Sharing Режим Load Sharing Multicast (Многоадресное распределение нагрузки) — это эффективный способ работы с высокой нагрузкой, поскольку обеспечивает оптимальное распределение нагрузки между элементами кластера. Однако в режиме Load Sharing Multicast можно использовать не все маршрутизаторы. Режим Load Sharing Multicast связывает групповой MAC-адрес с каждым индивидуальным IP-адресом кластера.




Благодаря этому трафик, предназначенный для кластера, получают все его элементы. Поэтому ARP-ответы, отправляемые элементом кластера, будет означать, что IP-адрес кластера можно достичь через групповой MAC-адрес.

Некоторые устройства маршрутизации не будут принимать такие ARP-запросы. Для некоторых маршрутизаторов эту проблему можно решить, добавив статическую ARP-запись для IP-адреса кластера на устройстве маршрутизации. Другие маршрутизаторы не примут такой тип статической ARP-записи.

Кроме того, следует учесть, включает ли ваша развернутая система устройства маршрутизации с интерфейсами, работающими в режиме перехвата всех пакетов. Если на одном сегменте сети существует два таких маршрутизатора и шлюз ClusterXL в режиме Load Sharing Multicast, то трафик, предназначенный для кластера, генерируемый одним из маршрутизаторов, может быть обработан другим маршрутизатором.

Для таких случаев используйте режим Load Sharing Unicast (Одноадресное распределение нагрузки), который не требует использования групповых адресов кластера.

Миграция IP-адресов Если вы хотите применить High Availability или Load Sharing к существующей конфигурации с одним шлюзом, рекомендуется взять существующие IP-адреса с текущего шлюза и сделать их адресами кластера (виртуальными адресами кластера), когда это возможно. Это позволит избежать изменения текущих идентификационных данных конечных точек IPSec, а во многих случаях и сохранить конфигурации Hide NAT (Скрытая NAT-трансляция).

Требования к аппаратному обеспечению, совместимость и пример Cisco

Требования к аппаратному обеспечению ClusterXL Кластер шлюзов обычно находится в одной среде с другими сетевыми устройствами, такими как коммутаторы и маршрутизаторы. Эти устройства и шлюзы должны взаимодействовать друг с другом для обеспечения возможности сетевого подключения. В этом разделе изложены требования, предъявляемые кластером ClusterXL к окружающей сетевой среде.

Режимы HA New и Load Sharing Unicast Режим Multicast является режимом по умолчанию протокола управления кластером (CCP) в режимах High Availability New (Высокая доступность в новом режиме) и Load Sharing Unicast (Одноадресное распределение нагрузки), равно как и в режиме Load Sharing Multicast (Многоадресное распределение нагрузки).

При использовании CCP в многоадресном режиме выполните следующие настройки на коммутаторе.

Настройка коммутатора на режим High Availability New и Load Sharing

Настройка коммутатора

Описание

IGMP и статические CAM-записи

По умолчанию ClusterXL не поддерживает регистрацию IGMP (или т.н. отслеживание сетевого IGMP-трафика). Либо отключите регистрацию IGMP на коммутаторах, использующих IGMP-пакеты для конфигурирования своих портов, либо активируйте регистрацию IGMP в ClusterXL. В ситуациях, когда отключение регистрации IGMP недопустимо, для разрешения многоадресного трафика на определенных портах необходимо настроить статические CAM-записи.

Снятие ограничений по количеству многоадресных передач данных

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

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

Если коммутатор не допускает установку ни одной из этих настроек, возможно, хотя это и менее эффективно, настроить коммутатор на использование широковещательной адресации трафика и настроить элементы кластера на использование широковещательного CCP-протокола (см. "Выбор режима



передачи CCP на элементах кластера" на стр. 38).

Выполните следующие настройки на маршрутизаторе:

Настройка маршрутизатора на режим High Availability New и Load Sharing Unicast

Настройка маршрутизатора

Описание

Индивидуальный MAC-адрес

При работе в режимах High Availability Legacy, High Availability New и Load Sharing Unicast IP-адрес кластера совмещен с обычным MAC-адресом, который соответствует MAC-адресу активного элемента. Маршрутизатор должен уметь узнавать этот MAC-адрес посредством регулярных ARP-сообщений.

Режим Load Sharing Multicast При работе в режиме Load Sharing Multicast выполняются следующие настройки коммутатора:

Настройка коммутатора на режим Load Sharing Multicast

Настройка коммутатора

Описание

CCP в многоадресном режиме

Режим Multicast является режимом по умолчанию протокола управления кластером (CCP) в режиме Load Sharing Multicast.

Зеркалирование порта

ClusterXL не поддерживает использование индивидуальных MAC-адресов с зеркалированием порта для решений Multicast Load Sharing.

При работе в режиме Load Sharing Multicast маршрутизатор должен поддерживать отправку одноадресных IP-пакетов с групповыми MAC-адресами. Это необходимо для того, чтобы все элементы кластера получали пакеты данных.

Для поддержки этого режима может потребоваться выполнение следующих настроек в зависимости от модели маршрутизатора:

Настройка маршрутизатора на режим Load Sharing Multicast

Настройка маршрутизатора

Описание

Статическая MAC-запись

Большинство маршрутизаторов способны автоматически узнавать ARP-записи с индивидуальным IP и групповым MAC с помощью ARP-механизма. Если ваш маршрутизатор не способен динамично распознавать такое соответствие, вам нужно настроить статические MAC-записи.

IGMP и статические CAM

Некоторые маршрутизаторы требуют отключения отслеживания IGMP или настройки статических CAM-записей для поддержки одноадресных IP-пакетов с групповыми MAC-адресами.


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

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

Отключение переадресации многоадресного трафика на маршрутизатор

Некоторые маршрутизаторы отправляют многоадресный трафик на сам маршрутизатор. Это может привести к передаче лавины пакетов через сеть, поэтому данную опцию следует отключить.

Аппаратная совместимость ClusterXL Следующие маршрутизаторы и коммутаторы совместимы со всеми режимами ClusterXL:



Маршрутизаторы

Cisco серии 7200

Cisco серий 1600, 2600, 3600

Маршрутизирующий коммутатор

Extreme Networks Blackdiamond (отключите отслеживание сетевого IGMP-трафика)

Extreme Networks Alpine серии 3800 (отключите отслеживание сетевого IGMP-трафика)

Foundry Network Bigiron серии 4000

Nortel Networks Passport серии 8600

Cisco Catalyst серии 6500 (отключите отслеживание сетевого IGMP-трафика, настройте групповые MAC-адреса вручную)

Коммутаторы

Cisco Catalyst серий 2900, 3500

Nortel BayStack 450

Alteon 180e

Dell PowerConnect 3248 и PowerConnect 5224

Пример конфигурации маршрутизирующего коммутатора Cisco Catalyst Следующий пример показывает, как выполнять команды конфигурирования, необходимые для поддержки ClusterXL на маршрутизирующем коммутаторе Cisco Catalyst серии 6500. Подробности и инструкции по другим сетевым устройствам см. в документации поставщика устройства.

Отключение отслеживания сетевого IGMP-трафика

Для отключения отслеживания сетевого IGMP-трафика выполните:

no ip igmp snooping

Определение статических CAM-записей

Для добавления постоянной многоадресной записи в таблицу для порта 1 модуля 1 и портов 1, 3 и 8-12 модуля 2:

1. Выберите Console> (enable), чтобы настроить постоянные CAM 01-40-5e-28-0a-64 1/1,2/1,2/3,2/8-12.

2. Постоянная многоадресная запись добавлена в таблицу CAM.

3. Выберите Console> (enable).

Для определения MAC-адресов, требующих настройки:

1. В сети с IP-адресом кластера x.y.z.w:

Если y<=127, то групповой MAC-адрес имел бы вид: 01:00:5e:y:z:w. Пример: 01:00:5e:5A:0A:64 для 192.90.10.100

Если y>127, то групповой MAC-адрес имел бы вид: 01:00:5e:(y-128):z:w. Пример: 01:00:5e:28:0A:64 для 192.168.10.100 (168-128=40 = 28 в шестнадцатеричном виде).

2. Для сети x.y.z.0, не имеющей IP-адреса кластера, например, для сети синхронизации, следовало бы использовать такую же процедуру, подставив fa вместо 0 в последнем октете MAC-адреса.

Пример: 01:00:5e:00:00:fa для сети 10.0.0.X.


Для отключения ограничений по количеству многоадресных передач данных выполните:

no storm-control multicast level



Настройка статической ARP-записи на маршрутизаторе

Для определения статической ARP-записи:

1. Определите MAC-адрес (см. "Определение статических CAM-записей" на стр. 32).

2. Выполните arp <MAC address> arpa

Отключение отправки многоадресных пакетов на маршрутизатор

Для отключения отправки многоадресных пакетов на маршрутизатор:

1. Определите MAC-адрес (см. "Определение статических CAM-записей" на стр. 32).

2. Выполните set cam static <MAC address> module/port.

Программная совместимость Check Point

Совместимость с операционными системами В следующей таблице перечислены операционные системы, поддерживаемые ClusterXL с ограничениями, указанными в примечаниях ниже. Подробнее о поддерживаемых версиях этих операционных систем см. в "Примечания к изданию R75.40VS" (http://supportcontent.checkpoint.com/solutions?id=sk76540).

Совместимость ClusterXL с операционными системами

Операционная система Распределение нагрузки Высокая доступность

Check Point SecurePlatform Да Да

Примечания 1. VLAN поддерживаются на всех интерфейсах.

Совместимость ClusterXL (кроме IPS) В следующей таблице и сопроводительных примечаниях представлена совместимость решений Load Sharing и High Availability кластера ClusterXL с кластерами, имеющими сертификат OPSEC (см. "Работа с продуктами кластеризации, имеющими сертификат OPSEC" на стр. 42). Некоторые продукты и опции Check Point не поддерживаются или лишь частично поддерживаются (см. сноски) кластером ClusterXL.

Продукты и опции, не полностью поддерживаемые кластером ClusterXL

Опция или продукт Опция Распределение нагрузки


Security Management Нет Нет

Firewall Серверы аутентификации/безопасности

Да (1) Да (1)

Firewall Серверы ACE и SecurID Да Да

Firewall Контроль протокола Application Intelligence (2)

Да (3) Да

Firewall Верификатор последовательностей

Да (4) Да (1)

Firewall UDP-инкапсуляция Да Да

Firewall SAM Да Да

Firewall ISP-резервирование Да Да




Опция или продукт Опция Распределение нагрузки


VPN (Виртуальная частная сеть)

Сторонние VPN-узлы Да Да

<esp> Client Сервер распространения программного обеспечения (SDS)

Нет Нет

<esp> Client IP для каждого пользователя в офисном режиме

Да Да

Аппаратное ускорение SecureXL или Performance Pack

Да Да

Check Point QoS Да (4)(5) Да

SmartProvisioning Шлюз безопасности SmartLSM

Нет Нет

Шлюз безопасности Check Point

Да Да

1. В случае если при получении фрагментов произойдет аварийное переключение, пакет будет потерян.

2. Теряет работоспособность при аварийном переключении.

3. Требует односторонней привязки. Это означает, что один и тот же элемент должен получать все внешние пакеты и один и тот же элемент должен получать все внутренние пакеты, при этом необязательно, чтобы один и тот же элемент получал как внутренние, так и внешние пакеты.

4. Требует двусторонней привязки соединений.

5. Использует уровень передачи, рассматриваемый в следующем разделе.

Совместимость ClusterXL с IPS Ниже перечислены опции IPS, поддерживаемые кластером ClusterXL c ограничениями, указанными в примечаниях.

Совместимость ClusterXL с IPS

Опция Распределение нагрузки Высокая доступность

Проверка исправности фрагментов Да (1, 3) Да (1)

Распознавание образцов Да (2, 3) Да (2)

Верификатор последовательностей Да (2, 4) Да (2)

Серверы безопасности FTP, HTTP и SMTP

Да (2, 5) Да (2)

1. В случае если при получении фрагментов произойдет аварийное переключение, пакет будет потерян.





Сноски 1. В случае если при получении фрагментов произойдет аварийное переключение, пакет будет потерян.







Механизм Forwarding Layer Forwarding Layer — это механизм ClusterXL, который позволяет элементу кластера передавать пакеты другим элементам после их локальной проверки блейдом Firewall. Эта опция позволяет открывать соединения элемента кластера с внешним хостом.

Пакеты, инициируемые элементами кластера, скрываются за виртуальным IP кластера. Таким образом, ответ от внешнего хоста отправляется не прямо элементу-источнику, а кластеру. Это может привести к проблемам в следующих ситуациях:

Кластер работает в режиме New High Availability, а соединение открывается с резервной машины. При этом все пакеты от внешнего хоста обрабатываются активной машиной.

Кластер работает в одном из режимов Load Sharing, а функция принятия решений выбрала другой элемент для обработки этого соединения. Это возможно, поскольку пакеты, направляемые на IP кластера, распределяются между элементами кластера, как и в случае с любым другим соединением.

Если по завершении проверки блейдом Firewall элемент кластера принял решение о том, что пакет предназначен для другого элемента, он может использовать Forwarding Layer для передачи пакета по назначению. Это происходит путем отправки пакета через защищенную сеть (любую подсеть, назначенную сетью синхронизации) прямо этому элементу. Важно использовать только защищенные сети, так как во время проверки зашифрованные пакеты расшифровываются и передаются открытым текстом (как незашифрованные данные).

Пакеты, отправляемые с помощью Forwarding Layer, используют особый MAC-адрес источника, тем самым сообщая элементу-получателю о том, что они уже прошли проверку другим шлюзом безопасности. Таким образом, элемент-получатель может без риска передать эти пакеты локальной операционной системе без дополнительной проверки. Этот процесс безопасен, потому что сети синхронизации всегда должны быть изолированы от любой другой сети (с использованием выделенной сети).

Конфигурирование топологии кластера 1. На странице Topology (Топология) щелкните Edit Topology (Изменить топологию) и определите

виртуальные IP-адреса кластера и как минимум одну сеть синхронизации.

2. В окне Edit Topology:

a) Определите топологию для каждого интерфейса. Чтобы автоматически считать все предустановленные настройки на интерфейсах элементов, щелкните Copy topology to cluster interfaces (Копировать топологию на интерфейсы кластера).

b) В столбце Network Objective (Задача сети) выберите из списка задачу для каждой сети. Описание разных вариантов приведено в интерактивной справке. Для определения новой сети щелкните Add Network (Добавить сеть).



3. Определите топологию для каждого виртуального интерфейса кластера. В ячейке виртуального интерфейса кластера щелкните правой кнопкой мыши и выберите Edit Interface (Изменить интерфейс). Откроется окно Interface Properties (Свойства интерфейса).

a) На вкладке General (Общие) дайте имя виртуальному интерфейсу в поле Name (Имя) и определите IP-адрес в поле IP Address.

b) На вкладке Topology укажите, является ли интерфейс внутренним или внешним, и настройте антиспуфинг.

c) На вкладке Member Networks (Сети элементов) определите сеть элемента и при необходимости сетевую маску. Описание этой дополнительной опции приведено в разделе "Настройка адресов кластера в разных подсетях".


Глава 5

Конфигурирование ClusterXL В этой главе

Подготовка элементов кластера 37

Конфигурирования маршрутизации для машин-клиентов 37

Выбор режима передачи CCP на элементах кластера 38

Конфигурирование объектов и элементов кластера 38

ClusterXL High Availability для IPv6 40

В этом разделе рассматривается порядок конфигурирования режимов Load Sharing Multicast, Load Sharing Unicast и High Availability New с самого начала. Конфигурирование режимов выполняется идентичным образом, за исключением выбора объекта кластера шлюзов на панели инструментов SmartDashboard или выбора режима в мастере создания кластера шлюзов.

Если вы используете режим High Availability Legacy, см. приложение ("Режим High Availability Legacy" на стр. 99).

Подготовка элементов кластера Для подготовки элементов кластера:

1. Получите и установите центральную лицензию ClusterXL на ваш сервер управления безопасностью.

2. Установите и настройте шлюз безопасности Check Point на всех элементах кластера. Каждый элемент должен использовать одинаковую версию и сборку. Процедуры установки и начального конфигурирования приведены в "Руководстве по установке и обновлению R75.40VS" (http://supportcontent.checkpoint.com/solutions?id=sk76540).

a) Во время установки активируйте ClusterXL и State Synchronization (Синхронизация состояний), отметив опцию Enable cluster membership for this gateway (Активировать членство в кластере для этого шлюза) для элементов Secure Platform и Solaris или This Gateway is part of a cluster (Этот шлюз входит в состав кластера) для элементов на базе Windows.

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

3. Определите IP-адрес для каждого интерфейса на всех элементах.

4. Для элементов кластера VPN выполните синхронизацию часов элементов с точностью до одной секунды. Если эти элементы постоянно включены и работают, то однократной настройки времени обычно бывает достаточно. Более надежной синхронизации можно достичь с помощью NTP или других сервисов синхронизации времени, предлагаемых операционной системой. Синхронизация часов элементов кластера имеет отношение только к кластерам VPN; в противном случае она не нужна.

5. Соедините элементы кластера друг с другом и с сетями посредством коммутаторов. Для интерфейсов синхронизации вы можете использовать кросс-кабель или выделенный коммутатор. Каждая сеть (внутренняя, внешняя, сеть синхронизации, DMZ и пр.) должна быть настроена на отдельной VLAN-сети, коммутаторе или хабе.

Примечание: вы также можете выполнить синхронизацию в глобальной компьютерной сети (WAN) (см. "Синхронизация кластеров в глобальной компьютерной сети" на стр. 15).

Конфигурирование маршрутизации для машин-клиентов Для конфигурирования маршрутизации для машин-клиентов:

1. Настройте маршрутизацию таким образом, чтобы для связи с внутренними сетями использовался внешний IP-адрес кластера. Например, настройте статический маршрут, при котором внутренняя сеть


Конфигурирование ClusterXL


10.10.0.0 достигается через 192.168.10.100.

2. Настройте маршрутизацию таким образом, чтобы для связи с внешними сетями использовался внутренний IP-адрес кластера. Например, задайте внутренний IP-адрес сети 10.10.0.100 как шлюз по умолчанию для каждого компьютера на внутренней стороне маршрутизатора.

Выбор режима передачи CCP на элементах кластера Протокол управления кластером ClusterXL (CCP) по умолчанию использует многоадресный режим, потому что он эффективнее широковещания. Если коммутатор не может передавать многоадресный трафик, то возможно, хотя это менее эффективно, настроить коммутатор на использование широковещательной адресации трафика.

Для переключения между режимами широковещательной и многоадресной передачи данных по протоколу CCP:

На каждом элементе кластера выполните следующую команду из адресной строки: cphaconf set_ccp broadcast/multicast

Конфигурирование объектов и элементов кластера На странице Topology объекта-кластера настройте топологию объекта-кластера и его элементов. IP-адреса кластера являются виртуальными, поскольку не относятся к какому-либо физическому интерфейсу. Свяжите один или несколько интерфейсов сети синхронизации с каждым элементом кластера.

На следующей схеме сети представлена типичная развернутая система ClusterXL, которая используется во многих примерах, содержащихся в рассматриваемых в этой главе процедурах.

Для определения нового объекта — кластера шлюзов:

1. В дереве Network Objects (Сетевые объекты) щелкните правой кнопкой мыши по Check Point и выберите Security Cluster (Кластер безопасности).

2. Если на экране появится окно Security Gateway Cluster Creation (Создание кластера шлюзов безопасности), выберите один из следующих способов создания нового объекта-кластера:

Simple Mode (Wizard) — простой режим (мастер), который содержит пошаговую инструкцию по настройке. Подробную информацию см. в интерактивной справке.

Classic Mode — классический режим, описанный в следующем разделе.

ЛВС





Интернет

Элемент B









Элемент A


(маршрутизируемый адрес)



Использование мастера Конфигурирование в классическом режиме Порядок конфигурирования

Настройка общих свойств 39

Определение элементов кластера 39

Настройка свойств ClusterXL 39

Конфигурирование топологии кластера 40

Завершение процедуры определения 40

Настройка общих свойств

Для настройки общих свойств кластера:

1. Введите уникальное имя для этого объекта-кластера в соответствующем поле.

2. Введите главный IP-адрес кластера.

3. Выберите ClusterXL как продукт, установленный на кластере.

4. Активируйте ClusterXL и по необходимости другие программные блейды сетевой безопасности.

Определение элементов кластера

Для конфигурирования элемента кластера:

1. На странице Cluster Members щелкните Add > New Cluster Member (Добавить > Новый элемент кластера).

2. На вкладке General окна Cluster Members Properties (Свойства элементов кластера) введите имя элемента в поле Name и физический IP-адрес с возможностью маршрутизации с сервера управления безопасностью в поле IP Address. Это может быть внутренний или внешний адрес или выделенный интерфейс управления.

3. Щелкните Communication (Связь) и инициализируйте доверие для защищенной внутренней связи (SIC).

4. Установите нужные настройки NAT и VPN на соответствующих вкладках. Подробнее см. в "Руководстве администратора Security Management R75.40VS" (http://supportcontent.checkpoint.com/solutions?id=sk76540).

Добавление существующего шлюза в качестве элемента

Чтобы добавить существующий шлюз в качестве элемента кластера, выберите Add > Add Gateway to Cluster (Добавить > Добавить шлюз в кластер) на странице Cluster Members и выберите шлюз из списка в окне Add Gateway to Cluster.

Удаление элемента

Чтобы удалить шлюз из кластера, щелкните Remove (Удалить) на странице Cluster Members и выберите Detach Member from Cluster (Отсоединить элемент от кластера) или щелкните правой кнопкой мыши по элементу кластера в дереве Network Objects и выберите Detach from Cluster (Отсоединить от кластера).

Настройка свойств ClusterXL

Для настройки свойств ClusterXL:

1. В развернутых системах High Availability активируйте опцию High Availability и

a) Выберите один из следующих режимов:

New (по умолчанию)

Legacy

b) Выберите действие, выполняемое при восстановлении первичного элемента:

Maintain the current active cluster member (Оставить текущий активный элемент кластера)

Switch back to a higher priority cluster member (Переключиться на элемент кластера с более высоким приоритетом)

2. В развернутых системах Load Sharing активируйте опцию Load Sharing и выберите один из следующих режимов в зависимости от возможностей вашего маршрутизатора:




Multicast (по умолчанию)

Unicast

3. Выберите опцию Use State Synchronization (Использовать синхронизацию состояний) в зависимости от конфигурации:

а) Конфигурации Load Sharing требуют использования синхронизации состояний. Эта опция активирована по умолчанию, и ее нельзя отключить.

б) Для конфигурации High Availability New синхронизация состояний является опциональной, но по умолчанию активирована. Если вы решили отключить синхронизацию состояний, элементы кластера не синхронизируются и в случае аварийного переключения существующие соединения на отказавшем шлюзе будут прерваны.

4. Выберите опции отслеживания из списка.

Конфигурирование топологии кластера 1. На странице Topology щелкните Edit Topology и определите виртуальные IP-адреса кластера и как

минимум одну сеть синхронизации.

2. В окне Edit Topology:

a) Определите топологию для каждого интерфейса. Чтобы автоматически считать все предустановленные настройки на интерфейсах элементов, щелкните Copy topology to cluster interfaces.

b) В столбце Network Objective выберите из списка задачу для каждой сети. Описание разных вариантов приведено в интерактивной справке. Для определения новой сети щелкните Add Network.

3. Определите топологию для каждого виртуального интерфейса кластера. В ячейке виртуального интерфейса кластера щелкните правой кнопкой мыши и выберите Edit Interface. Откроется окно Interface Properties.

a) На вкладке General дайте имя виртуальному интерфейсу в поле Name и определите IP-адрес в поле IP Address.

b) На вкладке Topology укажите, является ли интерфейс внутренним или внешним, и настройте антиспуфинг.

c) На вкладке Member Networks определите сеть элемента и при необходимости сетевую маску. Описание этой дополнительной опции приведено в разделе "Настройка адресов кластера в разных подсетях".

Завершение процедуры определения 1. Установите нужные настройки на других страницах в объекте-кластере (NAT, VPN, Remote Access и

пр.).

2. Установите политику безопасности на кластере.



ClusterXL High Availability для IPv6 R75.40VS ClusterXL поддерживает кластеры High Availability для IPv6. Благодаря этому информация о состоянии IPv6 синхронизируется, и при аварийном переключении активируется кластерный механизм IPv6.

Когда вы используете R75.40VS ClusterXL (например, с IPv4), ClusterXL выполняет как синхронизацию состояний, так и кластеризацию. На панели инструментов SmartDashboard необходимо определить адреса кластера IPv6 для каждого элемента, входящего в состав кластера.

ClusterXL High Availability При использовании R75.40VS ClusterXL синхронизация состояний и кластеризация High Availability осуществляются с использованием ClusterXL. При аварийном переключении кластер High Availability, как правило, отправляет пакеты самообращенных ARP-запросов для обновления ARP-кэша хостов/маршрутизаторов, подключенных к интерфейсам кластера, путем объявления нового MAC-адреса для виртуальных IPv4-адресов кластера.

R75.40VS ClusterXL дает способность обновления IPv6-сети при аварийных переключениях. Cluster XL отправляет сообщение — анонсирование соседа для обновления соседнего кэша (который соответствует ARP-кэшу в IPv4) путем объявления нового MAC-адреса для виртуального IPv6-адреса кластера. Кроме того, в ответ на любой запрос соседа ClusterXL отправит целевой адрес, соответствующий виртуальному IPv6-адресу кластера.

Примечание: обнаружение аварийного переключения в ClusterXL происходит с

использованием IPv4-тестирования. При смене состояния драйвер IPv4 командует драйверу IPv6 переустановить сетевое соединение IPv6 с кластером HA.

Конфигурирование кластеров IPv6 Чтобы активировать функционал IPv6 для интерфейса, определите IPv6-адрес для подходящего интерфейса на кластере и на каждом элементе. Все интерфейсы, для которых настроен IPv6-адрес, должны иметь и соответствующий IPv4-адрес. Если интерфейс не требует IPv6, достаточно определить только IPv4-адрес.

Примечание: для интерфейсов синхронизации настроить только IPv4-адрес. Это

связано с тем, что механизм при работе использует только IPv4. Вся информация и состояния IPv6 синхронизируются с помощью этого интерфейса.

Для конфигурирования IPv6-адресов для интерфейсов и элементов кластера:

1. На панели инструментов SmartDashboard создайте новый объект-кластер или дважды щелкните по существующему объекту-кластеру.

2. Щелкните ClusterXL в навигационном дереве.

3. Выберите High Availability.

4. Щелкните Topology > Edit (Топология > Правка).

Откроется окно Edit Topology.

5. Щелкните Add Network.

6. Введите информацию об интерфейсе и элементах кластера в соответствующие поля (IPv4-адрес, сетевая маска, IPv6-адрес, длина префикса).

Чтобы ввести информацию, выберите ячейку и щелкните Edit (Правка).

Примечание: элементы кластера должны иметь такой же префикс IPv6-адреса,

что и интерфейс кластера. Разные префиксы не поддерживаются.

7. Щелкните OK, чтобы сохранить изменения.

По команде cphaprob stat или cphaprob -a отображается информация только по IPv4-адресу, потому

что механизм ClusterXL создан на базе IPv4. Если команда cphaprob stat показывает, что IPv4-адрес

включен и активен, значит IPv6-адрес тоже включен и активен.


Глава 6

Работа с продуктами кластеризации, имеющими сертификат OPSEC


О продуктах кластеризации, имеющих сертификат OPSEC 42

Конфигурирование продуктов кластеризации, имеющих сертификат OPSEC 42

Особенности работы командной строки CPHA в кластерах OPSEC 44

О продуктах кластеризации, имеющих сертификат OPSEC Существует ряд продуктов High Availability, иногда называемых Hot Standby (Горячий резерв), и Load Sharing, иногда называемых Load Balancing (Балансировка нагрузки), имеющих сертификат OPSEC. Эти продукты предназначены для создания высокодоступных кластеров шлюзов безопасности и равномерного распределения трафика между шлюзами кластера.

Каждое приложение кластеризации, имеющее сертификат OPSEC, обладает своими преимуществами и возможностями, будь то мониторинг, управление или производительность. Задача этих приложений кластеризации состоит в следующем:

1. Принятие решения о том, какой элемент кластера будет обрабатывать соединение.

2. Проведение проверок работоспособности. К ним относятся проверка состояния элемента кластера (например: активный, резервный, выключен) и проверка состояния интерфейсов элемента.

3. Осуществление аварийного переключения.

Продукты кластеризации, имеющие сертификат OPSEC, используют механизм синхронизации состояний Check Point (см. "Синхронизация информации о соединениях в кластере" на стр. 12) для обновления информации о соединениях и других состояниях и обмена этой информацией между элементами кластера.

В данном руководстве приведены общие указания по работе с продуктами кластеризации, имеющими сертификат OPSEC. Каждый продукт кластеризации имеет свои особенности конфигурирования. В связи с этим настоятельно рекомендуется соблюдать инструкции, прилагаемые к продукту OPSEC.

Конфигурирование продуктов кластеризации, имеющих сертификат OPSEC

Ниже представлена процедура конфигурирования решения кластеризации, имеющего сертификат OPSEC.

Подготовка коммутаторов и конфигурирование маршрутизации Соблюдайте инструкции, приведенные в документации по вашему продукту кластеризации, при:

Подготовке коммутаторов и маршрутизаторов

Конфигурировании маршрутизации

Подготовка машин — элементов кластера Для подготовки машин — элементов кластера:

1. Определите IP-адреса для всех интерфейсов на всех элементах кластера.

2. Соедините сетевые машины кластера посредством коммутаторов. Для интерфейсов синхронизации рекомендуется использовать кросс-кабель или выделенный коммутатор.



Примечание: существует возможность синхронизации в глобальной

компьютерной сети (WAN). (Подробности см. в разделе "Синхронизация кластеров в глобальной компьютерной сети" на стр. 15).

3. Для кластеров IPSO настройте VRRP или IP Clustering перед установкой шлюза безопасности Check Point.

4. Для кластеров, имеющих сертификат OPSEC, следуйте рекомендациям поставщика.

После завершения установки убедитесь в том, что опция Enable VPN-1/FW-1 monitoring (Активировать мониторинг VPN-1/FW-1) в менеджере конфигурирования IPSO установлена на Enable (Активировать). Теперь IPSO будет отслеживать изменения в состоянии брандмауэра. Для VRRP и IP Clustering в IPSO 3.8.2 и последующих версиях информация о состоянии брандмауэра передается кластеру IPSO для целей аварийного переключения.

5. Установите шлюз безопасности Check Point на всех элементах кластера. На этапе конфигурирования (или позже, с помощью инструмента конфигурирования cpconfig):

Установите лицензию шлюза безопасности Check Point на каждом элементе кластера. Специальной лицензии для использования продукта OPSEC совместно со шлюзом безопасности не требуется.

В процессе конфигурирования активируйте State Synchronization, отметив опцию Enable cluster membership for this gateway на машинах с Unix или This Gateway is part of a cluster для Windows.

Конфигурация SmartDashboard для кластеров OPSEC Создайте объект — кластер шлюзов с помощью панели инструментов SmartDashboard. Чтобы определить новый объект — кластер шлюзов, щелкните правой кнопкой мыши по дереву Network Objects и выберите New Check Point > Gateway Cluster… (Новый Check Point > Кластер шлюзов...). Для конфигурирования объекта — кластера шлюзов можно выбрать:

Simple Mode (Wizard) — простой режим (мастер), который содержит пошаговую инструкцию по настройке. Подробную информацию см. в интерактивной справке.

Classic Mode — классический режим, который рассматривается ниже.

Конфигурирование в классическом режиме Для использования классического режима с OPSEC:

1. В окне General Properties объекта — кластера шлюзов присвойте кластеру общий IP-адрес. Как правило, он должен быть сделан внешним виртуальным IP-адресом кластера.

Убедитесь в том, что в списке Check Point Products (Продукты Check Point) не выбран ClusterXL.

2. На странице Cluster Members щелкните Add > New Cluster Member, чтобы добавить элементы в

кластер.

Элементы кластера существуют только внутри объекта — кластера шлюзов. Для каждого элемента кластера:

На вкладке Cluster Members Properties > General (Свойства элементов кластера > Общие) задайте имя в поле Name и IP-адрес в поле IP Address. Выберите IP-адрес с возможностью маршрутизации с сервера управления безопасностью — это нужно для успешной установки политики безопасности. Это может быть внутренний или внешний адрес или выделенный интерфейс управления.

Щелкните Communication и инициализируйте доверие для защищенной внутренней связи (SIC).

Задайте нужные настройки на вкладках NAT и VPN.

Вы также можете добавить существующий шлюз в качестве элемента кластера, выбрав Add > Add

Gateway to Cluster на странице Cluster Members и выбрав шлюз из списка в окне Add Gateway to

Cluster.

Если вы хотите удалить шлюз из кластера, щелкните Remove на странице Cluster Members и

выберите Detach Member from Cluster или щелкните правой кнопкой мыши по элементу кластера в

дереве Network Objects и выберите Detach from Cluster.

3. На странице 3rd Party Configuration (Конфигурирование стороннего решения) укажите режим работы кластера, выберите OPSEC для опции 3rd Party Solution (Стороннее решение) и отметьте Use State Synchronization.

4. Страница Topology используется для определения виртуальных IP-адресов кластера и адресов элементов кластера.

Для каждого элемента кластера определите интерфейсы для отдельных элементов.

Для некоторых продуктов, имеющих сертификат OPSEC, конфигурирование виртуальных IP-адресов

кластера является обязательным, в других оно запрещено. Подробности см. в документации по

вашему кластерному продукту.



Определите сети синхронизации. В зависимости от реализации OPSEC у вас может быть возможность

"получить" сеть синхронизации из конфигурации OPSEC, если она уже определена. См. документацию

OPSEC, чтобы узнать о наличии этой возможности в конкретном продукте OPSEC.

5. Теперь вернитесь на страницу 3rd Party Configuration.

Соединение без привязки — это соединение, при котором пакеты, передаваемые от клиента серверу и от сервера клиенту, проходят через разные элементы кластера. Соединения без привязки представляют проблему, потому что они могут привести к получению элементом кластера пакетов, не соответствующих таблице состояний. Шлюз безопасности будет отклонять пакеты, не соответствующие таблице состояний, даже если они относятся к допустимому соединению.

Чтобы шлюз безопасности пропускал допустимые соединения без привязки через кластер, либо механизм синхронизации, либо продукт кластеризации, имеющий сертификат OPSEC, должен уметь идентифицировать такие соединения.

Узнайте, способен ли продукт кластеризации, имеющий сертификат OPSEC, идентифицировать допустимые соединения без привязки.

Если данный продукт кластеризации не способен идентифицировать допустимые соединения без привязки, вместо него это будет делать механизм синхронизации. В этом случае отметьте Support non-sticky connections (Поддерживать соединения без привязки).

Если продукт кластеризации способен идентифицировать допустимые соединения без привязки, механизм синхронизации не должен этим заниматься. В этом случае снимите галочку с опции Support non-sticky connections. Обычно снятие галочки с этой опции безопасно в решениях High Availability (не Load Sharing). Отмена этой опции приведет к незначительному повышению скорости установления соединения.

Если отмечена опция Hide Cluster Members' outgoing traffic behind the Clusters IP Address (Скрывать исходящий трафик элементов кластера за IP-адресом кластера), следует дополнительно отметить опцию Support non-sticky connections для поддержки исходящих соединений от резервной машины (при отсутствии особых указаний в руководстве по продукту кластеризации, имеющему сертификат OPSEC).

6. Многие кластеры шлюзов помимо физических адресов интерфейсов элементов кластера имеют виртуальный IP-адрес, заданный на странице Topology. Использование виртуальных IP-адресов кластера влияет на настройки на странице 3rd Party Configuration.

Когда клиент, находящийся за кластером, устанавливает исходящее соединение с Интернетом, адрес источника в исходящих пакетах обычно представляет собой физический IP-адрес интерфейса элемента кластера. Если используются виртуальные IP-адреса кластера, продукт кластеризации обычно меняет IP-адрес источника (посредством NAT) на внешний виртуальный IP-адрес кластера.

Это соответствует отмеченной по умолчанию опции Hide Cluster Members' outgoing traffic behind the Cluster's IP address.

Когда клиент устанавливает входящее соединение с внешним виртуальным адресом кластера, продукт кластеризации меняет IP-адрес назначения (посредством NAT) на физический внешний адрес одного из элементов кластера.

Это соответствует отмеченной по умолчанию опции Forward Cluster's incoming traffic to Cluster Members' IP addresses (Передавать входящий трафик кластера на IP-адреса элементов кластера). На странице Topology определите интерфейсы для отдельных элементов. В большинстве решений OPSEC IP-адреса кластера не следует добавлять на вкладку Topology отдельного элемента. Подробную информацию см. в документации по вашему продукту кластеризации.

7. Установите нужные настройки на других страницах в объекте-кластере (NAT, VPN, Remote Access и пр.).


Примечание: при настройке кластера VRRP или IP в IPSO 3.9 и последующих версиях перед первой установкой политики следует отключить опцию monitor fw state (мониторинг состояния передачи). В противном случае вы не сможете определить IP-адреса кластера, и, следовательно, вам не удастся получить интерфейсы с помощью опции Get Interfaces (Получить интерфейсы) в разделе Topology окна Gateway Cluster Properties. После установки политики опция monitor fw state может быть снова включена.



Особенности работы командной строки CPHA в кластерах OPSEC

В этом разделе рассматриваются особенности работы командных строк, используемых в кластерах OPSEC.

Примечание: подробности о командных строках cpha см. в разделе "Мониторинг

и диагностика неполадок кластеров шлюзов" (на стр. 46).

Команды cphastart и cphastop в кластерах OPSEC Особенности работы команд cphastart и cphasstop в кластерах ClusterXL рассматриваются в разделе "Команды cphastart и cphastop" (на стр. 55).

В кластерах OPSEC команда cphastart не может привести к запуску элемента кластера. В кластерах IPSO особенности работы те же, что в случае с кластерами ClusterXL.

Команда cphastop не может привести к аварийному переключению в кластерах OPSEC. В кластерах IPSO IP Clustering (но не в кластерах VRRP) особенности работы те же, что и в случае с кластерами ClusterXL.

Как и в случае с кластерами ClusterXL, эти команды должны выполняться не непосредственно пользователем, а только шлюзом безопасности.

Команда cphaprob в кластерах OPSEC Команда cphaprob предназначена для проверки исправной работы кластера и его элементов. Эта команда имеет отношение только к кластерам IPSO IP Clustering и IPSO VRRP.

В кластерах OPSEC, кроме IPSO, либо вывод команды остается пустым, либо команда не дает результата.

Чтобы вывести на принтер распечатку об использовании cphaprob с указанием всех доступных команд, введите cphaprob в командную строку и нажмите Enter. Значение каждой из этих команд рассматривается в следующих разделах.

cphaprob state: При выполнении этой команды состояние машины соответствует лишь состоянию Check

Point и не отражает реального состояния машины. Команда только отслеживает успешность выполнения полной синхронизации и установки политики. В случае IP-кластеризации состояние является точным и отражает состояние кластера IPSO. В случае VRRP состояние является точным для брандмауэра, но неточно отражает состояние машины IPSO (например, отказ интерфейса не обнаруживается).

cphaprob [-a] if: Показывает только релевантную информацию: имя интерфейса и является ли он

интерфейсом синхронизации. "Multicast"/"Broadcast" относится только к протоколу управления кластером и касается только интерфейса синхронизации. Обратите внимание, что состояние интерфейса не выводится на печать, поскольку оно не отслеживается. (Это же относится к машине IPSO.)


Глава 7

Мониторинг и диагностика неполадок кластеров шлюзов


Проверка исправной работы кластера 46

Мониторинг состояния кластера с помощью клиентов SmartConsole 52

Команды конфигурирования ClusterXL 55

Как инициировать аварийное переключение 56

Мониторинг синхронизации (fw ctl pstat) 56

Диагностика проблем синхронизации 58

Сообщения об ошибках ClusterXL 67

Отказ запуска элемента после перезагрузки 70

Проверка исправной работы кластера

Команда cphaprob Команда cphaprob предназначена для проверки исправной работы кластера и его элементов, а также для определения критических устройств. Критическое устройство представляет собой процесс, выполняемый на элементе кластера, который позволяет элементу уведомлять другие элементы кластера о своей неспособности играть роль элемента. Устройство должно сообщать механизму ClusterXL о своем текущем состоянии, в противном же случае ClusterXL решает, что произошло аварийное переключение, и обязанности передаются другому элементу кластера. Когда критическое устройство, которое также называется сообщением о проблеме (pnote), отказывает, элемент кластера считается отказавшим.

Существует ряд встроенных критических устройств, и администратор может задать дополнительные критические устройства. В число критических устройств по умолчанию входят:

Интерфейсы кластера на элементах кластера.

Synchronization — успешно выполненная полная синхронизация.

Filter — политика безопасности и загружена ли она.

cphad — команда, которая выполняет процесс ClusterXL, называемый cphamcset.

fwd — демон шлюза безопасности.

Эти команды можно выполнять автоматически, включив их в скрипты.

Чтобы вывести на принтер распечатку об использовании cphaprob с указанием всех доступных команд, введите cphaprob в командную строку и нажмите Enter. Значение каждой из этих команд рассматривается в следующих разделах.



Мониторинг состояния кластера Для просмотра состояния одного или нескольких элементов кластера:

Выполните следующую команду:

cphaprob state

Выполняйте эту команду после настройки кластера, а также каждый раз, когда вы хотите увидеть состояние кластера.

Ниже приведен пример вывода команды cphaprob state:

Cluster mode (Режим кластера) может иметь следующие значения:

Load Sharing (Multicast) — Распределение нагрузки (Многоадресный режим)

Load Sharing (Unicast) — Распределение нагрузки (Одноадресный режим)

High Availability New Mode (Primary Up or Active Up) — Высокая доступность в новом режиме (использование первичного или активного элемента кластера).

High Availability Legacy Mode (Primary Up or Active Up) — Высокая доступность в режиме совместимости (использование первичного или активного элемента кластера).

Для сторонних продуктов кластеризации: "Service" (Сервис). Подробную информацию см. в разделе "Термины и определения" (на стр. 10).

Номер элемента означает идентификатор элемента для режима Load Sharing и приоритет для режима High Availability.

В конфигурации Load Sharing все элементы полноценно работающего кластера должны иметь значение Active (Активный). В конфигурациях High Availability только одна машина исправно работающего кластера должна иметь значение Active, а другие должны находиться в состоянии Standby (Резервный).

Для сторонних продуктов кластеризации отображается значение Active/Active (Активный/Активный), даже если один из элементов находится в резервном состоянии. Это объясняется тем, что данная команда выводит отчет только о состоянии процесса полной синхронизации. Для IPSO VRRP эта команда отображает точное состояние брандмауэра, но не элемента кластера (например, элемент может не работать исправно, но брандмауэр находится в активном состоянии).

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



Состояния кластера

Состояние Значение Передача пакетов?

Является ли это состояние проблемой?

Active Все в порядке. Да Нет

Active attention

Обнаружена проблема, но элемент кластера все равно передает пакеты, потому что является единственной машиной кластера или в кластере нет других активных машин. В любой другой ситуации элемент находился бы в состоянии down (не работает).

Да Да

Down Одно из критических устройств выключено. Нет Да

Ready Состояние Ready (Готов) означает, что машина признала себя элементом кластера и буквально готова к работе, но что-то не позволяет машине приступить к работе. То, что машина все еще не активна, может быть связано со следующими причинами:

1. Еще не все необходимые программные компоненты загружены и инициализированы и/или еще не все шаги конфигурации успешно завершены. Прежде чем элемент кластера становится активным, он отправляет сообщение остальным элементам кластера, проверяя, может ли он стать активным. В режиме High Availability он проверяет, присутствует ли активный элемент, а в режиме Load Sharing Unicast — присутствует ли главный элемент. Элемент остается в состоянии Ready, пока не получит ответ от остальных элементов кластера и не примет решение о том, какое состояние выбрать следующим (активный, резервный, главный или неглавный).

2. На этом элементе установлено программное обеспечение более поздней версии, чем на остальных элементах данного кластера. Например, при обновлении кластера с заменой одной версии шлюза безопасности Check Point на другую, в результате которой на элементах кластера установлены разные версии шлюзов безопасности Check Point, элементы с новой версией находятся в состоянии Ready, а элементы с предыдущей версией находятся в состоянии Active / Active.

3. Если в состав программного обеспечения, установленного на всех элементах кластера, входит CoreXL, который устанавливается по умолчанию в версиях начиная с R70, то элемент в состоянии Ready может иметь больше экземпляров CoreXL, чем другие элементы. Решение см. в sk42096.

Нет Нет

Standby Относится только к конфигурации High Availability и означает, что элемент ожидает, пока не откажет активная машина, после чего он начнет передавать пакеты.

Нет Нет

Initializing (Инициализация)

Начальное и переходное состояние элемента кластера. Элемент кластера загружается, продукт ClusterXL уже запущен, но шлюз безопасности еще не готов.

Нет Нет

ClusterXL неактивен или машина выключена

Локальная машина не может получить никакую информацию, поступающую с данного элемента кластера.

Неизвес-тно

Да



Мониторинг интерфейсов кластера Для просмотра интерфейсов элементов кластера и виртуальных интерфейсов кластера:

Выполните следующую команду на элементах кластера:

cphaprob [-a] if

Вывод этой команды должен соответствовать конфигурации на странице Topology объекта кластера.

Пример:

Интерфейсы являются критическими устройствами ClusterXL. ClusterXL проверяет количество исправных интерфейсов и устанавливает значение Required interfaces (Требуемые интерфейсы) на максимальное количество исправных интерфейсов, обнаруженных с момента последней перезагрузки. Если количество исправных интерфейсов меньше требуемого количества, ClusterXL инициирует аварийное переключение. То же касается защищенных интерфейсов, отображаемых в строке secured interfaces, где учитываются только исправные интерфейсы синхронизации.

Интерфейс может быть:

Non-secured (Незащищенный) или Secured (Защищенный). Защищенный интерфейс — это интерфейс синхронизации.

Shared (Совместного использования) или unique (уникальный). Интерфейс совместного использования имеет отношение только к режиму High Availability Legacy.

Multicast (Многоадресный) или broadcast (широковещательный). Режим протокола управления доступом (CCP), используемый в кластере. Вместо CCP можно использовать широковещательный режим. Для переключения между этими двумя режимами применяется команда cphaconf set_ccp <broadcast|multicast>

Для сторонних продуктов кластеризации, кроме IPSO IP Clustering, по команде cphaprob -a if всегда должны отображаться виртуальные IP-адреса кластера.

Когда интерфейс находится в состоянии DOWN, т.е. не работает, это означает, что он не может получать или передавать CCP-пакеты или не может ни то, ни другое. Это может произойти, когда интерфейс неисправен, подключен к не той подсети, не способен перехватить пакеты Multicast Ethernet и т.д. Кроме того, интерфейс может быть способен получить CCP-пакеты, но не передать их, в случае чего считывается поле состояния. Отображаемое время представляет собой количество секунд, прошедших с момента, когда интерфейс в последний раз смог получить/передать CCP-пакет.

Дополнительную информацию см. в разделе "Определение отключенных интерфейсов" (на стр. 90).



Мониторинг критических устройств Когда критическое устройство отказывает, элемент кластера считается отказавшим. Чтобы увидеть список критических устройств элемента кластера, а также всех других машин в кластере, выполните на данном элементе кластера следующую команду:

cphaprob [-i[a]] [-e] list

Существует ряд встроенных критических устройств, и администратор может задать дополнительные критические устройства. В число критических устройств по умолчанию входят:

Интерфейсы кластера на элементах кластера.

Synchronization — успешно выполненная полная синхронизация.

Filter — политика безопасности и загружена ли она.

cphad — команда, которая выполняет процесс ClusterXL, называемый cphamcset.

fwd — демон шлюза безопасности.

Для IPSO Clustering эта команда выводит то же, что и в случае с кластерами ClusterXL. Для других сторонних продуктов она не выводит ничего. В следующем примере вывод показывает, что процесс fwd не работает:



Регистрация критического устройства

В список критических устройств по умолчанию вы можете добавить пользовательское критическое устройство. Зарегистрируйте <device> (т.е. устройство) как критический процесс с помощью вышеуказанной команды и добавьте его в список устройств, которые должны быть запущены, для того чтобы элемент кластера считался активным. Если устройство отказало, то элемент кластера считается отказавшим.

Если устройству не удалось связаться с элементом кластера в течение тайм-аута, заданного параметром <timeout> в секундах, устройство считается отказавшим. Если вы не хотите задавать тайм-аут, используйте значение 0.

Задайте состояние устройства, о котором будет сообщено кластеру ClusterXL после регистрации. Таким начальным состоянием может быть одно из следующих:

ok — устройство работает.

init — устройство инициализируется. Машина не работает. Это состояние не дает машине стать активной.

problem — устройство отказало.

[-p] делает эти изменения постоянными. После выполнения перезагрузки или удаления шлюза безопасности (например, в Linux или IPSO) и его повторного подключения состояние критических устройств, зарегистрированных с добавлением этого флага, будет сохранено.

Регистрация критических устройств, перечисленных в файле

cphaprob -f <file> register

С помощью этой команды вы можете зарегистрировать все пользовательские критические устройства, перечисленные в файле, заданном параметром <file>. Файл должен быть в формате ASCII, и каждое устройство должно быть указано в нем в отдельной строке. В каждой строке должно быть перечислено три следующих параметра, отделенных как минимум пробелом или знаком табуляции:

<device> <timeout> <status>

<device> — имя критического устройства. Оно должно содержать не более 15 символов без пробелов.

<timeout> — если устройству не удалось связаться с элементом кластера в течение тайм-аута, заданного в секундах, устройство считается отказавшим. Если вы не хотите задавать тайм-аут, используйте значение 0.

<status> — может иметь одно из следующих значений:



problem — устройство отказало.

Отмена регистрации критического устройства

cphaprob -d <device> [-p] unregister

Отмена регистрации устройства, определенного пользователем как критический процесс. Это означает, что данное устройство больше не считается критическим. Если перед выполнением этой команды было зарегистрировано состояние "problem" критического устройства (а значит, и элемента кластера), то после выполнения этой команды состояние кластера будет зависеть только от оставшихся критических устройств.

[-p] делает эти изменения постоянными. Это означает, что после выполнения перезагрузки или удаления ядра (например, в Linux или IPSO) и его повторного подключения эти критические устройства останутся незарегистрированными.



Информирование ClusterXL о состоянии критического устройства

cphaprob -d <device> -s <ok|init|problem> report

Эта команда используется для информирования кластера ClusterXL о состоянии пользовательского критического устройства.

<device> означает устройство, которое должно быть запущено, для того чтобы элемент кластера считался активным. Если устройство отказало, то элемент кластера считается отказавшим.

Сообщаемое состояние. Это может быть одно из следующих состояний:



problem — устройство отказало. Если ClusterXL был проинформирован об этом состоянии, это приведет к немедленному аварийному переключению с данного элемента кластера на другой элемент.

Если устройству не удалось связаться с элементом кластера в течение тайм-аута, заданного при его регистрации, устройство, а значит, и элемент кластера будут считаться отказавшими. Это относится только к критическим устройствам с тайм-аутами. Если критическое устройство зарегистрировано с параметром -t 0, то тайм-аута не будет? и, если устройство не сообщит иное, состояние устройства будет считаться соответствующим последнему сообщению.

Пример скрипта cphaprob Предопределенные скрипты cphaprob расположены в $FWDIR/bin. Таких скрипта два:

clusterXL_monitor_ips

clusterXL_monitor_process

Скрипт clusterXL_monitor_ips, подробно рассматриваемый в главе "Пример скрипта cphaprob" приложения (на стр. 106), предназначен для проверки возможности сквозного соединениям с маршрутизаторами или другими сетевыми устройствами и выполнения аварийного переключения в случае проблемы с соединением. Скрипт clusterXL_monitor_process контролирует наличие данных процессов и вызывает аварийное переключение в случае их затухания. В этом скрипте используется обычный

механизм pnote.

Мониторинг состояния кластера с помощью клиентов SmartConsole

SmartView Monitor SmartView Monitor отображает снапшоты всех элементов кластера ClusterXL на предприятии, обеспечивая возможность мониторинга и оповещения в реальном времени. По каждому элементу кластера отображаются уведомления об изменении состояния и проблемах критических устройств. SmartView Monitor позволяет определить действие, выполняемое в случае изменения состояния элемента кластера. Например, шлюз безопасности может направить вам предупреждение о подозрительной активности.

Запуск и выключение ClusterXL с помощью SmartView Monitor Чтобы выключить ClusterXL на данной машине с аварийным переключением на другую машину, откройте SmartView Monitor, щелкните по объекту-кластеру, выберите одну из ветвей элемента-шлюза, щелкните правой кнопкой мыши по элементу кластера и выберите Down (Выключить).

Чтобы запустить или перезапустить ClusterXL, откройте SmartView Monitor, щелкните по объекту-кластеру, выберите одну из ветвей элемента-шлюза, щелкните правой кнопкой мыши по элементу кластера и выберите Up (Включить).

Примечание: SmartView Monitor не инициирует полную синхронизацию, поэтому некоторые соединения могут быть потеряны. Чтобы инициировать полную синхронизацию, выполните команду cpstart.



SmartView Tracker Каждое изменения в состоянии элемента кластера фиксируется в SmartView Tracker в зависимости от настройки опции Fail-Over Tracking (Отслеживание аварийных переключений) на странице ClusterXL объекта-кластера.

Сообщения журналов регистрации ClusterXL В этом разделе используются следующие условные обозначения:

1. Квадратные скобки используются для обозначения заполнителей, которые заменяются соответствующими данными при выдаче фактического сообщения журнала регистрации (например, [NUMBER] заменяется числовым значением).

2. Угловые скобки используются для обозначения вариантов, один из которых будет использоваться в фактических сообщениях журналов регистрации. Варианты отделяются друг от друга вертикальной линией (например, <up|down> означает, что будет использоваться либо "up", либо "down").

3. Наиболее распространенными заполнителями являются:

ID: Уникальный идентификатор элемента кластера начиная с "1". Он соответствует порядку, в котором отсортированы элементы на графическом пользовательском интерфейсе объекта-кластера.

IP: Любой уникальный IP-адрес, принадлежащий элементу.

MODE: Режим кластера (например, New HA, LS Multicast и пр.).

STATE: Состояние элемента (например, активный, не работает, резервный).

DEVICE: Имя устройства pnote (например, fwd, Interface Active Check).

Общие журналы регистрации

Starting <ClusterXL|State Synchronization>.

Означает, что ClusterXL (или State Synchronization в случае со сторонними кластерами) успешно запущен на элементе, отправляющем сообщение. Это сообщение обычно выдается после загрузки элемента или

явного вызова команды cphastart.

Stopping <ClusterXL|State Synchronization>.

Сообщает о том, что ClusterXL (или State Synchronization) на данной машине выключен. Машина больше не будет элементом кластера (даже если она должна им быть согласно настройкам), пока ClusterXL не будет перезапущен.

Unconfigured cluster Machines changed their MAC Addresses. Please reboot the cluster

so that the changes take affect. (У ненастроенных машин кластера изменились MAC-

адреса. Перезагрузите кластер, чтобы изменения вступили в силу.)

Это сообщение обычно выдается после выключения машины или явного вызова команды cphastop.

Журналы регистрации состояний

Mode inconsistency detected: member [ID] ([IP]) will change its mode to [MODE].

Please re-install the security policy on the cluster. (Обнаружено несоответствие

режимов: режим элемента [ID] ([IP]) будет изменен на [MODE]. Установите заново

политику безопасности на кластере.)

Это сообщение должно появляться редко. Оно означает, что еще один элемент кластера сообщил о режиме кластера, отличном от режима, известного локальному элементу. Обычно это происходит, если политика безопасности не была установлена на всех элементах кластера. Для устранения этой проблемы еще раз установите политику безопасности.

Примечание: кластер продолжит работать после обнаружения несоответствия

режимов, изменив режим машины, отправившей сообщение, на режим других элементов кластера. Несмотря на это, настоятельно рекомендуется как можно скорее установить политику заново.

State change of member [ID] ([IP]) from [STATE] to [STATE] was cancelled, since all

other members are down. Member remains [STATE]. (Изменение состояния элемента [ID]

([IP]) с [STATE] на [STATE] было отменено, так как все другие элементы не работают.

Элемент остается в состоянии [STATE].)

Когда элементу необходимо изменить свое состояние (например, когда активный элемент сталкивается с проблемой и должен отключиться), сначала он посылает запросы другим элементам об их состоянии. Если все другие элементы отключены, данный элемент не может изменить свое состояние на неактивное (иначе все элементы окажутся неактивными, и кластер не будет работать). Поэтому элемент, отправивший данное сообщение, продолжает работать, несмотря на свою проблему (и, как правило, сообщит о том, что находится в состоянии "Внимание").

member [ID] ([IP]) <is active|is down|is stand-by|is initializing> ([REASON]).



Это сообщение выдается при каждом изменении состояния элемента кластера. Новое состояние элемента указано в тексте журнала регистрации.

Журналы регистрации Pnote

Сообщения журналов регистрации PNote выдаются при изменении состояния устройства pnote.

[DEVICE] on member [ID] ([IP]) status OK ([REASON]).

Устройство pnote работает исправно.

[DEVICE] on member [ID] ([IP]) detected a problem ([REASON]).

Либо само устройство pnote обнаружило ошибку, либо устройство не сообщило о своем состоянии в течение заданного тайм-аута в секундах (определенного опцией "timeout" устройства pnote).

[DEVICE] on member [ID] ([IP]) is initializing ([REASON]).

Означает, что устройство зарегистрировалось с использованием механизма pnote, но еще не определило свое состояние.

[DEVICE] on member [ID] ([IP]) is in an unknown state ([STATE ID]) ([REASON]).

Означает, что устройство находится в неизвестном состоянии. Это сообщение не должно появляться при нормальной работе. Обратитесь в службу поддержки Check Point.

Журналы регистрации интерфейсов

interface [INTERFACE NAME] of member [ID] ([IP]) is up.

Означает, что данный интерфейс работает исправно, т.е. он способен получать и передавать пакеты в нужной подсети.

interface [INTERFACE NAME] of member [ID] ([IP]) is down (receive <up|down>, transmit <up|down>).

Это сообщение выдается каждый раз, когда интерфейс сталкивается с проблемой либо при получении, либо при передаче пакетов. Обратите внимание, что в этом случае интерфейс может продолжать исправно работать в том, что касается ОС, но он не способен связаться с другими элементами кластера из-за неверной конфигурации кластера.

interface [INTERFACE NAME] of member [ID] ([IP]) was added.

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

сообщение появляется в результате активации интерфейса (например, при выдаче команды ifconfig

up в системах Unix). Теперь интерфейс будет включаться в отчеты ClusterXL (например, в SmartView

Monitor или выводе команды cphaprob -a if). Обратите внимание, что в отчетах интерфейс может

все еще значиться как "Disconnected" (Отключенный), если так настроен для ClusterXL.

interface [INTERFACE NAME] of member [ID] ([IP}) was removed.

Означает, что интерфейс был отсоединен от шлюза безопасности и потому больше не контролируется кластером ClusterXL.

Журналы регистрации SecureXL

SecureXL device was deactivated since it does not support CPLS. (Устройство SecureXL было выключено, поскольку оно не поддерживает CPLS.)

Это сообщение появляется в результате попытки конфигурирования ClusterXL в режиме Load Sharing Multicast на шлюзах безопасности с использованием ускорителя, который не поддерживает распределение нагрузки. При этом ускоритель будет выключен, но кластер будет работать в режиме Check Point Load Sharing (CPLS).

Строки, содержащие причины сообщений

member [ID] ([IP]) reports more interfaces up. (Элемент [ID] ([IP]) сообщает о большем количестве рабочих интерфейсов.)

Этот текст может быть включен в сообщение журнала регистрации pnote c указанием причин сообщения о проблеме: согласно отчетам, у другого элемента больше рабочих интерфейсов, чем у локального элемента. Это означает, что у локального элемента есть неисправный интерфейс и другой элемент может лучше него выполнять функции элемента кластера.

Поэтому локальный элемент перестанет работать, а обработка трафика будет осуществляться элементом, указанным в сообщении.

member [ID] ([IP]) has more interfaces - check your disconnected interfaces configuration in the <discntd.if file|registry>. (У элемента [ID] ([IP]) больше интерфейсов — проверьте конфигурацию отключенных интерфейсов в <discntd.if file|registry>.)

Это сообщение выдается, когда у элементов одного и того же кластера имеется разное количество интерфейсов. При этом элемент с меньшим количеством интерфейсов, чем максимальное количество в кластере (у элемента, отправившего сообщение), может быть неисправен, так как у него не хватает



интерфейса, необходимого для работы с IP-адресом кластера или с сетью синхронизации. Если некоторые интерфейсы другого элемента кластера являются резервными и не должны контролироваться кластером ClusterXL, то их необходимо явно обозначить как "Disconnected" (Отключенные). Для этого используется файл $FWDIR/conf/discntd.if (в системах Unix) или системный реестр Windows.

[NUMBER] interfaces required, only [NUMBER] up. (Требуется [КОЛИЧЕСТВО] интерфейсов, только больше [КОЛИЧЕСТВО].)

ClusterXL обнаружил проблему с одним или несколькими контролируемыми интерфейсами. Это необязательно означает, что элемент выйдет из строя, так как у других элементов может быть меньше работоспособных интерфейсов. В такой ситуации в работе останется элемент с наибольшим количеством работоспособных интерфейсов, а другие выйдут из строя.

Команды конфигурирования ClusterXL

Команда cphaconf Описание Команда cphaconf конфигурирует ClusterXL.

Важно: выполнять эту команду не рекомендуется. Она должна выполняться

автоматически только шлюзом безопасности или службой поддержки Check Point. Единственным исключением из этого правила является выполнение команды с

опцией set_cpp так, как описано ниже.

Использование

Синтаксис

Параметр Описание

set_ccp

<broadcast/multicast>

Устанавливает, должны ли пакеты протокола управления кластером (CCP) отправляться с широковещательным или групповым MAC-адресом назначения. По умолчанию применяется групповой адрес. Настройка, созданная с использованием этой команды, сохраняется после перезагрузки.

Обратите внимание, что такое же значение (широковещательный или групповой адрес) должно быть установлено на всех элементах кластера.

stop_all_vs Останавливает кластерный продукт во всех виртуальных системах на шлюзе VSX.

Команды cphastart и cphastop При выполнении на элементе кластера команды cphastart на этом элементе активируется ClusterXL. Команда не инициирует полную синхронизацию. Использование команды cpstart является рекомендуемым способом запуска элемента кластера.

При выполнении на элементе кластера команды cphastop прекращается передача трафика элементом кластера. Синхронизация состояний также прекращается. При этом все еще возможно открывать прямые соединения с элементом кластера. В режиме High Availability Legacy выполнение команды cphastop может привести к прекращению работы всего кластера.



Эти команды должны выполняться не непосредственно пользователем, а только шлюзом безопасности.

Как инициировать аварийное переключение Вы можете вручную управлять состоянием элемента кластера с целью вывода элемента кластера из строя. В случае с Load Sharing это инициирует аварийное переключение на один или несколько других элементов кластера, а в случае с High Availability — на элемент кластера с самым высоким приоритетом из оставшихся элементов.

Выключение элемента кластера Для выключения кластера ClusterXL на машине и осуществления аварийного переключения на другую машину:

1. Зарегистрируйте фиктивное критическое устройство (например, faildevice) с помощью команды cphaprob -d faildevice - t 0 -s ok register.

2. Затем выполните следующую команду, чтобы сообщить кластеру ClusterXL о том, что у критического устройства faildevice есть проблема: cphaprob -d faildevice -s problem report. Это приведет к немедленному аварийному переключению на элемент кластера.

Другой способ:

1. Откройте SmartView Monitor и щелкните по объекту-кластеру.

2. Выберите одну из ветвей элемента-шлюза.

3. Щелкните правой кнопкой мыши по элементу кластера и выберите Down (Выключить).

Запуск элемента кластера Запуск ClusterXL осуществляется автоматически при запуске шлюза безопасности на элементе кластера (cpstart).

Для повторного запуска ClusterXL:

Если элемент кластера был выведен из строя по команде cphaprob -d faildevice -s problem report,

выполните любую из следующих команд:

cphaprob -d faildevice -s ok report

cphaprob -d faildevice unregister

Как вариант:

1. Откройте SmartView Monitor и щелкните по объекту-кластеру.

2. Выберите ветвь элемента-шлюза, обозначенного как "Down".

3. Щелкните правой кнопкой мыши по этому элементу кластера и выберите Up (Включить).

Примечание: запуск элемента кластера из SmartView Monitor не инициирует полную синхронизацию, поэтому некоторые соединения могут быть потеряны. Чтобы инициировать полную синхронизацию, выполните команду cpstart.

Мониторинг синхронизации (fw ctl pstat) Для мониторинга механизма синхронизации на кластере ClusterXL или сторонних продуктах кластеризации, имеющих сертификат OPSEC:

Выполните эту команду на элементе кластера: fw ctl pstat

Вывод этой команды представляет собой длинный список статистических данных по шлюзу безопасности. В конце списка для каждого элемента кластера шлюзов есть раздел под названием "Synchronization" (Синхронизация). Многие статистические данные представляют собой счетчики, которые могут только увеличиваться. Типичный вывод имеет следующий вид:



total (всего): 3976, retransmitted (передано повторно): 0, retrans reqs

(запросы на повторную передачу): 58, acks (подтверждения): 97

Sync packets received (Полученные пакеты синхронизации):

total (всего): 4290, were queued (поставлено в очередь): 58, dropped by net

(сброшено сетью): 47

retrans reqs (запросы на повторную передачу): 0, received (получено) 0 acks

(подтверждения)

retrans reqs for illegal seq (запросы на повторную передачу некорректной

последовательности): 0

Callback statistics (Статистика обратных вызовов): handled 3 cb (обработано 3

обратных вызова), average delay (средняя задержка): 1, max delay (максимальная

задержка): 2

Delta Sync memory usage (Использование памяти Delta Sync): currently using XX KB

mem (в данное момент использует ХХ КБ памяти)




Number of Pending packets currently held (Количество ожидающих пакетов,

удерживаемых в данный момент): 1

Packets released due to timeout (Пакеты, выпущенные в результате тайм-аута): 18

Значение каждой строки в этой распечатке подробно рассматривается далее.

Version: new (Версия: новая)

Эта строка должна появиться, если настроена синхронизация. Она означает, что новая синхронизация

работает (в отличие от прежней синхронизации из версии 4.1).

Status: Able to Send/Receive sync packets (Состояние: способен отправлять/получать

пакеты синхронизации)

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

При загрузке возможна временная неспособность отправлять или получать пакеты, но этого не должно

быть при нормальной работе. При выполнении полной синхронизации получение пакетов синхронизации

может быть прервано.

Sync packets sent: (Отправленные пакеты синхронизации)

total (всего): 3976, retransmitted (передано повторно): 0, retrans reqs (запросы

на повторную передачу): 58, acks (подтверждения): 97

Первым отображается общее количество отправленных пакетов синхронизации. Обратите внимание, что

общее количество пакетов синхронизации не равно нулю и увеличивается.

При получении пакета синхронизации с изменением последовательности элемент кластера отправляет

запрос на повторную передачу. При нагрузке это число может увеличиваться.

Acks означает подтверждения, отправляемые в ответ на полученные пакеты синхронизации, если

подтверждение было запрошено другим элементом кластера.

Sync packets received (Полученные пакеты синхронизации):

total (всего): 4290, were queued (поставлено в очередь): 58, dropped by net

(сброшено сетью): 47

Первым отображается общее количество полученных пакетов синхронизации. Количество пакетов,

поставленных в очередь, увеличивается при получении пакета синхронизации, соответствующего одному

из следующих условий:

1. Получен пакет синхронизации с порядковым номером, не следующим за номером предыдущего

обработанного пакета синхронизации.

2. Пакет синхронизации фрагментирован. Это делается для устранения ограничений по максимальному

размеру пакета.

Эти число никогда не уменьшается. Любое значение, кроме нуля, не означает проблему.

Количество dropped by net (сброшено сетью) может означать перегрузку сети. При нагрузке это число

может медленно увеличиваться. Если это число увеличивается слишком быстро, возможно, протоколу

синхронизации мешает сетевая ошибка. В этом случае проверьте сеть.

retrans reqs (запросы на повторную передачу): 0, received (получено) 0 acks

(подтверждения)

retrans reqs for illegal seq (запросы на повторную передачу некорректной

последовательности): 0




Это сообщение отражает количество полученных запросов на повторную передачу, в отличие от переданных

запросов на повторную передачу, рассмотренных выше. Когда это число увеличивается очень быстро, это

может означать, что нагрузка на машину становится слишком высокой для обработки с синхронизацией. Acks означает количество подтверждений, полученных в ответ на пакеты синхронизации "cb request",

которые являются пакетами синхронизации с запросами на подтверждения.



Retrans reqs for illegal seq отображает количество запросов на повторную передачу пакетов, которые

больше не принадлежат этому элементу. Это может означать проблему синхронизации.

Callback statistics отражает полученные пакеты c последовательностью "Flush and Ack" (передача и подтверждение). Эта статистика отображается, только если значение не равно нулю.

Параметр average delay (средняя задержка) обратного вызова показывает, на какое время был задержан пакет на этом элементе, прежде чем был выпущен, когда элемент получил подтверждение ото всех других элементов. Задержка происходит потому, что пакеты удерживаются, пока все другие элементы кластера не подтвердят получение данного пакета синхронизации.

Это число выражается в пакетах. При нормальной работе оно должно быть небольшим (~1-5). Большее число может свидетельствовать о перегрузке по трафику синхронизации, в результате чего появляются соединения c небольшой задержкой подтверждений синхронизации.

dropped updates as a result of sync overload (обновления, сброшенные в результате

перегрузки по синхронизации): 0

В сильно загруженной системе элемент кластера может сбрасывать обновления синхронизации, отправляемые с другого элемента кластера.

Delta Sync memory usage (Использование памяти Delta Sync): currently using XX KB

mem (в данное момент использует ХХ КБ памяти)

Delta Sync memory usage отображается, только если значение не равно нулю. Delta sync (дельта-

синхронизация) использует память только во время осуществления полной синхронизации. Полная синхронизация происходит, когда система включается в работу, например, после перезагрузки. В остальное время Delta sync не требует памяти, потому что обновления Delta sync применяются немедленно. Информацию о дельта-синхронизации см. в разделе "Как работает синхронизация состояний" (на стр. 13).

Number of Pending packets currently held (Количество ожидающих пакетов,

удерживаемых в данный момент): 1

Packets released due to timeout (Пакеты, выпущенные в результате тайм-аута): 18

Number of Pending packets currently held отображается, только если значение не равно нулю. ClusterXL не пропускает пакеты, не соответствующие таблице состояний, в соединениях без привязки. Для этого он удерживает пакеты, пока не будет получено подтверждение синхронизации ото всех других активных элементов кластера. Если по какой-то причине подтверждение синхронизации не получено, шлюз безопасности на элементе кластера не выпустит пакет и соединение не будет установлено.

Packets released due to timeout отображается, только если значение не равно нулю. Если ожидающих

пакетов много (более 100 ожидающих пакетов), а число пакетов, выпущенных в результате тайм-

аута, мало, следует принять меры, чтобы уменьшить количество ожидающих пакетов. Решение этой

проблемы см. в разделе "Уменьшение количества ожидающих пакетов" (на стр. 89).

Диагностика проблем синхронизации О команде cphaprob [-reset] syncstat Сильно нагруженные кластеры и кластеры с географически удаленными элементами представляют особые трудности. Высокие скорости соединения и большие расстояния между элементами могут приводить к задержкам, влияющим на работу кластера.

Команда cphaprob [-reset] syncstat — это инструмент для мониторинга работы механизма синхронизации состояний в кластерах с высокой нагрузкой и географическим разделением. Его можно использовать как для ClusterXL, так и для сторонних продуктов кластеризации, имеющих сертификат OPSEC.

Процесс диагностики осуществляется в следующем порядке:

1. Выполните команду cphaprob syncstat.

2. Прочитайте выходную статистику.

3. Настройте соответствующие параметры общей конфигурации синхронизации.

4. Повторно выполните команду, переустановив счетчики статистики с помощью опции -reset:

cphaprob -reset syncstat

5. Проверьте выходную статистику, чтобы узнать, устранена ли проблема.

В разделе "Вывод команды cphaprob [-reset] syncstat" (на стр. 59) представлен каждый из параметров вывода с указанием того, когда вывод представляет проблему.

Любую выявленную проблему можно устранить, выполнив одну или несколько рекомендаций, приведенных в разделе "Опции диагностики проблем синхронизации" (на стр. 65).



Вывод команды cphaprob [-reset] syncstat Ниже представлен список параметров вывода команды cphaprob syncstat. Их значения (нет в списке) дают представление о состоянии и характеристиках сети синхронизации. Каждый параметр и смысл его возможных значений подробно рассматриваются в следующих разделах.

Параметры:

Sync Statistics (IDs of F&A Peers - 1) —Статистика синхронизации (Идентификаторы равноправных узлов F&A - 1) 59 Other Member Updates — Обновления других элементов 59 Sent Retransmission Requests — Отправленные запросы на повторную передачу 59 Avg |Missing Updates per Request — Среднее количество обновлений | Пропущенные обновления на запрос 60 Old or too-new Arriving Updates — Старые или преждевременно поступающие обновления 60 Unsynced Missing Updates — Несинхронизированные пропущенные обновления 60 Lost Sync Connection (num of events) — Потерянное соединение синхронизации (количество событий) 60 Timed out Sync Connection — Соединение синхронизации с истекшим тайм-аутом 61 Local Updates — Локальные обновления 61 Total Generated Updates — Общее количество сгенерированных обновлений 61 Recv Retransmission requests — Полученные запросы на повторную передачу 61 Recv Duplicate Retrans request — Полученные дубликаты запросов на повторную передачу 61 Blocking Scenarios — Сценарии блокировки 62 Blocked Packets — Заблокированные пакеты 62 Max Length of Sending Queue — Максимальная длина очереди на отправку 62 Avg Length of Sending Queue — Средняя длина очереди на отправку 63 Hold Pkts Events — События с удержанием пакетов 63 Unhold Pkt Events — События с отменой удержания пакетов 63 Not Held Due to no Members — Не удержано в связи с отсутствием элементов 64 Max Held Duration (ticks) — Максимальное время удержания (такты) 64 Avg Held Duration (ticks) — Среднее время удержания (такты) 64 Timers — Таймеры 64 Sync tick (ms) — Такт синхронизации (мс) 64 CPHA tick (ms) — Такт CPHA (мс) 65 Queues — Очереди 65 Sending Queue Size — Размер очереди на отправку 65 Receiving Queue Size — Размер очереди на получение 65

Sync Statistics (IDs of F&A Peers - 1) — Статистика синхронизации (Идентификаторы равноправных узлов F&A) Эта статистика относится к механизму синхронизации состояний. Равноправные узлы F&A (Flush and Ack — передача и подтверждение) — это элементы кластера, которые данный элемент признает частью кластера. Идентификаторы соответствуют идентификаторам и IP-адресам, сгенерированным командой cphaprob state.

Other Member Updates — Обновления других элементов Статистика этого раздела отражает обновления, сгенерированные другими элементами кластера, или обновления, не полученные от других элементов. Обновления сообщают об изменениях в соединениях, обрабатываемых элементом кластера, и отправляются от элементов и на них. Идентификация обновлений осуществляется по порядковому номеру.

Sent Retransmission Requests — Отправленные запросы на повторную передачу Количество запросов на повторную передачу, отправленных данным элементом. Запросы на повторную передачу отправляются тогда, когда некоторые пакеты (с указанным порядковым номером) отсутствуют, а элемент-отправитель уже получил обновления с более высокими порядковыми номерами. Высокое значение этого параметра может означать проблемы со связью.



Примечание: сравните количество запросов на повторную передачу с общим

количеством повторно сгенерированных обновлений других элементов (см. "Общее количество сгенерированных обновлений" (на стр. 61)).

Если его значение неоправданно велико (более 30% от общего количества сгенерированных обновлений других элементов), обратитесь в службу технической поддержки с полным текстом вывода и подробным описанием сетевой топологии и конфигурации.

Avg | Missing Updates per Request — Среднее количество обновлений | Пропущенные обновления на запрос Каждый запрос на повторную передачу может содержать до 32 пропущенных последовательностей. Значение этого поля соответствует среднему количеству запрошенных последовательностей, приходящихся на один запрос на повторную передачу.

Если пропущено более 20 последовательностей на один такой запрос, это может означать проблемы со связью.

Примечание: если это значение неоправданно велико, обратитесь в службу

технической поддержки с полным текстом вывода и подробным описанием сетевой топологии и конфигурации.

Old or too-new Arriving Updates — Старые или преждевременно поступающие обновления Количество поступающих обновлений синхронизации со слишком низким порядковым номером, означающим, что он относится к старой передаче, или со слишком высоким номером, который не может относиться к новой передаче.

Высокие значения означают проблемы со связью.

Примечание: см. "Увеличение очереди на получение" (на стр. 65). Если это

значение неоправданно велико (более 10% от общего количества отправленных обновлений), обратитесь в службу технической поддержки с полным текстом вывода и подробным описанием сетевой топологии и конфигурации.

Unsynced Missing Updates — Несинхронизированные пропущенные обновления Количество пропущенных обновлений синхронизации, которые элемент-получатель перестал ожидать. Он перестает ожидать обновления, когда разница в порядковых номерах между вновь поступающими обновлениями и пропущенными обновлениями превышает длину очереди на получение.

Это значение должно быть равно нулю. При этом потеря некоторых обновлений допустима, но количество потерянных обновлений должно быть менее 1% от общего количества сгенерированных обновлений.

Примечание: чтобы уменьшить количество потерянных обновлений, следует

увеличить вместимость очереди на получение. См. "Увеличение очереди на получение" (на стр. 65).

Lost Sync Connection (num of events) — Потерянное соединение синхронизации (количество событий) Количество событий, когда синхронизация с другим элементом была потеряна и восстановлена либо в связи с установкой политики безопасности на другом элементе, либо из-за большой разницы между ожидаемым и полученным порядковым номером.

Это значение должно быть равно нулю. Положительное значение означает проблемы со связью.



Примечание: разрешите механизму синхронизации обрабатывать соединения с

большой разницей в порядковых номерах, увеличив вместимость очереди на получение. См. "Увеличение очереди на получение" (на стр. 65).

Timed out Sync Connection — Соединение синхронизации с истекшим тайм-аутом Количество событий, когда элемент объявляет другой элемент неподключенным. Элемент считается отключенным, потому что в течение определенного времени (одной секунды) от этого элемента не было получено ни одного пакета ACK, несмотря на то что для этого элемента удерживаются пакеты Flush and Ack (передача и подтверждение).

Это значение должно быть равно нулю. Даже если время на передачу и подтверждение в сети синхронизации составляет 100 мс, одной секунды должно быть достаточно для получения ACK. Положительное значение означает проблемы со связью.

Примечание: попробуйте увеличить таймер синхронизации (см. "Увеличение

таймера синхронизации" (на стр. 66)). Однако, возможно, вам придется обратиться в службу технической поддержки с полным текстом вывода и подробным описанием сетевой топологии и конфигурации.

Local Updates — Локальные обновления Статистика этого раздела отражает обновления, сгенерированные локальным элементом кластера. Обновления сообщают об изменениях в соединениях, обрабатываемых элементом кластера, и отправляются от элементов и на них. Идентификация обновлений осуществляется по порядковому номеру.

Total Generated Updates — Общее количество сгенерированных обновлений

Количество пакетов обновления синхронизации, сгенерированных механизмом синхронизации с момента последнего сброса статистики. Его значение равно разнице между порядковым номером при применении опции -reset и текущим порядковым номером.

Это может быть любое значение.

Recv Retransmission requests — Полученные запросы на повторную передачу

Количество полученных пакетов на повторную передачу. Элемент делает запрос на повторную передачу, когда ему не хватает определенных пакетов с более низкими порядковыми номерами, чем у уже полученных пакетов.

Большое значение может означать проблемы со связью.

Примечание: если его значение неоправданно велико (более 30% от общего количества сгенерированных обновлений), обратитесь в службу технической поддержки с полным текстом вывода и подробным описанием сетевой топологии и конфигурации.

Recv Duplicate Retrans request — Полученные дубликаты запросов на повторную передачу

Количество дубликатов запросов на повторную передачу, полученных элементом. Дубликаты запросов уже были обработаны и потому сбрасываются.

Большое значение может означать сетевую проблему или наличие штормов в сети синхронизации.

Примечание: если его значение неоправданно велико (более 30% от общего количества сгенерированных обновлений), обратитесь в службу технической поддержки с полным текстом вывода и подробным описанием сетевой топологии и конфигурации.



Blocking Scenarios — Сценарии блокировки В условиях чрезмерно высокой нагрузки кластер может блокировать новые соединения. Этот параметр показывает, сколько раз элемент кластера начинал блокировку новых соединений в связи с перезагрузкой по синхронизации.

Элемент начинает блокировать соединения, когда его очередь на отправку достигла своего порога вместимости. Порог вместимости рассчитывается в размере 80% от разницы между текущим порядковым номером и порядковым номером, для которого элемент получил подтверждение ото всех других работающих элементов.

Положительное значение означает высокую нагрузку. В этом случае проверьте значение Blocked Packets (Заблокированные пакеты), чтобы узнать, сколько пакетов было заблокировано. Каждый сброшенный пакет означает одно заблокированное соединение.

Этот параметр измеряется, только если активен механизм блокировки новых соединений Block New Connections (описываемый в разделе "Блокировка новых соединений при нагрузке" (на стр. 88)).

Для активации механизма блокировки новых соединений:

Примените команду fw ctl set int fw_sync_block_new_conns 0 ко всем элементам кластера.

Примечание: лучшим способом решения проблемы блокировки соединений является увеличение очереди на отправку. См. "Увеличение очереди на отправку" (на стр. 65).

Другой вариант — уменьшение тайм-аута, после которого элемент инициирует подтверждение. См. "Переконфигурирование тайм-аута подтверждения" (на стр. 66). Это позволяет изменить вместимость очереди на отправку с большей точностью и тем самым сделать процесс блокировки более точным.

Blocked Packets — Заблокированные пакеты Количество пакетов, которые были заблокированы, потому что элемент кластера блокировал все новые соединения (см. "Сценарии блокировки"). Количество заблокированных соединений обычно составляет один пакет на одну попытку нового соединения.

Если это значение превышает 5% от очереди на отправку (см. "Средняя длина очереди на отправку" (на стр. 63)), это может означать проблему со связью или то, что отправка подтверждений выполняется недостаточно часто.



Примените команду fw ctl set int fw_sync_block_new_conns 0 на всех элементах кластера.

Примечание: лучшим способом решения проблемы блокировки соединений является увеличение очереди на отправку. См. "Увеличение очереди на отправку" (см. "Увеличение таймера синхронизации" (на стр. 66)).

Другой вариант — уменьшение тайм-аута, после которого элемент инициирует подтверждение. См. "Изменение настройки тайм-аута подтверждения" (на стр. 66). Это позволяет изменить вместимость очереди на отправку с большей точностью и тем самым сделать процесс блокировки более точным.

Max Length of Sending Queue — Максимальная длина очереди на отправку Размер очереди на отправку является фиксированным. По умолчанию он составляет 512 обновлений синхронизации. Когда более новые обновления с более высокими порядковыми номерами поступают в очередь, более старые обновления с более низкими порядковыми номерами сбрасываются с конца очереди. Более старое обновление может быть удалено из очереди, прежде чем элемент получит подтверждение об этом обновлении ото всех других элементов.

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



Значение этого параметра должно быть меньше 512. Если оно больше 512, это необязательно означает проблему синхронизации. Однако элемент не сможет ответить на запрос на повторную передачу обновлений, которые больше не находятся в его очереди.

Этот параметр измеряется, только если активен механизм блокировки новых соединений Block New Connections (описываемый в разделе "Блокировка новых соединений" (на стр. 88)).



Примечание: увеличьте очередь на отправку так, чтобы ее значение было больше этого значения. См. "Увеличение очереди на отправку" (на стр. 65).

Avg Length of Sending Queue — Средняя длина очереди на отправку Среднее значение параметра Max Length of Sending Queue (Максимальная длина очереди на отправку) с момента перезагрузки или сброса статистики синхронизации.

Оно должно составлять до 80% от размера очереди на отправку.




Примечание: увеличьте очередь на отправку так, чтобы это значение не превышало 80% от нового размера очереди. См. "Увеличение очереди на отправку" (на стр. 65).

Hold Pkts Events — События с удержанием пакетов Количество случаев, когда обновление синхронизации потребовало Flush and Ack (передачи и подтверждения) и потому оставалось в системе, пока не поступило подтверждение ото всех других функционирующих элементов.

Оно должно быть равно значению параметра Unhold Pkt Events (События с отменой удержания пакетов).

Примечание: Обратитесь в службу технической поддержки с полным текстом вывода и подробным описанием сетевой топологии и конфигурации.

Unhold Pkt Events — События с отменой удержания пакетов Количество случаев, когда элемент получил все требуемые подтверждения от других функционирующих элементов.

Оно должно быть равно значению параметра Hold Pkt Events (События с удержанием пакетов).

Примечание: Обратитесь в службу технической поддержки с полным текстом вывода и подробным описанием сетевой топологии и конфигурации.



Not Held Due to no Members — Не удержано в связи с отсутствием элементов Количество пакетов, которые должны были остаться в системе, но были выпущены, потому что не оказалось других работающих элементов.

Когда в кластере есть хотя бы два работающих элемента, значение должно быть равно 0.

Примечание: у кластера проблема со связью. Проверьте значения параметров Lost Sync Connection (num of events) (на стр. 60) и Timed out Sync Connection (на стр. 61), чтобы узнать, почему элемент считает себя единственным элементом кластера.

Возможно, вам также придется обратиться в службу технической поддержки с полным текстом вывода и подробным описанием сетевой топологии и конфигурации.

Max Held Duration (ticks) — Максимальное время удержания (такты) Максимальное время в тактах, или тиках (один такт равен 100 мс), в течение которого пакет был задержан в системе для целей Flush and Ack.

Оно не должно быть больше 50 (5 секунд) из-за механизма тайм-аута, который выпускает удерживаемые пакеты по истечении определенного тайм-аута. По умолчанию тайм-аут разблокировки составляет 50 тактов. Большое значение означает проблему со связью между элементами.

Примечание: по желанию вы можете изменить тайм-аут по умолчанию, изменив значение глобальной переменной fwldbcast_pending_timeout. См. "Дополнительное конфигурирование кластера" (на стр. 86) и "Уменьшение количества ожидающих пакетов" (на стр. 89).

Кроме того, проверьте параметр Timed out Sync Connection (на стр. 61), чтобы понять, почему пакеты были удержаны в течение долгого времени.

Возможно, вам также придется обратиться в службу технической поддержки с полным текстом вывода и подробным описанием сетевой топологии и конфигурации.

Avg Held Duration (ticks) — Среднее время удержания (такты) Среднее время в тактах, или тиках (такт равен 100 мс), в течение которого пакеты были задержаны в системе для целей Flush and Ack.

Среднее время должно быть примерно равно времени на передачу и подтверждение в сети синхронизации. Большее значение означает проблемы со связью.

Примечание: если это значение велико, обратитесь в службу технической

поддержки с полным текстом вывода и подробным описанием сетевой топологии и конфигурации, чтобы изучить причину проблемы.

Timers — Таймеры Таймеры синхронизации и CPHA выполняют действия, связанные с синхронизацией и кластером, через фиксированный интервал.

Sync tick (ms) — Такт синхронизации (мс) Таймер синхронизации выполняет действия, связанные с кластером, через фиксированный интервал. По умолчанию интервал таймера синхронизации составляет 100 мс. Базовая единица времени составляет 100 мс (или 1 такт), которая также является минимальным значением.



CPHA tick (ms) — Такт CPHA (мс) Таймер CPHA выполняет действия, связанные с кластером, через фиксированный интервал. По умолчанию интервал таймера CPHA составляет 100 мс. Базовая единица времени составляет 100 мс (или 1 такт), которая также является минимальным значением.

Queues — Очереди У каждого элемента кластера есть две очереди: очередь на отправку и очередь на получение.

Sending Queue Size — Размер очереди на отправку В очереди на отправку, находящейся на элементе кластера, хранятся локально сгенерированные обновления синхронизации. Обновления в очереди на отправку заменяются более поздними обновлениями. Поэтому в кластере с высокой нагрузкой обновления хранятся меньше времени. Если элемент получил запрос на повторную передачу обновления, он может сделать это, только если обновление все еще находится в его очереди на отправку. По умолчанию (и минимальный) размер этой очереди равен 512. У каждого элемента есть одна очередь на отправку.

Receiving Queue Size — Размер очереди на получение В очереди на получение, находящейся на элементе кластера, обновления от каждого элемента кластера хранятся до тех пор, пока он не получит полную последовательность обновлений. По умолчанию (и минимальный) размер этой очереди равен 256. На каждом элементе есть очередь на получение для каждого из равноправных элементов.

Опции диагностики проблем синхронизации Ниже представлены доступные опции диагностики проблем. Каждая опция подразумевает изменение глобального системного настраиваемого параметра с целью переконфигурирования системы с заменой значения, заданного по умолчанию.

Увеличение очереди на отправку В очереди на отправку, находящейся на элементе кластера, хранятся локально сгенерированные обновления синхронизации. Обновления в очереди на отправку заменяются более поздними обновлениями. Поэтому в кластере с высокой нагрузкой обновления хранятся меньше времени. Если элемент получил запрос на повторную передачу обновления, он может сделать это, только если обновление все еще находится в его очереди на отправку. По умолчанию (и минимальный) размер этой очереди равен 512. У каждого элемента есть одна очередь на отправку.

Для увеличения размера очереди на отправку:

1. Измените значение глобального параметра fw_sync_sending_queue_size. См. "Дополнительное конфигурирование кластера" (на стр. 86).

2. Вам также необходимо убедиться, что нужный размер очереди сохранится после перезагрузки. См. "Как сконфигурировать шлюз, чтобы настройки сохранялись после перезагрузки" (на стр. 87).

Увеличение этой очереди позволяет элементу хранить больше обновлений от других элементов. Однако учтите, что каждое сохраненное обновление потребляет память. При изменении этой переменной вам следует тщательно обдумать, как это повлияет на память. Изменения вступят в силу только после перезагрузки.

Увеличение очереди на получение В очереди на получение, находящейся на элементе кластера, обновления от каждого элемента кластера хранятся до тех пор, пока он не получит полную последовательность обновлений. По умолчанию (и минимальный) размер этой очереди равен 256. На каждом элементе есть очередь на получение для каждого из равноправных элементов.

Для увеличения размера очереди на получение:

1. Измените значение глобального параметра fw_sync_recv_queue_size. См. "Дополнительное конфигурирование кластера" (на стр. 86).

2. Вам также необходимо убедиться, что нужный размер очереди сохранится после перезагрузки. См. "Как сконфигурировать шлюз, чтобы настройки сохранялись после перезагрузки" (на стр. 87).

Увеличение этой очереди означает, что элемент сможет хранить больше обновлений от других элементов. Однако учтите, что каждое сохраненное обновление потребляет память. При изменении этой переменной вам следует тщательно обдумать, как это повлияет на память. Изменения вступят в силу только после перезагрузки.



Увеличение таймера синхронизации Таймер синхронизации выполняет действия, связанные с синхронизацией, через фиксированный интервал. По умолчанию интервал таймера синхронизации составляет 100 мс. Базовая единица времени составляет 100 мс (или 1 такт), она же является минимальным значением.

Для увеличения таймера синхронизации:

Измените значение глобального параметра fwha_timer_sync_res. См. "Дополнительное

конфигурирование кластера" (на стр. 86). Значение этой переменной можно изменять во время работы системы. Перезагрузка не требуется.

По умолчанию fwha_timer_sync_res имеет значение 1, т.е. таймер синхронизации срабатывает через каждую базовую единицу времени (каждые 100 мс). Если вы установите эту переменную на n, таймер будет срабатывать каждые n*100 мс.

Увеличение таймера CPHA Таймер CPHA выполняет действия, связанные с кластером, через фиксированный интервал. По умолчанию интервал таймера CPHA составляет 100 мс. Базовая единица времени составляет 100 мс (или 1 такт), которая также является минимальным значением.

Если элементы кластера географически удалены друг от друга, установите таймер CPHA на значение примерно в 10 раз больше задержки, требуемой на передачу и подтверждение в сети синхронизации.

Увеличение этого значения приводит к увеличению времени на обнаружение аварийного переключения. Например, если на обнаружение аварийного переключения интерфейса требуется 0,3 секунды и значение таймера было удвоено до 200 мс, то время, требуемое на обнаружение аварийного переключения интерфейса, также удваивается до 0,6 секунды.

Для увеличения таймера CPHA:

Измените значение глобального параметра fwha_timer_cpha_res. См. "Дополнительное конфигурирование кластера" (на стр. 86). Значение этой переменной можно изменять во время работы системы. Перезагрузка не требуется.

По умолчанию fwha_timer_cpha_res имеет значение 1, т.е. таймер CPHA срабатывает через каждую базовую единицу времени (каждые 100 мс). Если вы установите эту переменную на n, таймер будет срабатывать каждые n*100 мс.

Переконфигурирование тайм-аута подтверждения Элемент кластера регулярно удаляет обновления из своей очереди на отправку (см. "Размер очереди на отправку" (на стр. 65)) Благодаря этому освобождается место в очереди для более поздних обновлений.

Элемент кластера удаляет обновления из этой очереди, если он получает подтверждение об обновлении от равноправного элемента.

Равноправный элемент отправляет подтверждение в одной из двух ситуаций, при условии что механизм Block New Connections (рассматриваемый в разделе "Блокировка новых соединений при нагрузке" (на стр. 88)) активен:

После получения определенного количества обновлений.

Если он не отправлял подтверждения в течение определенного времени. Это важно, если в сети синхронизации существует значительная линейная задержка, которая может появиться, если элементы кластера географически удалены друг от друга.

Чтобы переконфигурировать тайм-аут, после которого элемент отправляет подтверждение:

Измените значение глобального параметра fw_sync_ack_time_gap. См. "Дополнительное конфигурирование кластера" (на стр. 86). Значение этой переменной можно изменять во время работы системы. Перезагрузка не требуется.

По умолчанию значение этой переменной составляет 10 тактов (10 * 100 мс). Таким образом, если элемент не отправил подтверждение за полную секунду, он отправит подтверждение для полученных им обновлений.

Обращение в службу технической поддержки Если другие рекомендации не помогают устранить проблему, обратитесь за помощью в службу технической поддержки.



Сообщения об ошибках ClusterXL В этом разделе приведен список сообщений об ошибках ClusterXL. О других, менее распространенных сообщениях об ошибках см. решение SecureKnowledge sk23642 (http://supportcontent.checkpoint.com/solutions?id=sk23642).

Общие сообщения об ошибках ClusterXL FW-1: changing local mode from <mode1> to <mode2> because of ID <machine_id> (изменение

локального режима с <режим 1> на <режим 2> из-за идентификатора <идентификатор_машины>) Это сообщение журнала регистрации может появиться, если элементы кластера работают в разных режимах, например, одна машина — в режиме High Availability, а другая — в режиме Load Sharing Multicast или Load Sharing Unicast. В этом случае внутренний механизм ClusterXL пытается синхронизировать конфигурацию элементов кластера, изменив режим работы на наименее распространенный. Режимы работы имеют следующие степени приоритетов (в порядке убывания): 1. Только Synchronization 2. Load Sharing 3. High Availability (Active Up) (Высокая доступность (с использованием активного элемента кластера)) 4. High Availability (Primary Up) (Высокая доступность (c использованием первичного элемента кластера)).

CPHA: Received confirmations from more machines than the cluster size (получены подтверждения от большего количества машин, чем входит в состав кластера) Это сообщение журнала регистрации может появиться при установке политики в кластере. Оно означает, что в данном кластере существует серьезная проблема конфигурации. Возможно, какой-то другой кластер был сконфигурирован с использованием идентичных параметров и оба из них имеют общие сети.

fwldbcast_timer: peer X probably stopped... (возможно, элемент Х прекратил работу...) Это сообщение появляется тогда, когда элемент, отправивший его на печать, перестает получать определенные типы сообщений от элемента X. С помощью команды cphaprob state проверьте, все ли сообщения активны, а с помощью команды fw ctl pstat, убедитесь, что синхронизация правильно настроена и исправно работает на всех элементах. В такой ситуации можно предположить, что возникла временная проблема со связью, которая была исправлена. Существует несколько соединений, которые могут испытать проблемы со связью из-за временной проблемы синхронизации между двумя данными элементами. С другой стороны, это может означать, что другой элемент действительно вышел из строя.

FW-1: fwha_notify_interface: there are more than 4 IPs on interface <interface name> notifying only the first ones (более 4 IP-адресов на интерфейсе <имя интерфейса>, отправляющем уведомления только на первые адреса) У элемента того же кластера, в состав которого входит машина, выдавшая сообщение, на одном и том же интерфейсе задано более трех виртуальных IP-адресов. Эта конфигурация не поддерживается и причинит вред функционалу ClusterXL.

Sync could not start because there is no sync license (Не удалось запустить синхронизацию из-за отсутствия лицензии на синхронизацию) Это сообщение об ошибке связано с лицензией: если у вас есть базовая лицензия на шлюз безопасности, то у вас автоматически есть лицензия на синхронизацию. Проверьте базовую лицензию на шлюз безопасности с помощью команд cplic print и cplic check.

FW-1: h_slink: an attempt to link to a link (попытка сослаться на ссылку) kbuf id not found (идентификатор kbuf не найден) fw_conn_post_inspect: fwconn_init_links failed Несколько проблем такого рода могут возникнуть во время сеанса полной синхронизации, когда в процессе полной синхронизации открываются и закрываются соединения. Полная синхронизация по возможности осуществляется автоматически, но она не полностью автоматизирована по соображениям производительности. Шлюз безопасности продолжает обрабатывать трафик, даже если он играет роль сервера полной синхронизации. Это может вызвать некоторые незначительные проблемы, такие как удаление одного соединения дважды, ссылка на существующую ссылку и т.п. Это не должно повлиять на возможность соединения или вызвать проблемы с безопасностью.

Error SEP_IKE_owner_outbound: other cluster member packet in outbound (пакет другого элемента кластера в исходящих) Кластер не синхронизирован. Обычно случается в сторонних продуктах распределения нагрузки, имеющих сертификат OPSEC, для которых на странице 3rd Party Configuration объекта-кластера не отмечена опция Support non-sticky connections.

FW-1: fwha_pnote_register: too many registering members, cannot register (слишком много регистрирующих элементов, невозможно зарегистрировать) Механизм критических устройств (также называемых сообщениями о проблеме, или pnote) может помнить до 16 разных устройств. Попытка настроить 17-е устройство (либо путем редактирования файла cphaprob.conf, либо с помощью команды the cphaprob -d... register) приведет к этому сообщению.

FW-1: fwha_pnote_register: <NAME> already registered (# <NUMBER>) (<ИМЯ> уже зарегистрировано (под № <НОМЕР>) Каждое устройство, зарегистрированное с помощью механизма pnote, должно иметь уникальное имя. Это сообщение может появиться при регистрации нового устройства и означает, что устройство с именем <NAME> уже зарегистрировано под номером pnote <NUMBER>.




FW-1: fwha_pnote_unregister: attempting to unregister an unregistered device <DEVICE NAME> (попытка отменить регистрацию незарегистрированного устройства <ИМЯ УСТРОЙСТВА>) Означает попытку отменить регистрацию устройства, которое в данный момент не зарегистрировано.

FW-1: alert_policy_id_mismatch: failed to send a log (не удалось отправить журнал) Журнал, содержащий информацию о несовпадении идентификатора политики на двух или более элементах, не был отправлен. Убедитесь, что на всех элементах кластера установлена одинаковая политика (по команде fw stat). Рекомендуется установить политику заново.

FW-1: fwha_receive_fwhap_msg: received incomplete HAP packet (read <number> bytes) (получен неполный HAP-пакет (прочтено <количество> байтов)) Это сообщение может быть получено, когда ClusterXL получает CCP-пакеты с кластеров версии 4.1. В таком случае его можно спокойно проигнорировать.

Сообщения в активном режиме SmartView Tracker В активном режиме SmartView Tracker могут появиться следующие сообщения об ошибках. Эти ошибки указывают на возможность того, что некоторые записи не получилось обработать и, как результат, на элементе кластера может отсутствовать синхронизирующая информация, а в SmartView Tracker отображаются неточные отчеты.

FW-1: fwlddist_adjust_buf: record too big for sync. update Y for table <id> failed. fwlddist_state=<val> (слишком большая запись для синхронизации. не удалось установить обновление Y для таблицы <идентификатор>) Указывает на проблему конфигурации на машине кластера. Либо синхронизация неверно сконфигурирована, либо на интерфейсе синхронизации существует проблема с передачей пакетов. Чтобы получить больше информации об источнике проблемы,

Выполните команду fw ctl pstat (описанную в разделе "Мониторинг синхронизации (fw ctl pstat)" (на стр. 56)).

В кластерах ClusterXL выполните команду cphaprob -a if, чтобы получить информацию о состояниях интерфейсов (см. "Мониторинг интерфейсов кластера" (на стр. 49)). Для устранения этой проблемы см. раздел "Работа со SmartView Tracker в активном режиме" (на стр. 89).

FW-1: fwldbcast_flush: active connections is currently enabled and due to high load it is making sync too slow to function properly. X active updates were dropped (в данный момент активные соединения разрешены, и из-за высокой нагрузки синхронизация выполняется слишком медленно, чтобы исправно работать. Х активных соединений было сброшено) Означает, что машина кластера сбросила обновления активного режима SmartView Tracker, чтобы сохранить функциональные возможности синхронизации. Для устранения этой проблемы см. раздел "Работа со SmartView Tracker в активном режиме" (на стр. 89).

Сообщения об ошибках, связанные с синхронизацией FW-1: fwldbcast_retreq: machine <MACHINE_ID> sent a retrans request for seq <SEQ_NUM> which is

no longer in my possession (current seq <SEQ_NUM>) (машина <ИДЕНТИФИКАТОР_МАШИНЫ> отправила запрос на повторную передачу последовательности <ПОРЯДКОВЫЙ_НОМЕР>, который мне больше не принадлежит) Это сообщение появляется, когда локальный элемент получает запрос на повторную передачу порядкового номера, которого больше нет в его окне отправки. Это сообщение может означать проблему синхронизации, если элемент-отправитель не получил запрошенный номер.

FW-1: fwlddist_save: WARNING: this member will not be fully synchronized! (ВНИМАНИЕ! Этот элемент не будет полностью синхронизирован!) FW-1: fwlddist_save: current delta sync memory during full sync has reached the maximum of <MEM_SIZE> MB (во время полной синхронизации достигнут лимит текущей памяти дельта-синхронизации, составляющий <РАЗМЕР_ПАМЯТИ> МБ) FW-1: fwlddist_save: it is possible to set a different limit by changing fw_sync_max_saved_buf_mem value (можно установить другой лимит, изменив значение fw_sync_max_saved_buf_mem) Эти сообщения могут появиться только во время полной синхронизации. При выполнении полной синхронизации обновления дельта-синхронизации сохраняются и применяются только после завершения процесса полной синхронизации. Вы можете ограничить память, используемую для сохранения обновлений дельта-синхронизации, установив переменную fw_sync_max_saved_buf_mem на нужное значение.

FW-1: fwldbcast_flush: fwlddist_buf_ldbcast_unread is not being reset fast enough (ur=<UNREAD_LOC>,fwlddist_buflen=<BUFFER_LEN>) Это сообщение может появиться из-за высокой нагрузки, в результате которой заполнение буфера синхронизации происходит быстрее считывания. Возможным решением является увеличение размера буфера fwlddist_buf_size, как это указано в разделе "Работа со SmartView Tracker в активном режиме"

(на стр. 89).

FW-1: fwlddist_mode_change: Failed to send trap requesting full sync (Не удалось отправить ловушку с запросом полной синхронизации) Это сообщение может появиться из-за проблемы при запуске процесса полной синхронизации и означает серьезную проблему. Обратитесь в службу технической поддержки.

FW-1: State synchronization is in risk. Please examine your synchronization network to avoid further problems! (Синхронизация состояний подвержена опасности. Проверьте сеть синхронизации во



избежание дальнейших проблем!) Это сообщение может появиться при чрезвычайно высокой нагрузке, когда обновление синхронизации было безвозвратно потеряно. Обновление синхронизации считается безвозвратно потерянным, когда оно не может быть передано повторно, потому что его больше нет в очереди на передачу на элементе-источнике обновления. Этот сценарий не означает, что шлюз безопасности будет неисправно работать, а, скорее, указывает на потенциальную проблему. Потенциальная проблема безопасна, если потерянное обновление синхронизации предназначалось для соединения, выполняемого только на одном элементе, как в случае с незашифрованными (прозрачными) соединениями (кроме случаев аварийного переключения, когда это обновление нужно другим элементам).

Потенциальная проблема может быть опасной, когда потерянное обновление синхронизации относится к соединению без привязки (см. "Соединения без привязки" (на стр. 14)), как в случае с зашифрованными соединениями. В этом случае один или несколько других элементов кластера могут начать сбрасывать пакеты, относящиеся к этому соединению, обычно с сообщением о несоответствии TCP-пакета таблице состояний (см. "Сообщения о несоответствии TCP таблице состояний" (на стр. 69)). В этом случае важно блокировать новые соединения при высокой нагрузке, как это указано в разделе "Блокировка новых соединений при нагрузке" (на стр. 88).

С этим сообщением связано следующее сообщение об ошибке.

FW-1: fwldbcast_recv: delta sync connection with member <MACHINE_ID> was lost and regained. <UPDATES_NUM> updates were lost. (соединение дельта-синхронизации с элементом <ИДЕНТИФИКАТОР_МАШИНЫ> было потеряно и восстановлено. Обновления <НОМЕРА_ОБНОВЛЕНИЙ> были потеряны) FW-1: fwldbcast_recv: received sequence <SEQ_NUM> (fragm <FRAG_NUM>, index <INDEX_NUM>), last processed seq <SEQ_NUM> (получена последовательность <ПОРЯДКОВЫЙ_НОМЕР> (фрагмент <НОМЕР_ФРАГМЕНТА>, индекс <НОМЕР_ИНДЕКСА>), последовательность, обработанная последней) Эти сообщения появляются, если возникла временная проблема синхронизации и некоторые обновления синхронизации не были синхронизированы между элементами. В результате некоторые соединения могли не сохраниться после аварийного переключения.

С этим сообщением связано предыдущее сообщение об ошибке.

FW-1: The use of the non_sync_ports table is not recommended anymore. Refer to the user guide for configuring selective sync instead (Использование таблицы non_sync_ports больше не рекомендуется. Настройте выборочную синхронизацию в соответствии с руководством пользователя) В предыдущих версиях для реализации выборочной синхронизации, позволяющей выбирать сервисы, не нуждающиеся в синхронизации, использовалась таблица ядра под названием non_sync_ports. Теперь конфигурирование выборочной синхронизации возможно с помощью панели инструментов SmartDashboard. См. "Выбор сервисов, не требующих синхронизации" (см. "Конфигурирование несинхронизируемых сервисов" на стр. 13).

Сообщения о несоответствии TCP таблице состояний Когда механизм синхронизации загружен, в столбце Information (Информация) SmartView Tracker могут появляться сообщения о том, что TCP-пакет не соответствует таблице состояний. В этом разделе рассматриваются способы исправления каждой ошибки.

TCP packet out of state - first packet isn't SYN tcp_flags: FIN-ACK (TCP-пакет не соответствует таблице состояний - первый пакет не является SYN tcp_flags: FIN-ACK) TCP packet out of state - first packet isn't SYN tcp_flags: FIN-PUSH-ACK (TCP-пакет не соответствует таблице состояний - первый пакет не является SYN tcp_flags: FIN-PUSH-ACK)

Эти сообщения появляются при повторной передаче пакета FIN после удаления соединения из таблицы соединений. Для решения этой проблемы на странице Global properties (Общие свойства) для Stateful Inspection панели инструментов SmartDashboard увеличьте тайм-аут окончания TCP c 20 до 60 секунд. При необходимости также увеличьте таблицу соединений, чтобы она не заполнялась полностью.

SYN packet for established connection (Пакет SYN для установленного соединения) Это сообщение появляется, если на установленном соединении получен пакет SYN, а верификатор последовательностей выключен. Верификатор последовательностей выключен для соединения без привязки на кластере (или в SecureXL). Некоторые приложения закрывают соединения с пакетом RST (для повторного использования портов). Чтобы решить эту проблему, разрешите это поведение для некоторых или всех портов. Например, выполните команду: fw ctl set int fw_trust_rst_on_port <port>

Это означает, что шлюз безопасности должен доверять RST c каждого порта, в случае если одного порта недостаточно.

Сообщения об ошибках, специфические для платформ Сообщения об ошибках, специфические для IPSO FW-1: fwha_nok_get_mc_mac_by_ip: received a NULL query (получен запрос NULL)

FW-1: fwha_nok_get_mc_mac_by_ip: nokcl_get_clustermac returned unknown type <TYPE> (nokcl_get_clustermac вернул неизвестный тип <ТИП>)



Эти сообщения означают, что, возможно, автоматические ARP-записи прокси-сервера для конфигурации статической NAT-трансляции неправильно установлены.

FW-1: fwha_nokcl_sync_rx_f: received NULL mbuf from ipso. Packet dropped. (получен NULL mbuf от IPSO. Пакет сброшен) FW-1: fwha_nokcl_sync_rx_f: received packet with illegal flag=<FLAG>. drop packet. (получен пакет с недопустимым флагом=<ФЛАГ>. сбросить пакет) Эти сообщения означают, что был получен недопустимый пакет CPHA, который будет сброшен. Если это происходит чаще, чем несколько раз за загрузку, значит, кластер неисправен.

FW-1: fwha_nokcl_reregister_rx: unregister old magic mac values with IPSO (отменить регистрацию старых магических значений mac в IPSO) FW-1: fwha_nokcl_reregister_rx: new magic mac values <MAC,FORWARD MAC> registered successfully with IPSO. (регистрация новых магических значений mac <MAC,FORWARD MAC> в IPSO успешно завершена) Уведомление об успешном завершении операции fw ctl set int fwha_magic_mac.

FW-1: fwha_nokcl_reregister_rx: error in de-registration to the sync_rx (<ERR NUM>) new magic macs values will not be applied (ошибка при отмене регистрации sync_rx (<НОМЕР ОШИБКИ>) новые магические числа mac не будут применены Уведомление о сбое операции fw ctl set int fwha_magic_mac. Будут сохранены предыдущие значения MAC.

FW-1: fwha_nokcl_creation_f: error in registration … (ошибка при регистрации) FW-1: fwha_nok_init: NOT calling nokcl_register_creation since did not de-register yet (вызов nokcl_register_creation НЕ выполняется, так как регистрация еще не отменена) FW-1: fwha_nok_fini: failed nokcl_deregister_creation with rc=<ERROR NUM> (не удалось выполнить nokcl_deregister_creation с rc=<НОМЕР ОШИБКИ>) Эти сообщения означают, что произошла внутренняя ошибка при регистрации на механизме кластеризации IPSO. Убедитесь, что версия IPSO поддерживается данной версией шлюза безопасности и что IPSO IP Clustering или кластер VRRP правильно сконфигурирован.

FW-1: successfully (dis)connected to IPSO Clustering (успешное подключение/отключение к IPSO Clustering) Уведомление, обычно получаемое при инициализации и удалении шлюза безопасности.

FW-1: fwha_pnote_register: noksr_register_with_status failed FW-1: fwha_IPSO_pnote_expiration: mismatch between IPSO device to ckp device <DEVICE NAME> (несоответствие между устройством IPSO и устройством ckp <ИМЯ УСТРОЙСТВА>) FW-1: fwha_nokia_pnote_expiration: can not find the device nokia claims to be expired (невозможно найти устройство, у которого, по утверждению nokia, истек срок годности) FW-1: fwha_noksr_report_wrapper: attempting to report an unregistered device <DEVICE NAME> (попытка сообщить о незарегистрированном устройстве <ИМЯ УСТРОЙСТВА>) Эти сообщения могут появиться в результате проблемы во взаимодействии между механизмами мониторинга устройств IPSO и ClusterXL. Для устранения этой проблемы должно быть достаточно перезагрузки. Если проблема повторится, обратитесь в службу технической поддержки Check Point.

Отказ запуска элемента после перезагрузки Если перезагрузка (или последовательное выполнение команд cpstop и cpstart) на элементе кластера выполняется, когда кластер сильно загружен, может произойти отказ запуска элемента. Элемент, осуществляющий запуск, попытается выполнить полную синхронизацию с одним или несколькими существующими активными элементами и в процессе может использовать все свои ресурсы и доступную память. Это может привести к неожиданному поведению.

Чтобы устранить эту проблему, определите максимальный объем памяти, используемый элементом при запуске для синхронизации своих соединений с активным элементом. По умолчанию этот объем не ограничен. Рассчитайте объем требуемой памяти по следующей таблице:

Память (МБ), необходимая для полной синхронизации.

Новые соединения/с

Количество открытых соединений

100 1 000 5 000 10 000

1 000 1,1 6,9

10 000 11 69 329

20 000 21 138 657 1305

50 000 53 345 1642 3264



Примечание: эти значения были получены для элементов кластера, использующих платформу Windows, с процессорами Pentium 4, работающими с частотой 2,4 ГГц.

Например, если на кластере имеется 10 000 соединений, а скорость составляет 1 000 соединений/с, то для полной синхронизации вам потребуется 69 МБ.

Определите максимальный объем памяти с помощью следующего глобального параметра шлюза: fw_sync_max_saved_buf_mem.

Единица измерения — мегабайт. Подробнее см. в разделе "Дополнительное конфигурирование кластера" (на стр. 86).


Глава 8

Дополнительное конфигурирование ClusterXL


Работа с сетями VPN и кластерами 72

Работа с NAT и кластерами 73

Работа с сетями VLAN и кластерами 74

Мониторинг состояния канала интерфейса 76

Агрегирование каналов и кластеры 77

Дополнительное конфигурирование кластера 86

Определение отключенных интерфейсов 90

Настройка тайм-аута обновления политики 90

Расширенное применение трехэтапного TCP-квитирования 91

Настройка адресов кластера в разных подсетях 91

Переход от одного шлюза к кластеру ClusterXL 94

Добавление элемента в существующий кластер 95

Настройка ISP-резервирования на кластере 96

Активация протоколов динамической маршрутизации в развернутом кластере 96

Работа с сетями VPN и кластерами

Конфигурирование VPN и кластеров Конфигурирование кластера шлюзов безопасности с помощью панели SmartDashboard осуществляется подобно конфигурированию одного шлюза безопасности. Все атрибуты VPN задаются на объекте — кластере шлюзов, за исключением двух атрибутов, которые определяются для каждого элемента кластера.

1. Откройте окно Gateway Cluster Properties на странице Cluster Members. Для каждого элемента кластера в окне Cluster member Properties (Свойства элемента кластера) настройте вкладку VPN:

Office Mode for Remote access (Офисный режим для удаленного доступа) — если вы хотите

использовать офисный режим для удаленного доступа, определите пул IP-адресов, выделенных для каждого элемента кластера.

Hardware Certificate Storage List (Список хранилищ сертификатов аппаратного обеспечения) — если ваш элемент кластера поддерживает хранилище сертификатов IKE аппаратного обеспечения, задайте свойства сертификата. В этом случае сервер управления безопасностью дает элементу кластера указание создать ключи и предоставить материал, необходимый для создания запроса на сертификат. Сертификат загружается на элемент кластера во время установки политики.

2. На VPN-кластере ключи IKE синхронизируются. На странице Synchronization окна Gateway Cluster Properties отметьте опцию Use State Synchronization, даже для конфигураций High Availability.

3. На странице Topology окна Gateway Cluster Properties определите домен шифрования для кластера. В разделе VPN Domain (Домен VPN) выберите одну из двух следующих настроек:

All IP addresses behind cluster members based on topology information (Задавать все IP-адреса за элементами кластера задаются на основании информации о топологии). Это опция по умолчанию.

Manually Defined (Задаются вручную). Используйте эту опцию, если IP-адрес кластера находится не в сети элементов, т.е. если виртуальный IP-адрес кластера находится в другой подсети, нежели интерфейсы элементов кластера. В этом случае выберите сеть или группу сетей, которая должна включать виртуальный IP-адрес кластера, и сеть или группу сетей за кластером.



Определение равноправных кластеров VPN c отдельными серверами управления безопасностью При работе с равноправным VPN, являющимся кластером шлюзов Check Point, НЕ задавайте другой объект-кластер, если управление равноправным VPN осуществляется другим сервером управления безопасностью. Вместо этого сделайте следующее:

1. В ветви Network Objects дерева объектов щелкните правой кнопкой мыши и выберите New Check Point Externally Managed Gateway (Новый шлюз Check Point c внешним управлением).

2. На странице Topology добавьте внешние и внутренние адреса интерфейсов равноправного кластера VPN. Не используйте адреса интерфейсов элементов кластера, за исключением следующих случаев:

Если версия внешнего кластера 4.1, добавьте IP-адреса интерфейсов элементов кластера.

Если кластер является продуктом, имеющим сертификат OPSEC (кроме IPSO), возможно, вам придется добавить IP-адреса элементов кластера.

При добавлении IP-адресов интерфейсов элементов кластера на вкладке Topology интерфейса определите интерфейс как Internal (Внутренний), а IP Addresses behind this interface (IP-адреса за данным интерфейсом) как Not defined (Не определены).

3. В разделе VPN Domain страницы настройте домен шифрования шлюза с внешним управлением так, чтобы он находился за внутренним виртуальным IP-адресом шлюза. Если домен шифрования представляет собой всего одну подсеть, выберите All IP addresses behind cluster members based on topology information (Задавать все IP-адреса за элементами кластера на основании информации о топологии). Если домен шифрования включает более одной подсети, выберите Manually Defined, чтобы определить его вручную.

Работа с NAT и кластерами

Трансляции Cluster Fold и Cluster Hide Трансляция сетевых адресов (NAT) является фундаментальным принципом работы ClusterXL.

Когда элемент кластера устанавливает исходящее соединение с Интернетом, адрес источника в исходящих пакетах представляет собой физический IP-адрес интерфейса элемента кластера. С помощью NAT IP-адрес источника меняется на внешний виртуальный IP-адрес кластера. Такая трансляция адресов называется "Cluster Hide".

Для продуктов кластеризации, имеющих сертификат OPSEC, это соответствует отмеченной по умолчанию опции Hide Cluster Members' outgoing traffic behind the Cluster's IP address (Скрывать исходящий трафик элементов кластера за IP-адресом кластера) на странице 3rd Party Configuration объекта-кластера.

Когда клиент устанавливает входящее соединение с внешним (виртуальным) адресом кластера, ClusterXL посредством NAT меняет IP-адрес назначения на физический внешний адрес одного из элементов кластера. Такая трансляция адресов называется "Cluster Fold".

Для продуктов кластеризации, имеющих сертификат OPSEC, это соответствует отмеченной по умолчанию опции Forward Cluster's incoming traffic to Cluster Members' IP addresses (Передавать входящий трафик кластера на IP-адреса элементов кластера) на странице 3rd Party Configuration объекта-кластера.

Настройка NAT на кластере шлюзов Трансляция сетевых адресов (NAT) может выполняться на кластере шлюзов так же, как она выполняется на шлюзе. Такая NAT является дополнением к автоматическим трансляциям адресов "Cluster Fold" и "Cluster Hide".

Для настройки NAT измените объект — кластер шлюзов и в окне Gateway Cluster Properties выберите страницу NAT. НЕ меняйте настройки на вкладке NAT объекта — элемента кластера.

Настройка NAT на элементе кластера Трансляция сетевых адресов (NAT) может быть выполнена на интерфейсе элемента кластера, не принадлежащем кластеру.

Например, это возможно в ситуации, когда интерфейс элемента кластера, не принадлежащий кластеру, подключен к другому внутреннему шлюзу безопасности, не принадлежащему кластеру, и вы хотите скрыть адрес такого интерфейса, не принадлежащего кластеру.



Выполнение NAT означает, что когда источник пакета находится за интерфейсом элемента кластера, не принадлежащим кластеру, или на таком интерфейсе и этот пакет отправляется на хост, находящийся на другой стороне внутреннего шлюза безопасности, то адрес источника пакета будет преобразован.

Для настройки NAT на интерфейсе шлюза — элемента кластера, не принадлежащем кластеру:

1. Измените объект — кластер шлюзов.

2. На странице Cluster Member (Элемент кластера) окна Gateway Cluster Properties (Свойство кластера

шлюзов) измените объект — элемент кластера.

3. В окне Cluster Member Properties щелкните по вкладке NAT.

4. Настройте статическую или скрытую NAT-трансляцию.

Работа с VLAN и кластерами

Поддержка VLAN в ClusterXL VLAN-коммутатор помечает пакеты, источником которых является виртуальная локальная компьютерная сеть (VLAN), 4-байтовым заголовком, в котором указано, с какого порта коммутатора он передан. Передача пакетов с порта коммутатора одной VLAN-сети на порт коммутатора другой VLAN-сети запрещена, за исключением портов, определенных как принадлежащие всем VLAN-сетям ("глобальные" порты).

Элемент кластера подключен к глобальному порту коммутатора VLAN, что логически делит один физический порт на множество портов VLAN, каждый из которых ассоциирован с интерфейсом, помеченным VLAN-тегом (интерфейсом VLAN) на элементе кластера.

При определении VLAN-тегов на интерфейсе вы можете задать IP-адреса кластера только на интерфейсах VLAN (помеченных тегами). Определение IP-адреса кластера на физическом интерфейсе с VLAN-сетями не поддерживается. Для определения такого физического интерфейса установите Network Objective на Monitored Private (Частный контролируемый интерфейс).

Примечание: ClusterXL не поддерживает VLAN-сети на сервере Windows 2000

или Windows 2003.

Подключение нескольких кластеров в одной VLAN Подключение незащищенных интерфейсов (например, внутренние или внешние интерфейсы) нескольких кластеров к одной VLAN-сети не рекомендуется. Для каждого кластера нужна отдельная VLAN и/или коммутатор.

Подключение защищенных интерфейсов (интерфейсов синхронизации) нескольких кластеров также не рекомендуется по той же причине. Поэтому лучше всего подключить защищенные интерфейсы данного кластера кроссовым соединением, если это возможно, или подключить их к изолированной VLAN.

Если вам необходимо подключить защищенные или незащищенные интерфейсы нескольких кластеров к одной VLAN, вам придется изменить:

MAC-адрес назначения для связи между кластером и машинами за его пределами (это касается только кластеров ClusterXL, работающих в режиме Load Sharing Multicast).

MAC-адрес источника для связи между элементами кластера по протоколу управления кластером.

Внесение изменений в MAC-адрес назначения Информация этого раздела касается только кластеров ClusterXL, работающих в режиме Load Sharing Multicast.

Как присваивается MAC-адрес кластера назначения в режиме Load Sharing Multicast

Когда машина, находящаяся за пределами кластера, хочет связаться с кластером, она отправляет ARP-запрос с (виртуальным) IP-адресом кластера. В ответ на ARP-запрос кластер отправляет групповой MAC-адрес, даже если IP-адрес является индивидуальным.



Этот групповой MAC-адрес назначения кластера определяется по индивидуальному IP-адресу кластера. Верхние три байта ― это 01.00.5E, и они означают групповой MAC обычным способом. Нижние три байта идентичны нижним трем байтам IP-адреса. Ниже приведен пример MAC-адреса, определенного по IP-адресу 10.0.10.11.

Дубликаты групповых MAC-адресов: проблема

Когда к одной VLAN подключено несколько кластеров, последние три байта IP-адресов интерфейсов кластера, подключенных к VLAN, должны различаться. Если они одинаковые, то информация, отправленная из-за пределов кластера и предназначенная для одного из кластеров, достигнет их обоих, что приведет к проблемам со связью.

Например, для интерфейса одного из кластеров, подключенных к VLAN, нормально иметь адрес 10.0.10.11, а для интерфейса второго кластера ― адрес 10.0.10.12. Однако следующие адреса для интерфейсов первого и второго кластеров вызовут сложности:

10.0.10.11 и 20.0.10.11.

Дубликаты групповых MAC-адресов: решение

Лучшее решение ― изменить последние три байта IP-адреса всех, кроме одного, интерфейсов кластера, у которых последние три байта IP-адреса одинаковые.

Если IP-адрес интерфейса кластера изменить невозможно, вам необходимо изменить автоматически присвоенный групповой MAC-адрес всех, кроме одного, кластеров и заменить его групповым MAC-адресом, задаваемым пользователем. Для этого выполните следующие действия:

1. На странице ClusterXL объекта-кластера выберите Load Sharing>Multicast Mode (Распределение нагрузки > Многоадресный режим). На вкладке Topology измените интерфейс кластера, подключенный к той же VLAN, что и другой кластер.

2. На вкладке General окна Interface Properties щелкните Advanced.

3. Измените MAC-адрес по умолчанию и внимательно введите новый MAC-адрес, задаваемый пользователем. Он должен иметь формат 01:00:5e:xy:yy:yy, где x имеет значение между 0 и 7, а y ― между 0 и f(шестнадцатеричное).

Внесение изменений в MAC-адрес источника Информация этого раздела касается всех режимов ClusterXL: как High Availability, так и Load Sharing, а также продуктов кластеризации, имеющих сертификат OPSEC.

Как присваивается MAC-адрес кластера-источника

Элементы кластера осуществляют связь друг с другом по протоколу управления кластером (CCP). CCP-пакеты отличаются от обычного сетевого трафика тем, что им присваивается уникальный MAC-адрес источника.

Первые четыре байта MAC-адреса источника все равны нулю: 00.00.00.00

Пятый байт MAC-адрес источника является магическим числом. Его значение соответствует его назначению

Значение пятого байта по умолчанию

Назначение

0xfe CCP-трафик

0xfd Трафик Forwarding Layer

Индивидуальный IP-адрес назначения кластера

Групповой MAC-адрес назначения кластера

Верхние 3 байта означают групповой MAC

Нижние 3 байта из IP-адреса



Шестой байт представляет собой идентификатор элемента кластера-отправителя

Дубликаты MAC-адресов кластера-источника: проблема

Когда к одной VLAN подключено несколько кластеров, при этом трафик CCP и Forwarding Layer для назначения использует групповой MAC-адрес, этот трафик достигнет только целевого кластера.

Однако если для назначения трафика CCP и Forwarding Layer используется широковещательный MAC-адрес (а также в некоторых других случаях), трафик кластера, предназначенный для одного кластера, виден всем подключенным кластерам. Если этот трафик обработан не тем кластером, это приведет к проблемам со связью.

Дубликаты MAC-адресов кластера-источника: решение

Для различения MAC-адреса источника в пакетах от разных кластеров, подключенных к одной VLAN, измените MAC-адрес источника интерфейса кластера, подключенного к VLAN на всех кластерах, кроме одного.

Для настройки нескольких кластеров на одной VLAN используйте следующие параметры конфигурации шлюза: Эти параметры относятся как к ClusterXL, так и к продуктам кластеризации, имеющим сертификат OPSEC.

Параметр Значение по умолчанию

fwha_mac_magic 0xfe

fwha_mac_forward_magic 0xfd

Изменение значений этих параметров конфигурации шлюза приведет к изменению пятой части MAC-адреса источника протокола управления кластером и переданных пакетов. Используйте любое значение с условием, что эти два параметра конфигурации шлюза отличаются друг от друга. Во избежание путаницы не используйте значение 0x00.

Инструкция по изменению этих параметров приведена в разделе "Как настроить параметры конфигурации шлюза" (на стр. 86).

Мониторинг состояния канала интерфейса Активация мониторинга состояния канала интерфейса позволяет сократить время, необходимое кластеру ClusterXL для обнаружения отказа интерфейса. Благодаря мониторингу состояния канала (т.е. электрической части) интерфейса ClusterXL немедленно получает предупреждение о проблемах со связью у определенного сетевого интерфейса, таких как отключение кабеля или электрический отказ (реальный или смоделированный) на коммутаторе.

Для мониторинга состояния канала интерфейса требуется драйвер устройства интерфейса, который поддерживает обнаружение состояния канала. В сообщении о состоянии канала драйвер устройства сообщает либо о подключенном, либо об отключенном канале.

Мониторинг состояния канала интерфейса особенно полезен в ситуациях, когда контролируемый интерфейс (либо интерфейс кластера, либо частный контролируемый интерфейс) отправляет пробные запросы ICMP ECHO, а хосты или маршрутизаторы в подключенной подсети на них не отвечают.

Когда мониторинг активирован, ClusterXL немедленно обнаруживает выход интерфейса из строя. Когда он отключен, обнаружение неисправности интерфейса происходит путем наблюдения за истечением тайм-аута длительностью менее секунды.

По умолчанию мониторинг состояния канала интерфейса отключен.

Примечание: Для мониторинга состояния канала интерфейса требуется драйвер

устройства интерфейса, который поддерживает обнаружение состояния канала и поддерживается только в системах Linux и SecurePlatform. Эта опция работает только на кластерах ClusterXL, состоящих из двух элементов, где два интерфейса напрямую подключены кросс-кабелем. См. sk31336 (http://supportcontent.checkpoint.com/solutions?id=sk31336).

Активация мониторинга состояния канала интерфейса Для активации (или отключения) мониторинга состояния канала интерфейса:

Задайте глобальный параметр fwha_monitor_if_link_state.




Использование:

fw ctl set int fwha_monitor_if_link_state <0|1>

Варианты:

0 – отключает мониторинг состояния канала интерфейса. Это настройка по умолчанию.

1 – включает мониторинг состояния канала интерфейса.

О том, как задать параметры конфигурации таким образом, чтобы они сохранились после перезагрузки, см. SecureKnowledge sk26202 (http://supportcontent.checkpoint.com/solutions?id=sk26202).

Агрегирование каналов и кластеры В этом разделе

Общий обзор 77

Агрегирование каналов: режим High Availability 78

Агрегирование каналов: режим Load Sharing 81

Определение VLAN-сетей в агрегации интерфейсов 83

Рекомендации по производительности агрегирования каналов 83

Команды ClusterXL для агрегаций интерфейсов 84

Диагностика неполадок агрегированных интерфейсов 85

Общий обзор Агрегирование каналов (также называемое "NIC teaming" - агрегирование сетевых адаптеров) означает объединение нескольких сетевых интерфейсов на шлюзе безопасности. Такая агрегация интерфейсов обеспечивает высокую доступность в случае отказа интерфейса, а в режиме Load Sharing может позволять значительно увеличить общую пропускную способность.

Примечание: агрегирование каналов поддерживается только на SecurePlatform от Check Point.

В агрегации интерфейсов от двух до восьми интерфейсов настроены таким образом, чтобы действовать как один интерфейс с использованием одного IP-адреса.

Агрегация — это виртуальный интерфейс, определяемый на SecurePlatform аналогично физическому интерфейсу. Каждый физический интерфейс в агрегации называется ведомым интерфейсом этой агрегации. Ведомые интерфейсы не функционируют независимо от агрегации.

Агрегирование каналов может осуществляться в одном из двух настроенных режимов:

High Availability (Active/Backup) — режим высокой доступности (Активный/Резервный), когда в каждый момент времени активен только один интерфейс. При отказе интерфейса агрегация выполняет аварийное переключение на другой интерфейс. Разные интерфейсы агрегации могут быть подключены к разным коммутаторам, что дополняет высокую доступность интерфейсов высокой доступностью коммутаторов.

Примечание: для внутреннего аварийного переключения в агрегации, вызванного

состоянием канала, требуется сетевой интерфейс, поддерживающий стандарт Media-Independent Interface (MII).

Load Sharing (Active/Active) — режим распределения нагрузки (Активный/Активный), когда активны все интерфейсы для разных соединений. Соединения распределяются между интерфейсами по сетевым уровням 3 и 4 с соблюдением либо стандарта IEEE 802.3ad, либо XOR. Режим Load Sharing имеет преимущество, так как повышает пропускную способность, но требует подключения всех интерфейсов агрегации к одному коммутатору.

Для режимов агрегирования каналов High Availability и Load Sharing:

Количество определяемых агрегаций интерфейсов ограничивается максимальным количеством интерфейсов, поддерживаемых каждой платформой. Информация о соответствующем издании Check Point приведена в "Примечаниях к изданию".

В одной агрегации High Availability или Load Sharing можно сконфигурировать до 8 сетевых адаптеров.




Агрегирование каналов: режим High Availability В этом разделе

Полносвязное резервирование 78

Аварийное переключение агрегации 79

Создание агрегации интерфейсов в режиме High Availability 79

Поддержка аварийного переключения для VLAN 80

При работе с приложениями, предназначенными для решения ответственных задач, обязательным требованием предприятия является наличие высокодоступной сети.

Кластеризация обеспечивает резервирование, а значит, и высокую доступность на уровне шлюза. Без агрегирования каналов резервирование сетевых адаптеров (NIC) или коммутаторов на любой стороне шлюза возможно только в кластере и только путем аварийного переключения шлюза на другой элемент кластера.

Вы можете достичь резервирования кластера шлюзов без агрегирования каналов. В случае отказа коммутатора или шлюза системное резервирование обеспечивается кластерным решением High Availability. Например, вы можете иметь систему резервирования с двумя синхронизированными элементами кластера шлюзов безопасности, установленными в топологии резервирования.


GW-1 и GW-2 являются элементами кластера. У каждого есть один внешний сетевой адаптер (NIC), подключенный к внешнему коммутатору (S-1 и S-2 соответственно).

S-1 и S-2 являются коммутаторами.

C-1 и C-2 являются объединяющими сетями.

В случае отказа элемента 1, его сетевого адаптера или S-1 единственным активным шлюзом становится элемент 2, который соединяется с коммутатором S-2 по сети C-2. Результатом аварийного переключения при отказе любого компонента (шлюза, адаптера или коммутатора) является прекращение действия резервирования. Следующий отказ любого активного компонента приведет к полной остановке сетевого трафика.

Агрегирование каналов обеспечивает высокую доступность сетевых адаптеров. В случае отказа одного вместо него может работать другой. Эта возможность существует как в режиме High Availability, так и в режиме Load Sharing.

Полносвязное резервирование Агрегирование каналов в режиме High Availability, если оно применяется в ClusterXL, позволяет повысить уровень надежности путем обеспечения в сети выборочного резервирования. Такое выборочное резервирование достигается благодаря использованию полносвязной топологии, предусматривающей независимое резервирование как сетевых адаптеров, так и коммутаторов.

Элемент-2

Элемент-1



Полносвязная топология расширяет возможности резервирования в системе, обеспечивая резерв как для интерфейса, так и для коммутатора, в основном путем дублирования кабеля. У каждого элемента кластера есть два интерфейса, подключенных к каждому коммутатору.


Элемент-1 и элемент-2 являются элементами кластера, работающими в режиме High Availability, из них каждый подключен к двум внешним коммутаторам.

S-1 и S-2 являются коммутаторами.

C-1, C-2, C-3 и C-4 являются сетевыми соединениями.

Аварийное переключение агрегации При агрегировании каналов в режиме High Availability, когда шлюз входит в состав кластера, внутреннее аварийное переключение агрегации может произойти в одном из следующих случаев:

Активный интерфейс обнаружил отказ в состоянии канала на контролируемом интерфейсе.

ClusterXL обнаружил отказ при отправке или получении пакетов подтверждения активности протокола управления кластером (CCP).

Любой из этих отказов в зависимости от обстоятельств вызовет аварийное переключение в агрегации интерфейсов или между элементами кластера. В следующем разделе рассматриваются два типа процессов аварийного переключения.

При обнаружении отказа это регистрируется в журнале. Его можно увидеть в SmartView Tracker.

Создание агрегации интерфейсов в режиме High Availability Для создания агрегации интерфейсов выполните следующие действия:

Удаление IP-адресов с ведомых интерфейсов 79

Настройка ведомых интерфейсов как отключенных 80

Определение агрегации интерфейсов 80

Проверка исправной работы агрегации 80

Удаление IP-адресов с ведомых интерфейсов

Перед определением агрегации интерфейсов удалите IP-адреса с ведомых (физических) интерфейсов:

1. Запустите утилиту конфигурирования SecurePlatform:

sysconfig

2. Выберите Network Connections (Сетевые соединения).

3. Для каждого интерфейса, который вы хотите сделать ведомым:

a) Выберите Configure connection (Настроить соединение).

b) Выберите соответствующий физический интерфейс.

Элемент-2

Элемент-1



c) Выберите Remove IP from interface (Удалить IP c интерфейса).

d) Вернитесь в Network Connections.

4. Закройте утилиту конфигурирования SecurePlatform.

Настройка ведомых интерфейсов как отключенных

Отключенные интерфейсы — это интерфейсы элементов кластера, не контролируемые механизмом ClusterXL. В случае отказа отключенного интерфейса аварийное переключение не происходит.

Для определения ведомого интерфейса на SecurePlatform как отключенного:

1. В $FWDIR/conf/ создайте файл с этим именем: discntd.if

2. В отдельных строках файла введите имя каждого физического интерфейса, который будет работать в паре "ведомый-агрегация".

Определение агрегации интерфейсов

Удалив IP-адреса с ведомых интерфейсов, определите агрегацию:


sysconfig

2. Выберите Network Connections.

3. Выберите Add new connection (Добавить новое соединение).

4. Выберите Bond (Агрегация).

5. Для каждого интерфейса, который будет подчиняться агрегации, введите его имя в списке и нажмите Enter.

6. Введите n, чтобы перейти к следующему шагу.

7. Выберите High Availability.

8. Выберите, будете ли вы использовать параметры по умолчанию (рекомендуется) или их пользовательскую настройку.

9. Выберите, будете ли вы настраивать первичный ведомый интерфейс или нет (рекомендуется).

После отказа и восстановления первичный ведомый интерфейс автоматически возвращается в активное состояние, даже если произошло аварийное переключение на другой интерфейс. Если первичного интерфейса нет, аварийное переключение приведет к активации другого интерфейса, который будет оставаться активным до отказа.

10. Задайте IP-адрес и сетевую маску новой агрегации интерфейсов.


Проверка исправной работы агрегации

После установки или аварийного переключения рекомендуется проверить исправность агрегации, выведя информацию о ней на экран.

1. Выполните:

cphaprob -a if

Проверьте, отражено ли состояние агрегации UP (Работает).

2. Выполните:

cphaconf show_bond <bond name>

Проверьте правильность настроек агрегации.

Поддержка аварийного переключения для VLAN При агрегировании каналов в режиме High Availability ClusterXL проверяет идентификаторы VLAN на предмет отказа или ошибки связи и инициирует аварийное переключение при обнаружении отказа.



В коммутируемой среде с активированной VLAN ClusterXL осуществляет мониторинг VLAN с наименьшим идентификационным номером. Мониторинг осуществляется путем отправки пакетов протокола управления кластером ClusterXL (CCP) в прямом и обратном направлениях с заданным интервалом. Наименьший идентификатор VLAN означает состояние физического соединения. Этот идентификатор VLAN контролируется постоянно, и в случае ошибки связи ClusterXL инициирует аварийное переключение. При этот ClusterXL не обнаруживает проблемы конфигурации VLAN на коммутаторе.

Агрегирование каналов: режим Load Sharing В этом разделе

Порядок создания и настройки агрегации интерфейсов в режиме Load Sharing 81

Конфигурирование коммутаторов Cisco для работы в режиме Load Sharing 82

В режиме Load Sharing агрегирование каналов помимо высокой доступности обеспечивает распределение нагрузки. Все ведомые интерфейсы являются активными, а соединения распределяются между ведомыми интерфейсами агрегации подобно тому, как ClusterXL распределяет соединения между элементами кластера.

В режиме Load Sharing каждое соединение назначается определенному ведомому интерфейсу. Для индивидуального соединения активен только один ведомый интерфейс. При отказе этого интерфейса агрегация осуществляет аварийное переключение с передачей соединения отказавшего интерфейса одному из других интерфейсов, что добавляет это соединение в число уже обрабатываемых им соединений.

Соединения распределяются между ведомыми интерфейсами по сетевым уровням 3 и 4 с соблюдением одного из следующих стандартов:

802.3ad — включает LACP и является рекомендуемым режимом, но он может не поддерживаться некоторыми коммутаторами.

XOR.

В режиме Load Sharing все интерфейсы агрегации должны быть подключены к одному коммутатору. Сам коммутатор должен поддерживать агрегирование каналов и быть на него настроен с использованием того же стандарта (802.3ad или XOR), что и агрегация шлюзов.

Для Load Sharing необходимо наличие запущенного пакета Performance Pack.

Порядок создания и настройки агрегации интерфейсов в режиме Load Sharing Создание агрегации Load Sharing выполняется аналогично созданию агрегации High Availability. Оно включает в себя такие же процедуры удаления IP-адресов с ведомых интерфейсов, отключения ведомых интерфейсов и проверки агрегации.

Для создания агрегации Load Sharing:

1. Настройте коммутаторы на используемый вами стандарт (802.3ad или XOR).



2. Удалите IP-адреса с ведомых интерфейсов (см. стр. 79).

3. Настройте ведомые интерфейсы как отключенные (см. стр. 80).

4. Определите агрегацию интерфейсов в режиме Load Sharing.

5. Настройте критический минимум интерфейсов.

6. Проверьте исправность работы агрегации (см. стр. 80).

Определение агрегации интерфейсов в режиме Load Sharing

Для определения агрегации интерфейсов:


sysconfig


3. Выберите Add new connection.

4. Выберите Bond.

5. Для каждого интерфейса, который будет подчиняться агрегации, введите его имя в списке и нажмите Enter.

6. Введите n, чтобы перейти к следующему шагу.

7. Выберите Load Sharing.

8. Выберите стандарт Load Sharing: 802.3ad или XOR.

9. Выберите, будете ли вы использовать параметры по умолчанию (рекомендуется) или их пользовательскую настройку.

10. Задайте IP-адрес и сетевую маску новой агрегации интерфейсов.


Настройка критического минимума интерфейсов

Агрегация в режиме Load Sharing считается вышедшей из строя, когда ведомых интерфейсов в рабочем состоянии осталось меньше критического минимума.

Если настройка не установлена, то критический минимум интерфейсов в агрегации, состоящей из n интерфейсов, равен n-1. В случае отказа второго интерфейса вышедшей из строя считается вся агрегация, даже если агрегация включает более двух интерфейсов.

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

Для определения количества критических интерфейсов создайте и отредактируйте следующий файл:

$FWDIR/conf/cpha_bond_ls_config.conf

Каждая строка файла должна содержать следующий синтаксис:

<bondname> <critical#> (<имя агрегации> <критический минимум>)

Например, если в агрегации bond0 семь интерфейсов, а в агрегации bond1 шесть интерфейсов, файл

должен иметь следующее содержимое:

bond0 5

bond1 3

В этом случае агрегация bond0 будет считаться вышедшей из строя при отказе трех из ее интерфейсов.

Агрегация bond1 будет считаться вышедшей из строя при отказе четырех из ее интерфейсов.

Конфигурирование коммутаторов Cisco для работы в режиме Load Sharing Для коммутаторов Cisco предусмотрены образцы команд конфигурирования.



Для 802.3ad:

Для XOR:

Определение VLAN-сетей в агрегации интерфейсов Определение VLAN-сетей в агрегации интерфейсов осуществляется так же, как на обычном интерфейсе.

Для определения VLAN в агрегации интерфейсов:


sysconfig


3. Выберите Add new connection.

4. Выберите VLAN.

5. Выберите интерфейс или агрегацию интерфейсов, в которой хотите настроить VLAN.

6. Введите идентификатор VLAN.

7. Задайте IP-адреса для VLAN.


Рекомендации по производительности агрегирования каналов Чтобы достичь наибольшей производительности, для агрегирования каналов используйте статическую привязку.

Настройка привязок Если вы используете Performance Pack в многоядерной системе, то после определения агрегаций вам

необходимо выполнить настройку привязок вручную. Используйте параметр -s команды sim affinity,

см. "Руководство администратора R75.40VS Performance Pack".

Примечание: команды sim affinity действуют, только если пакет Performance

Pack активирован и запущен. Performance Pack запускается при первой установке политики.

Для достижения оптимальной производительности настройте привязки согласно следующим инструкциям:

1. Выполните команду sim affinity с использованием опции -s.

2. Если это возможно, выделите по одному процессорному ядру для каждого интерфейса. См. sk33520 (http://supportcontent.checkpoint.com/solutions?id=sk33250).




3. Если интерфейсов больше, чем ядер, одно или несколько ядер работают с двумя интерфейсами. Используйте пары интерфейсов с одинаковым положением во внутренней и внешней агрегациях.

a) Чтобы увидеть положения интерфейсов в агрегации, выполните команду:

cat /proc/net/bonding/<bond name>.

b) Отметьте последовательность интерфейсов в выводе и сравните ее в двух агрегациях (во внешней агрегации и ее соответствующей внутренней агрегации). Интерфейсы, которые находятся в одинаковом положении в двух агрегациях, представляют собой пару интерфейсов и настраиваются на обработку одним процессорным ядром.

Например, у вас может быть четыре процессорных ядра (0-3) и шесть интерфейсов (0-5), распределенных между двумя агрегациями:

bond0 bond1

eth0 eth3

eth1 eth4

eth2 eth5

Двум из ядер придется работать с двумя интерфейсами. Оптимальная конфигурация может иметь следующий вид:

bond0 bond1

eth0 ядро 0 eth3 ядро 0

eth1 ядро 1 eth4 ядро 1

eth2 ядро 2

eth5 ядро 3

Команды ClusterXL для агрегаций интерфейсов

cphaconf show_bond Просмотр состояния одной агрегации интерфейсов или обзора всех интерфейсов

Синтаксис cphaconf show_bond [<bond-name>|-a]

Опции Параметр Описание

bond-name имя целевой агрегации

-a обзор всех агрегаций

Пример



Комментарии В результатах отчета отображается:

Количество требуемых ведомых интерфейсов ("Настройка критического минимума интерфейсов" на стр. 82)

Значение состояния:

Down — (только в режиме Load Sharing) физический канал не работает.

Active — трафик, обрабатываемый в данный момент времени.

Standby — (только в режиме High Availability) интерфейс находится в

состоянии готовности и поддерживает аварийное переключение внутренней агрегации.

Not Available (Недоступный) — (только в режиме High Availability) физический канал сломан или элемент кластера находится в состоянии down. В этом состоянии агрегация не может выполнить аварийное переключение.

Link (Канал) — при наличии физического канала.

cphaconf failover_bond Запуск внутреннего аварийного переключения агрегации интерфейсов (только в режиме High Availability)

Синтаксис cphaconf failover_bond <bond-name>

Опции Параметр Описание

bond-name имя целевой агрегации

chaprob -a if Отображение состояния всех агрегаций интерфейсов и VLAN-сетей

Синтаксис cphaprob -a if

Пример

Комментарии Используйте эту команду, чтобы узнать, может ли агрегация High Availability выполнить аварийное переключение.

Диагностика неполадок агрегированных интерфейсов В этом разделе

Порядок диагностики 85

Задержки соединения на коммутаторах 86

Порядок диагностики 1. Проверьте состояние агрегации ("Проверка исправной работы агрегации" на стр. 80).

2. При наличии проблемы посмотрите, не вышел ли из строя физический канал:

a) Выполните команду:

cphaconf show_bond <bond-name>



b) Найдите ведомый интерфейс, который сообщает об отсутствии канала.

c) Проверьте кабельные соединения и другое оборудование.

d) Проверьте конфигурацию порта на коммутаторе.

3. Посмотрите, не вышел ли из строя элемент кластера:

cphaprob state

Если на каком-либо из элементов кластера Firewall State (Состояние брандмауэра) имеет иное

значение, нежели active, продолжайте диагностику с помощью команды cphaprob state (см.

"Команда cphaprob" на стр. 46).

4. Просмотрите журналы регистрации в SmartView Tracker.

Задержки соединения на коммутаторах При использовании некоторых коммутаторов во время внутренних аварийных переключений агрегаций могут произойти задержки соединения. Из-за различных опций, установленных на некоторых коммутаторах, коммутатору может потребоваться до минуты, прежде чем он начнет обслуживание вновь подключенного интерфейса. Для сокращения времени запуска после аварийного переключения канала предлагается выполнить следующие действия:

1. Отключите автоопределение на соответствующем интерфейсе.

2. Активируйте опцию PortFast на некоторых коммутаторах Cisco.

3. Отключите STP на портах.

Предупреждения в связи с использованием PortFast

Опцию PortFast ни в коем случае нельзя использовать на портах, обеспечивающих подключение к другим коммутаторам или хабам. В таких ситуациях важно, чтобы связующее дерево осуществляло процедуру инициализации. В противном случае эти соединения могут привести к образованию физических петель с непрерывной передачей (или даже размножением) пакетов, в результате которой сеть выйдет из строя.

Образец конфигурирования опции PortFast на коммутаторе Cisco

Для активации PortFast на интерфейсе GigabitEthernet 1/0/15 коммутатора Cisco 3750 с системой IOS необходимо выполнить следующие команды.

1. Введите режим конфигурации:

cisco-3750A#conf t

2. Укажите интерфейс, который вы хотите настроить:

cisco-3750A(config)#interface gigabitethernet1/0/15

3. Установите PortFast на этом интерфейсе:

cisco-3750A(config-if)#spanning-tree portfast

Дополнительное конфигурирование кластера

Как настроить параметры конфигурации шлюза Ряд возможностей синхронизации и ClusterXL контролируются посредством параметров конфигурации шлюза безопасности. Выполните следующие команды на шлюзе безопасности:

fw ctl set int Parameter <value>

Parameter — это любой из параметров, описываемых в следующих разделах.

Изменения их значений по умолчанию должны осуществляться на всех элементах кластера. Настройка разных значений на элементах кластера может вызвать проблемы конфигурации и ошибки соединения.

Все эти параметры конфигурации шлюзов можно настроить таким образом, чтобы настройки сохранялись после перезагрузки. Способ настройки зависит от операционной системы.



Как сконфигурировать шлюз, чтобы настройки сохранялись после перезагрузки Параметры конфигурации шлюза, измененные с помощью команды fw ctl set int, не сохраняются после

перезагрузки. Способ их настройки с сохранением после перезагрузки зависит от операционной системы. В следующих инструкциях под термином Parameter понимается любой из параметров, описываемых в следующих разделах.

Linux/SecurePlatform 1. Отредактируйте файл $FWDIR/boot/modules/fwkern.conf.

2. Добавьте строку Parameter=<value in hex>.

3. Выполните перезагрузку.

Windows 1. Отредактируйте реестр.

2. Добавьте значение DWORD с именем Parameter под ключом HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FW1\Parameters\Globals.

3. Выполните перезагрузку.

Настройка модульных переменных в IPSO 6.1 и последующих версиях При первой установке IPSO или запуске Voyager на новой платформе страница конфигурирования Firewall Kernel Tuning (Настройка ядра брандмауэра) не отображается. Если представитель службы по работе с клиентами советует использовать эту страницу, вам нужно сначала вывести ее на экран, выполнив следующие действия:

1. Установите соединение командной строки с платформой (с помощью сетевого соединения или соединения консоли).

2. По подсказке оболочки IPSO введите nokia[admin]# dbset advanced:loader t

3. Запустите Voyager (или закройте Voyager и снова запустите его, если при вводе предыдущей команды Voyager был открыт).

4. Щелкните Configuration > Tools > Firewall Kernel Tuning (Конфигурирование > Инструменты > Настройка ядра брандмауэра) в навигационном дереве.

5. Настройте переменные согласно инструкциям службы поддержки и щелкните Apply (Применить). Щелчком по Apply вы применяете переменные ядра брандмауэра, а также сохраняете конфигурацию Voyager, так что в случае перезагрузки платформы страница конфигурирования Firewall Kernel Tuning снова появится на экране.

Управление таймерами кластеризации и синхронизации Для управления таймерами кластеризации и синхронизации применяются следующие параметры конфигурации шлюза: Изменение значений, заданных по умолчанию, не рекомендуется.

Таймеры кластеризации и синхронизации

Параметр Значение Значение по умолчанию

fwha_timer_cpha_res Периодичность выполнения операций ClusterXL на кластере.

Операции происходят через каждые: 10 миллисекунд, помноженные на fwha_timer_cpha_res, помноженные на fwha_timer_base_res

1



Параметр Значение Значение по умолчанию

fwha_timer_sync_res Периодичность выполнения операций передачи синхронизации на кластере.

Операции происходят через каждые: 10 миллисекунд, помноженные на fwha_timer_sync_res, помноженные на fwha_timer_base_res

1

fwha_timer_base_res Должно делиться на 10 без напоминаний. 10

Блокировка новых соединений при нагрузке Причина блокировки новых соединений заключается в том, что новые соединения являются главным источником нового трафика синхронизации и синхронизация может быть подвержена риску, если новый трафик будет дальше обрабатываться с такой скоростью.

Соответствующее сообщение об ошибке имеет следующий вид: "FW-1: State synchronization is in risk. Please examine your synchronization network to avoid further problems!" (Синхронизация состояний подвержена опасности. Проверьте сеть синхронизации во избежание дальнейших проблем!) (См. "Сообщения об ошибках, связанные с синхронизацией" на стр. 68).

Уменьшение объема трафика, передаваемого через шлюз безопасности, позволяет защитить механизм синхронизации.

fw_sync_block_new_conns обеспечивает обнаружение шлюзом безопасности высокой нагрузки и

инициирование блокировки новых соединений. Нагрузка считается высокой, когда очередь на передачу синхронизации на брандмауэре превышает порог fw_sync_buffer_threshold.

Чтобы активировать обнаружение нагрузки, установите значение на 0.

Чтобы отключить обнаружение нагрузки, установите значение на -1 (0xFFFFFFFF hex) (значение по умолчанию).

Обратите внимание, что блокировка новых соединений при занятой синхронизации рекомендуется только для развернутых систем ClusterXL в режиме Load Sharing. Хотя в режиме High Availability блокировка новых соединений возможна, она не устраняет проблему противоречий синхронизации, так как режим High Availability этого не допускает. Этот параметр можно настроить на сохранение после перезагрузки с помощью механизма, описанного в разделе "Как сконфигурировать шлюз, чтобы настройки сохранялись после перезагрузки" (на стр. 87).

fw_sync_buffer_threshold означает, насколько процентов может быть заполнен буфер, прежде чем будут заблокированы новые соединения. По умолчанию он установлен на 80 при размере буфера 512. По умолчанию в случае отправки более 410 последовательных пакетов без получения подтверждения на любой из них новые соединения сбрасываются. Когда начинается блокировка, значение fw_sync_block_new_conns устанавливается на 1. Когда ситуация стабилизируется, оно снова устанавливается на 0.

fw_sync_allowed_protocols используется для определения типа соединений, которые могут открываться, когда система находится в состоянии блокировки. Таким образом, пользователь получает больше контроля за поведением системы в случае нетипичной загрузки. Переменная fw_sync_allowed_protocols представляет собой комбинацию флагов, каждый из которых определяет один тип соединения. Необходимое значение переменной рассчитывается сложением отдельных значений этих флагов. Например, значение по умолчанию этой переменной равно 24, что является суммой TCP_DATA_CONN_ALLOWED (8) и UDP_DATA_CONN_ALLOWED (16), т.е. по умолчанию при нагрузке допускается открытие только информационных соединений TCP и UDP.

ICMP_CONN_ALLOWED 1

TCP_CONN_ALLOWED 2 (кроме информационных соединений)

UDP_CONN_ALLOWED 4 (кроме информационных соединений)

TCP_DATA_CONN_ALLOWED 8 (управляющее соединение должно быть установлено или разрешено)



UDP_DATA_CONN_ALLOWED 16 (управляющее соединение должно быть установлено или разрешено)

Работа со SmartView Tracker в активном режиме При активном режиме в SmartView Tracker отображаются соединения, открытые на любом из шлюзов безопасности в данный момент времени и отправляющие журналы в активный файл регистрации на сервере управления безопасностью.

Активный режим обычно замедляет процесс синхронизации. В этом случае для поддержания синхронизации механизм синхронизации сбрасывает обновления активного соединения случайным образом. Сброс сопровождается одним из сообщений об ошибках, рассмотренных в разделе "Сообщения в активном режиме SmartView Tracker".

Представление активного режима не рекомендуется использовать на сильно загруженном кластере. Для получения более точного отчета об активных соединениях при нагрузке предусмотрено два решения. Они относятся как к кластеру, так и к отдельному шлюзу безопасности:

1. Увеличьте fwlddist_buf_size

Параметр fwlddist_buf_size отражает размер буфера синхронизации в словах (Слова используются как для синхронизации, так и в активном режиме SmartView Tracker. 1 слово равно 4 байтам). По умолчанию задан размер в 16 тыс. слов. Максимальное значение составляет 64 тыс. слов, а минимальное значение — 2 тыс. слов.

В случае изменения этого параметра настройте его так, чтобы он сохранился после перезагрузки, потому что изменение применяется только после перезагрузки. Для этого воспользуйтесь механизмом, рассмотренным в разделе "Как сконфигурировать шлюз, чтобы настройки сохранялись после перезагрузки" (на стр. 86).

2. Получите хотфикс от службы технической поддержки

Получите хотфикс от службы технической поддержки Check Point. Этот хотфикс содержит переменную, контролирующую скорость, при которой fwd считывает активные компоненты на шлюзе перед их отправкой на сервер управления безопасностью. Обратите внимание, что для этого решения требуются дополнительные ресурсы ЦП.

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

Чтобы выяснить, выпускаются или нет удерживаемые пакеты, выполните команду fw ctl pstat. Если в выводе команды отражается большое значение Number of Pending Packets (Количество ожидающих пакетов) при нормальной нагрузке (более 100 ожидающих пакетов) и оно со временем не уменьшается, уменьшите количество ожидающих пакетов с помощью параметра fwldbcast_pending_timeout.

Измените параметр fwldbcast_pending_timeout со значения по умолчанию, равного 50, на значение меньше 50.

Значение выражается в тактах (тиках), при этом каждый такт равен 0,1 с, т.е. 50 тактов соответствует 5 секундам.

Это значение представляет время, по истечении которого пакеты выпускаются, даже если не получены подтверждения синхронизации.

Настройка дополнительных опций полной синхронизации Когда элемент кластера включается после перезагрузки (или после cpstart), он должен выполнить полную синхронизацию. На первом этапе процесса синхронизации он выполняет квитирование с одним из других активных элементов кластера. При этом процесс полной синхронизации может быть продолжен только в случае успешного завершения квитирования.

При выполняемом детальном квитировании (по умолчанию) между элементами кластера осуществляется обмен информацией. Эта информация включает информацию о версии, установленных продуктах Check Point и может включать информацию о том, какие таблицы ядра VPN в данный момент являются активными. Детальное квитирование не имеет отношения к обмену информацией о таблицах ядра, который осуществляется в дальнейшем при полной синхронизации.

На всех элементах кластера должны быть установлены одинаковые продукты и версии Check Point. Детальное квитирование отмечает, когда на элементах кластера установлены разные продукты. Когда установлены разные продукты, появляется предупреждение на консоли и сообщение в журнале регистрации.



Для поддержки обратной совместимости можно изменить принцип детального квитирования посредством следующих параметров конфигурации шлюза. Порядок изменения этих параметров рассмотрен в разделе "Дополнительное конфигурирование кластера" (на стр. 86):

fw_sync_no_ld_trans по умолчанию имеет значение 1. Установите его на 0, чтобы обмен информацией о таблицах ядра осуществлялся между элементами на первом этапе процесса полной синхронизации.

fw_sync_no_conn_trans по умолчанию имеет значение 0. Установите его на 1, чтобы на первом этапе

процесса полной синхронизации между элементами не осуществлялся обмен информацией об установленных продуктах.

fw_sync_fcu_ver_check по умолчанию имеет значение 1. Установите его на 0, чтобы разрешить полное обновление подключений для версий, не отвечающих требованиям, указанным в "Руководстве по установке и обновлению R75.40VS" (http://supportcontent.checkpoint.com/solutions?id=sk76540).

Определение отключенных интерфейсов Отключенные интерфейсы — это интерфейсы элементов кластера, не контролируемые механизмом ClusterXL.

По желанию вы можете определить интерфейс как отключенный, если он не работает в течение долгого времени, а вам нужно, чтобы элемент кластера оставался активным.

Ниже перечислены процессы, которые аналогичны определению неконтролируемого интерфейса на странице Topology, за исключением того, что метод GUI (Графический пользовательский интерфейс) работает только для интерфейсов, имеющих заданный IP-адрес.

Определение отключенного интерфейса в Unix Создайте файл в $FWDIR/conf/discntd.if и введите в отдельную строку имя каждого интерфейса,

который ClusterXL не должен контролировать.

Определение отключенного интерфейса в Windows 1. Откройте редактор реестра regedt32. Не используйте regedit.

2. В HKEY_LOCAL_MACHINES\System\CurrentControlSet\Services\CPHA создайте новое значение со следующими характеристиками:

Value Name (Имя значения): DisconnectedInterfaces

Data Type (Тип данных): REG_MULTI_SZ

3. Добавьте имя интерфейса. Чтобы получить имя системы интерфейса, выполните команду:

fw getifs

4. Добавьте это имя в список отключенных интерфейсов в следующем формате: \устройство\<Имя системы интерфейса>

5. Выполните команду cphastop, а затем cphastart, чтобы применить изменение.

Настройка тайм-аута обновления политики При установке политики на кластере шлюзов элементы кластера осуществляют процесс согласования, чтобы установить, все ли они получили одинаковую политику, прежде чем фактически ее применять. Этот процесс согласования снабжен механизмом тайм-аута, который предотвращает бесконечное ожидание элементом кластера ответов от других элементов кластера, что полезно в ситуациях, когда другой элемент выходит из строя при установке политики (например).

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

Вы можете точно настроить тайм-аут, установив следующий параметр:

fwha_policy_update_timeout_factor.

По умолчанию его значение равно 1, что достаточное для большинства конфигураций. Для конфигураций, в которых существует одна из вышеописанных ситуаций, достаточно установки этого параметра на 2. НЕ устанавливайте этот параметр на значение более 3.




Расширенное применение трехэтапного TCP-квитирования

При стандартном применении трехэтапного квитирования, инициирующего соединение TCP, достаточно высокая степень безопасности гарантируется путем обеспечения односторонней привязки. То есть оно гарантирует, что подтверждение синхронизации SYN-ACK всегда будет приходить после синхронизации SYN. Однако оно не гарантирует, что подтверждение ACK всегда будет приходить после подтверждения синхронизация SYN-ACK или что первый пакет данных придет после такого подтверждения.

Если вы хотите иметь более строгую политику, вообще не допускающую пакетов, не соответствующих таблице состояний, вы можете настроить механизм синхронизации таким образом, чтобы все пакеты, инициирующие соединение TCP, поступали в правильном порядке (SYN, SYN-ACK, ACK, затем данные). Ценой такой дополнительной безопасности является значительная задержка при установлении соединения.

Чтобы активировать расширенное применение, измените свойство sync_tcp_handshake_mode с minimal_sync (значение по умолчанию) на complete_sync с помощью инструмента Database Tool.

Настройка адресов кластера в разных подсетях

Об адресах кластера в разных подсетях IP-адреса кластера представляют собой виртуальные IP-адреса, присвоенные объектам ClusterXL и отличающиеся от уникальных IP-адресов отдельных машин кластера. Эти адреса позволяют принимать кластер за один шлюз, благодаря чему он может выполнять функции маршрутизатора в сети, не знакомой с внутренней структурой и состоянием кластера.

В предыдущих версиях IP-адреса кластера приходилось настраивать в тех же подсетях, которые использовались уникальными адресами элементов кластера. Теперь IP-адреса кластера могут находиться в других подсетях, нежели адреса элементов. Это дает следующие преимущества:

Возможность заменить одномашинный шлюз в предварительно сконфигурированной сети многомашинным кластером без необходимости в присвоении новых адресов элементам кластера.

Организации имеют возможность использовать всего один маршрутизируемый адрес для кластера шлюзов ClusterXL.

Примечание: эта возможность существует только в кластерах шлюзов ClusterXL. Подробности о кластерах, имеющих сертификат OPSEC, см. в документации поставщика.

Важно, что при этом пакеты, отправляемые с элементов кластера (в отличие от пакетов, направляемых через элементы), скрыты за IP- и MAC-адресами кластера. MAC-адрес кластера представляет собой:

MAC-адрес активной машины в режиме High Availability New.

Групповой MAC-адрес в режиме Load Sharing Multicast.

MAC-адрес главного элемента в режиме Load Sharing Unicast.

Это позволяет элементам осуществлять связь с окружающими сетями, но и накладывает определенные ограничения, которые рассматриваются в разделе "Ограничения при настройке адресов кластера в разных подсетях" (на стр. 93).

Настройка адресов кластера в разных подсетях Для обеспечения правильного функционирования ClusterXL c IP-адресами кластера в разных подсетях необходимо выполнить два главных шага.

Первым шагом является создание на каждом элементе кластера статических маршрутов, которые определяют интерфейс, подключенный к сети кластера (подсети, которой принадлежит IP кластера). Без создания этих записей ОС не сможет направлять пакеты в сеть кластера. Дополнительного конфигурирования элементов кластера не требуется. Однако важно отметить, что уникальные IP-адреса, присвоенные элементам, должны использовать общие подсети на каждой "стороне" кластера (т.е. каждый интерфейс на каждой машине должен иметь интерфейс на каждой другой машине, использующей такую же подсеть).

Второй шаг связан с конфигурированием топологии кластера. Здесь происходит определение IP-адресов кластера и их ассоциирование с интерфейсами элементов кластера (каждый элемент должен иметь интерфейс для ответа каждому IP кластера). Как правило, IP-адреса кластера ассоциируются с интерфейсом по принципу общей подсети. В данном случае это разные подсети. Необходимо точно определить, какая подсеть элемента ассоциируется с IP кластера.



Для определения сети элемента:

1. Выберите Topology в окне Gateway Cluster Properties.

2. Щелкните Edit Topology.

3. В окне Edit Topology вручную введите IP-адрес и подсеть в соответствующие поля интерфейса элемента.

Обратите внимание, что фактически этот интерфейс относится к виртуальному IP-адресу кластера, определенному в топологии кластера.

Пример адресов кластера в разных подсетях В данном примере необходимо заменить брандмауэр с одним шлюзом, отделяющий сеть 172.16.6.0 (Сторона "A") от сети 172.16.4.0 (Сторона "B"), кластером ClusterXL. При этом элементы кластера будут использовать сеть 192.168.1.0 в качестве стороны "A", сеть 192.168.2.0 в качестве стороны "B" и сеть 192.168.3.0 в качестве сети синхронизации (все сетевые адреса в данном примере относятся к классу "C"). Адреса, выделенные курсивом, представляют собой IP-адреса кластера. В результате конфигурация имеет следующий вид:

Настройка статических маршрутов на элементах Каждый элемент должен иметь два статических маршрута:

Один, определяющий его IP-адрес 192.168.1.x как шлюз для сети 172.16.6.0

Другой, определяющий его IP-адрес 192.168.2.x как шлюз для сети 172.16.4.0.

Для настройки статического маршрута на SecurePlatform выполните команду sysconfig в окне ввода команды, выберите Routing > Add New Network Route (Маршрутизация > Добавить новый сетевой маршрут) и выполните инструкции.

Настройка IP-адресов кластера на панели инструментов SmartDashboard

Для настройки IP-адресов интерфейсов кластера:

1. В окне Topology > Edit Topology (Топология > Изменить топологию) объекта — кластера шлюзов измените интерфейс кластера и откройте окно Interface Properties.

2. Для каждого интерфейса кластера настройте окно Interface Properties следующим образом:

Example ClusterXL Topology > Interface Properties (Пример топологии ClusterXL > Свойства интерфейса)

IP-адрес интерфейса кластера А

IP-адрес интерфейса кластера В

Вкладка General 172.16.6.100 172.16.4.100

Вкладка Member Networks 192.168.1.0 192.168.2.0

Все IP-адреса имеют сетевую маску 255.255.255.0

Сторона A

Сторона A

Сторона B

Сторона B Сторона A

Сторона B

Элемент 2

Элемент 1

Интерфейс кластера

Интерфейс кластера



Примечание: не задавайте IP-адреса кластера для интерфейсов синхронизации. Интерфейсы синхронизации также определяются на странице Edit Topology объекта — кластера шлюзов.

Ограничения при настройке адресов кластера в разных подсетях Эта новая опция пока еще не поддерживает все возможности ClusterXL. Некоторые элементы для исправной работы требуют дополнительного конфигурирования, другие — не поддерживаются.

Возможность соединения между элементами кластера Поскольку ARP-запросы, создаваемые элементами кластера, скрыты за IP- и MAC-адресами кластера, запросы, отправленные одним элементом кластера другому элементу, могут быть проигнорированы машиной-адресатом. Для обеспечения связи элементов кластера друг с другом для каждого элемента кластера следует настроить статическую ARP-запись с указанием MAC-адресов всех других машин в кластере. IP-пакеты, отправляемые от одного элемента другому, не меняются, поэтому вносить изменения в таблицу маршрутизации не нужно.

Примечание: протокол синхронизации кластера не использует ARP, поэтому для исправной работы машин как кластера статической ARP-записи не требуется.

Режим Load Sharing Multicast, наполовину поддерживаемый аппаратным обеспечением Хотя не все типы сетевого аппаратного обеспечения работают с групповыми MAC-адресами, некоторые маршрутизаторы могут пропускать такие пакеты, даже если они не способны обработать ARP-ответы, содержащие групповой MAC-адрес. Когда маршрутизатор поддерживает режим Load Sharing Multicast наполовину, можно настроить MAC-адрес кластера как статическую ARP-запись во внутренних таблицах маршрутизатора, тем самым обеспечив его связь с кластером.

Когда для IP-адресов кластера используются разные подсети, статические ARP-записи, содержащие MAC-адрес маршрутизатора, должны быть настроены на каждом из элементов кластера. Это делается потому, что маршрутизатор такого рода не будет отвечать на ARP-запросы, содержащие групповой MAC-адрес источника. Данные специальные процедуры не требуются при использовании маршрутизаторов, полностью поддерживающих групповые MAC-адреса.

Ручная настройка ARP прокси-сервера При использовании статической NAT-трансляции кластер может быть настроен на автоматическое распознавание скрытых за ним хостов и создание от их имени ARP-ответов с указанием MAC-адреса кластера. Этот процесс называется автоматическим определением адреса прокси-сервера.

Однако в случае использования разных подсетей для IP-адресов кластера этот механизм не работает и вам необходимо настроить ARP прокси-сервера вручную. Для этого на панели инструментов SmartDashboard выберите Policy menu > Global Properties > NAT Network Address Translation (Меню политики > Общие свойства > Трансляция сетевых адресов NAT) и отключите опцию Automatic ARP Configuration (Автоматическая настройка ARP). Затем создайте файл под именем local.arp в директории конфигурации брандмауэра ($FWDIR/conf).

Каждая запись в этом файле представляет собой триплет, который включает:

публикуемый адрес хоста,

MAC-адрес, который необходимо ассоциировать с IP-адресом,

уникальный IP интерфейса, отвечающего на ARP-запрос.

В качестве MAC-адреса укажите групповой MAC-адрес кластера, заданный на отвечающем интерфейсе, если ваш кластер работает в режиме Load Sharing Multicast, или уникальный IP этого интерфейса, если ваш кластер работает в любом другом режиме.

Например, если хост 172.16.4.3 должен быть скрыт с помощью адреса 172.16.6.25 и кластер работает в режиме Load Sharing Multicast, добавьте следующую строку в файл local.arp элемента 1:

172.16.6.25 00:01:5e:10:06:64 192.168.1.1



Второй параметр в этой строке отражает групповой MAC-адрес IP-адреса кластера 172.16.6.100, через который будут поступать ARP-запросы для 172.16.6.25. На элементе 2 эта строка будет иметь следующий вид:

172.16.6.25 00:01:5e:10:06:64 192.168.1.2

Если кластер работает в режиме Load Sharing Unicast или High Availability, строки на элементе 1 и 2 будут записаны следующим образом:

172.16.6.25 00:A0:C9:E8:C7:7F 192.168.1.1

- и -

172.16.6.25 00:A0:C9:E8:CB:3D 192.168.1.2

где вторая запись в каждой строке является уникальным MAC-адресом соответствующего локального интерфейса.

Подключение к элементам кластера из сети кластера Поскольку уникальные IP можно выбрать произвольно, нет гарантии, что эти адреса будут доступны из подсети IP-адреса кластера. Для доступа к элементам через их уникальные IP вам необходимо настроить маршруты на машине, с которой осуществляется доступ, чтобы при этом IP кластера был шлюзом для подсети уникальных IP. В предыдущем примере 172.16.6.100 должен быть шлюзом для подсети 192.168.1.0.

Шлюз по умолчанию на SecurePlatform Выполните команду sysconfig > routing > add network route > add the routable network with its subnet (конфигурирование системы > маршрутизация > добавить сетевой маршрут > добавить маршрутизируемую сеть со своей подсетью) и выберите подходящий физический интерфейс в данном направлении.

Затем перейдите к routing > add default gateway (маршрутизация > добавить шлюз по умолчанию) и добавьте IP-адрес (маршрутизируемого) шлюза по умолчанию. Как правило, это IP-адрес маршрутизатора в одной из подсетей IP кластера.

Если опция different subnets (разные подсети) настроена на нескольких интерфейсах, повторите вышеописанную процедуру добавления сетевого адреса для всех этих интерфейсов. (Определение шлюза по умолчанию для других подсетей НЕ требуется.)

Антиспуфинг Если опция different subnets определена на интерфейсе, который не является внешним, IP кластера, заданный на вкладке Cluster Topology (Топология кластера), не должен иметь определение Network defined by interface IP and Net Mask (Сеть, определенная IP-адресом интерфейса и сетевой маской) на вкладке Topology окна Interface Properties интерфейса кластера. В этом случае необходимо добавить группу сетей, в которую входят как маршрутизируемая, так и немаршрутизируемая сеть, и определить антиспуфинг для данного интерфейса как specific (специальный) для сети с этой новой группой.

Переход от одного шлюза к кластеру ClusterXL В этом разделе представлен порядок добавления нового шлюза (машины "В") к автономному шлюзу безопасности (машине "А") с целью создания кластера.

Предварительным условием является наличие IP-адресов в количестве, равном числу новых элементов кластера. Если их нет, см. "Настройка адресов кластера в разных подсетях".

На одной машине-шлюзе Если на вашем автономном шлюзе для сервера управления безопасностью и шлюза используется одна машина:

1. Отделите сервер управления безопасностью от шлюза и разместите их на двух машинах.

2. Инициализируйте SIC на отделенном шлюзе (машине "A").

На машине "В" 1. Определите интерфейс на машине "В" для каждого предполагаемого интерфейса кластера и

интерфейс синхронизации на машине "А" с одной и той же подсетью. Если элементы существуют в разных подсетях, см. "Настройка адресов кластера в разных подсетях".

2. Установите шлюз безопасности на машине. Во время установки обязательно активируйте ClusterXL.



На панели инструментов SmartDashboard для машины "В" 1. Создайте объект ClusterXL.

2. На странице Cluster Members щелкните Add (Добавить) и выберите New Cluster Member (Новый элемент кластера).

3. Подключите машину "В" и определите ее топологию.

4. Определите сети синхронизации для кластера.

5. Определите топологию кластера. Во избежание изменения конфигурации сетевых устройств IP-адреса кластера должны быть идентичны адресам машины "А" на его предполагаемых интерфейсах кластера.

6. Установите политику на кластере, который на данный момент состоит только из машины "В".

На машине "А" 1. Отключите все предполагаемые интерфейсы кластера и синхронизации. Теперь новые соединения

открываются не через машину "А", а через кластер.

2. Измените адреса этих интерфейсов на какой-нибудь другой уникальный IP-адрес, находящийся в одной подсети с машиной "В".

3. Подключите каждую пару интерфейсов одной подсети с использованием выделенной сети. Теперь любые хосты или шлюзы, ранее подключенные к автономному шлюзу, должны быть подключены к обеим машинам посредством хаба/коммутатора.

Примечание: существует возможность синхронизации в глобальной компьютерной сети (WAN). Подробности см. в разделе "Синхронизация кластеров в глобальной компьютерной сети" (см. "Синхронизация кластеров в глобальной компьютерной сети» на стр. 15).

На панели инструментов SmartDashboard для машины "А" 1. Обновите топологию шлюза A либо вручную, либо щелкнув Get Topology (Получить топологию).

Если IP-адрес интерфейса управления был изменен, действие Get Topology выполнено не будет. В этом случае вручную измените главный IP-адрес на объекте-шлюзе и сохраните политику перед выполнением автоматического получения топологии.

2. На странице Cluster Members щелкните Add и выберите Add Gateway to Cluster (Добавить шлюз в кластер).

3. Выберите машину "А" в окне.

4. На странице Edit Topology определите, какой интерфейс является интерфейсом кластера, а какой является внутренним или внешним интерфейсом.

5. Установите политику на кластере.

Добавление элемента в существующий кластер 1. На элементе кластера выполните команду cpconfig для активации ClusterXL.

2. Измените IP-адреса нового элемента кластера так, чтобы он отражал правильную топологию (либо совместно используемые IP-адреса, либо уникальные IP-адреса в зависимости от решения кластеризации).

3. Проверьте, все ли необходимые продукты Check Point установлены на новом элементе кластера.

4. На странице Cluster Members объекта — кластера шлюзов либо создайте новый элемент кластера (если это новая машина — шлюз безопасности) с соответствующими свойствами, либо преобразуйте существующий шлюз в элемент кластера.

5. Если это новая машина — шлюз безопасности, обязательно инициализируйте SIC. На странице Edit Topology проверьте правильность определения топологии.

6. Если режим кластера Cluster Mode имеет значение Load Sharing или New HA, определите соответствующие интерфейсы на новом элементе кластера как Cluster Interfaces (Интерфейсы кластера).


8. Теперь новый элемент входит в состав кластера.



Настройка ISP-резервирования на кластере Если вы используете кластер шлюзов ClusterXL Gateway, подключите каждый элемент кластера к обоим ISP посредством локальной вычислительной сети с двумя интерфейсами. Специфическая для кластера конфигурация представлена на рисунке ниже.

Обратите внимание, что интерфейсы элемента должны находиться в одной подсети с внешними интерфейсами кластера. Настройте ClusterXL обычным способом

Сервер SmartCenter,

расположенный где угодно

Внутренняя сеть

ЛВС

Адрес ISP-канала А:


Элементы кластера

Сеть синхронизации

Элемент A

Имя: Gateway_Cluster

(Все сетевые маски: 255 255 255 0. . . )

Сеть 192.168.1.0

Задача: Кластер

IP кластера: 192.163.1.100

Элемент A: 192.168.1.3

Элемент B: 132.163.1.2

Топология: Внешняя сеть

Сеть 172.16.2.0


IP кластера: 172.16.2.100

Элемент A: 172.16.2.2

Элемент B: 172.16.2.3

Топология: Внешняя сеть

Сеть 10.10.0.0


IP кластера: 10.10.0.100

Элемент A: 10.10.0.1

Элемент В: 10.10.0.2

Топология: Внутренняя сеть

Сеть 10.0.10.0

Задача: 1-я синхронизация

Элемент A: 10.0.10.1

Элемент B: 10.0.10 2

Топология: Внутренняя сеть

Адрес ISP-канала : B


Элемент B



Внешняя сеть

Интернет



Активация протоколов динамической маршрутизации в развернутом кластере

ClusterXL поддерживает протоколы динамической маршрутизации (одноадресной и многоадресной) как неотъемлемую часть SecurePlatform. Поскольку сетевая инфраструктура принимает шлюз кластера за один логический объект, отказ элемента кластера будет прозрачен для сетевой инфраструктуры и не вызовет волновой эффект.

Компоненты системы

Интегрирование виртуальных IP На всех элементах кластера используется один или несколько IP-адресов кластера.

Синхронизация таблицы маршрутизации Информация о маршрутизации синхронизируется между элементами кластера с помощью диспетчера базы данных FIB. Это позволяет избежать прерывания трафика в случае аварийного переключения и используется в режимах Load Sharing и High Availability. За информацию о маршрутизации отвечает диспетчер FIB.

Диспетчер FIB зарегистрирован в качестве критического устройства (Pnote), и если ведомый элемент выпадет из синхронизации, то будет создано Pnote и ведомый элемент выйдет из строя, пока диспетчер FIB не будет синхронизирован.

Восстановление после отказа Динамическая маршрутизация в ClusterXL позволяет избежать волнового эффекта при аварийном переключении благодаря информированию соседних маршрутизаторов о выходе маршрутизатора из режима поддержки. Соседние маршрутизаторы переустанавливают свои отношения с кластером, не информируя другие маршрутизаторы в сети. Эти протоколы перезапуска широко применяются всеми крупными сетевыми поставщиками. В следующей таблице перечислены запросы на отзывы RFC и проекты, соответствующие динамической маршрутизации Check Point:

Совместимые протоколы

Протокол RFC или проект

OSPF LLS draft-ietf-ospf-lls-00

OSPF Graceful restart RFC 3623

BGP Graceful restart draft-ietf-idr-restart-08

Динамическая маршрутизация в ClusterXL Вышеперечисленные компоненты функционируют скрытым путем. При настройке динамической маршрутизации в ClusterXL протоколы маршрутизации автоматически устанавливают связь с кластером, как они могли бы это сделать с отдельным устройством.

При настройке протоколов маршрутизации на каждом элементе кластера каждый элемент определяется одинаково и использует один или несколько IP-адресов кластера (не физический IP-адрес элемента). В случае с OSPF необходимо определить идентификатор маршрутизатора, который должен быть одинаковым на каждом элементе кластера. При настройке перезапуска OSPF необходимо определить тип перезапуска как signaled (по сигналу) или graceful (плавный). Для устройств Cisco используется тип signaled.

Для настройки каждого элемента кластера используйте интерфейс командной строки SecurePlatform.



Активация OSPF на элементе кластера А

Такая же конфигурация должна быть применена к каждому элементу кластера.

Поскольку диспетчер FIB для синхронизации информации о маршрутизации использует TCP 2010, политика безопасности должна принимать весь трафик на порте TCP 2010 между элементами кластера.

Подробную информацию о динамической маршрутизации см. в "Справочном руководстве по интерфейсу командной строки расширенного пакета маршрутизации R75.40VS" (http://supportcontent.checkpoint.com/solutions?id=sk76540).



Приложение А

Режим High Availability Legacy

В этом приложении

О режиме High Availability Legacy 99

Пример развернутой системы в режиме совместимости 100

Факторы, учитываемые при планировании 101

Настройка режима High Availability Legacy 101

Переход с High Availability Legacy при минимуме усилий 103

Переход с High Availability Legacy с минимизацией простоя 104

О режиме High Availability Legacy Когда элементы кластера настроены на работу в режиме High Availability Legacy (Высокая доступность в режиме совместимости), всем им присваиваются одинаковые общие IP- и MAC- адреса. Общий интерфейс — это интерфейс, MAC- и IP-адреса которого идентичны адресам другого интерфейса.

Главное преимущество использования этого режима заключается в том, что для перехода от системы с одним шлюзом к кластеру High Availability не требуется изменять IP-адреса или маршрутизацию. К интерфейсам кластера может подключиться любой коммутатор или хаб. Недостатком является сложность настройки этого режима, которая должна выполняться в строгой последовательности. Необходимо подключить сервер управления безопасностью либо к сети синхронизации кластера, либо к выделенной сети управления.



Пример развернутой системы в режиме совместимости В данном примере представлена типичная развернутая система в режиме High Availability Legacy. Схема связывает физическую топологию кластера с необходимой конфигурацией SmartDashboard. На ней изображены два элемента кластера: Элемент_A (первичный) и элемент_B (вторичный), у каждого из которых есть три интерфейса: один для синхронизации, другой — внешний общий, третий — внутренний общий.

Настройка IP- и MAC-адресов общих интерфейсов С режимом High Availability Legacy интерфейсы элементов, подключенные к одной сети (внутренней, внешней, DMZ и т.д.), совместно используют общие IP- и MAC-адреса. Каждый общий интерфейс на элементах кластера подключен к соответствующей сети посредством хаба или коммутатора.

В любой данный момент времени активен только один элемент кластера. Поэтому извне в любой данный момент времени можно видеть только общие интерфейсы на одном элементе.

В вышеприведенном примере развернутой системы внешний интерфейс (выходящий в Интернет) использует общий IP-адрес 192.168.0.1 как для элемента A, так и для элемента B. Внутренний интерфейс (выходящий в локальную сеть) использует IP-адрес 172.20.10.1 как для элемента A, так и для элемента B.

Интерфейс синхронизации Синхронизация состояний между элементами кластера обеспечивает сохранение существующих соединений, обрабатываемых отказавшим элементом, во время и после аварийного переключения. Сеть синхронизации пропускает информацию о синхронизации соединений и другую информацию о состояниях между элементами кластера. Поскольку эта сеть переносит ценную информацию о политике безопасности, важно, чтобы соединение было защищенным. Вы можете определить несколько сетей синхронизации для целей резервирования.

Для защиты интерфейсов синхронизации их следует подключить напрямую кросс-кабелем, а в кластере с тремя и более элементами посредством выделенного хаба, коммутатора или VLAN.

Элементы кластера High Availability синхронизировать необязательно. Однако если они не синхронизированы, во время аварийного переключения активные соединения могут быть потеряны.

Элементы кластера


Элемент B

Элемент A

Сервер управления безопасностью

Сервер управления безопасностью должен быть подключен к сети синхронизации или к выделенной сети управления

Интерфейс управления



Общий интерфейс




кластера




Факторы, учитываемые при планировании

Миграция IP-адресов Развернутые системы, работающие в режиме совместимости, допускают легкий переход с существующей конфигурации с автономным шлюзом на кластер High Availability. В таких случаях мы рекомендуем по возможности определить IP-адреса интерфейсов, существующих на автономном шлюзе безопасности, как адреса кластера. Это позволит избежать изменения идентификационных данных конечных точек IPSec и во многих случаях избавит от необходимости изменения конфигурации Hide NAT (Скрытая NAT-трансляция).

Расположение сервера управления безопасностью Сервер управления безопасностью загружает политики безопасности на все элементы кластера. Сервер управления безопасностью невозможно подключить к любой сети, подключенной к общим интерфейсам элемента, потому что эти интерфейсы настроены на использование одинаковых IP- и MAC-адресов.

Сервер управления безопасностью должен быть подключен к сети синхронизации кластера или к выделенной сети управления, так как в этом случае у элементов будут уникальные IP-адреса.

Настройка маршрутизации Настройте маршрутизацию таким образом, чтобы между внешней сетью и внутренними сетями существовала возможность маршрутизации.

Например, в примере развернутой системы (см. "Пример развернутой системы в режиме совместимости" на стр. 100) показана следующая настройка маршрутизации:

Внутренние сети определены с использованием 172.20.0.1 в качестве шлюза по умолчанию.

Внешний маршрутизатор настроен со статическим маршрутом, на котором сеть 172.20.0.1 достигается через 192.168.10.1.

Коммутаторы (передача 2-го уровня) как влияющий фактор Протокол управления кластером (CCP) использует групповой адрес 2-го уровня. В соответствии со стандартами многоадресной передачи этот групповой адрес используется только в качестве адреса назначения и используется во всех CCP-пакетах, отправляемых на "незащищенных" интерфейсах.

Коммутатор 2-го уровня, подключенный к незащищенным интерфейсам, должен быть способен передавать многоадресные пакеты на порты коммутатора или внутри VLAN-сети, если это VLAN-коммутатор. Допускается передача этим коммутатором такого трафика на все порты или на порты внутри данной VLAN. Однако более эффективной считается передача данных только на порты, соединяющие элементы кластера.

Большинство коммутаторов поддерживают многоадресную передачу данных по умолчанию. Узнайте подробности в документации по своему коммутатору.

Если коммутатор не способен на многоадресную передачу данных, CCP можно изменить на использование широковещания.

Для переключения между эти двумя режимами:

Используйте команду: 'cphaconf set_ccp broadcast/multicast'

Настройка режима High Availability Legacy 1. Получите и установите центральную лицензию ClusterXL на ваш сервер управления безопасностью.

2. Отключите шлюзы безопасности, которые хотите использовать в качестве элементов кластера, от коммутаторов и/или хабов.

3. Присвойте одинаковые IP-адреса общим интерфейсам на каждом элементе. Для предотвращения сетевых конфликтов из-за совместного использования MAC-адресов задайте IP-адреса до физического подключения элементов к топологии кластера.

4. Установите и настройте шлюз безопасности Check Point на всех элементах кластера. Каждый элемент должен использовать одинаковую версию и сборку. См. "Руководство по установке и обновлению R75.40VS" (http://supportcontent.checkpoint.com/solutions?id=sk76540).

Не перезагружайте элементы на данном этапе.




5. Подключите (или подключите повторно) элементы к их коммутаторам и хабам. Обязательно подключите каждый интерфейс к соответствующему физическому сетевому порту. Подключите каждую сеть (внутреннюю, внешнюю, сеть синхронизации, DMZ и т.д.) к отдельной VLAN-сети, коммутатору или хабу. Специального конфигурирования коммутаторов не требуется.

Настройка маршрутизации 1. Настройте маршрутизацию таким образом, чтобы связь с сетями, находящимися на внутренней

стороне кластера, осуществлялась через IP-адрес кластера, находящийся на внешней стороне кластера. Например, в примере развернутой системы (см. "Пример развернутой системы в режиме совместимости" на стр. 100) внешний маршрутизатор настроен как статический маршрут, на котором сеть 10.255.255.100 достигается через 192.168.10.100.

2. Настройте маршрутизацию таким образом, чтобы связь с сетями, находящимися на внешней стороне кластера, осуществлялась через IP-адрес кластера, находящийся на внутренней стороне кластера. Например, в примере развернутой системы (см. "Пример развернутой системы в режиме совместимости" на стр. 100) в качестве шлюза по умолчанию портов внутреннего маршрутизатора указан 10.255.255.100.

3. Перезагрузите элементы. Настройка MAC-адресов произойдет автоматически.

Конфигурация SmartDashboard 1. В дереве Network Objects щелкните правой кнопкой мыши по Check Point и выберите Security

Cluster.

2. В окне Security Gateway Cluster Creation выберите Classic Mode (Классический режим).

3. На странице Cluster Members щелкните Add > New Cluster Member, чтобы добавить элементы в кластер. Элементы кластера существуют только внутри объекта — кластера шлюзов. Для каждого элемента кластера:

a) На вкладке General окна Cluster Members Properties задайте имя в поле Name и IP-адрес в поле IP Address. Выберите IP-адрес с возможностью маршрутизации с сервера управления безопасностью — это нужно для успешной установки политики безопасности. Это может быть внутренний или внешний адрес или выделенный интерфейс управления.

b) Щелкните Communication и инициализируйте защищенную внутреннюю связь (SIC).

c) Выполните нужные настройки на вкладках NAT и VPN.

d) Вы также можете добавить существующий шлюз в качестве элемента кластера, выбрав Add > Add Gateway to Cluster на странице Cluster Members и выбрав шлюз из списка в окне Add Gateway to Cluster.

e) Если вы хотите удалить шлюз из кластера, щелкните Remove на странице Cluster Members и выберите Detach Member from Cluster или щелкните правой кнопкой мыши по элементу кластера в дереве Network Objects и выберите Detach from Cluster.

4. На странице ClusterXL

Выберите High Availability Legacy Mode (Высокая доступность в режиме совместимости),

При необходимости выберите Use State Synchronization. Эта опция отмечена по умолчанию. Если вы сняли с нее галочку, элементы кластера не будут синхронизироваться и в случае аварийного переключения существующие соединения на отказавшем шлюзе будут закрыты.

Укажите действие Upon Gateway Recovery, выполняемое при восстановлении шлюза, (подробнее см. в разделе "Что происходит при восстановлении шлюза?" на стр. 29).

Определите метод Fail-over Tracking.

5. На странице Topology задайте адреса элементов кластера. Не определяйте виртуальные интерфейсы кластера. При переключении с другого режима кластера заданные виртуальные интерфейсы кластера удаляются. В окне Edit Topology:

Определите топологию для каждого интерфейса элемента кластера. Чтобы автоматически считать все предопределенные настройки на интерфейсах элементов, щелкните Get all members' topology (Получить топологию всех элементов).

В столбце Cluster (Кластер) определите цель сети, выбрав одну из опций из выпадающего списка. Определите интерфейсы с общими IP-адресами как принадлежащие сети Monitored Private (Частная контролируемая сеть) и определите один или несколько интерфейсов каждого элемента кластера как интерфейс синхронизации в сети синхронизации (1st Sync/2nd Sync/3rd Sync). Описание этих опций приведено в интерактивной справке. Чтобы определить новую сеть, щелкните Add Network.

6. Установите нужные настройки на других страницах объекта — кластера шлюзов (NAT, VPN, Remote Access и т.д.).




8. Перезагрузите все элементы кластера, чтобы активировать настройку MAC-адресов на элементах кластера.

Настройка общих свойств Для настройки общих свойств кластера:

1. Введите уникальное имя для этого объекта-кластера в соответствующем поле.

2. Введите главный IP-адрес кластера.

3. Выберите ClusterXL как продукт, установленный на кластере.

4. Активируйте ClusterXL и по необходимости другие программные блейды сетевой безопасности.

Определение элементов кластера Для конфигурирования элемента кластера:

1. На странице Cluster Members щелкните Add > New Cluster Member.

2. На вкладке General окна Cluster Members Properties введите имя элемента в поле Name и физический IP-адрес с возможностью маршрутизации с сервера управления безопасностью в поле IP Address. Это может быть внутренний или внешний адрес или выделенный интерфейс управления.

3. Щелкните Communication и инициализируйте доверие для защищенной внутренней связи (SIC).

4. Установите нужные настройки NAT и VPN на соответствующих вкладках. Подробнее см. в "Руководстве администратора Security Management R75.40VS" (http://supportcontent.checkpoint.com/solutions?id=sk76540).

Добавление существующего шлюза в качестве элемента

Чтобы добавить существующий шлюз в качестве элемента кластера, выберите Add > Add Gateway to Cluster на странице Cluster Members и выберите шлюз из списка в окне Add Gateway to Cluster.

Удаление элемента

Чтобы удалить шлюз из кластера, щелкните Remove на странице Cluster Members и выберите Detach Member from Cluster или щелкните правой кнопкой мыши по элементу кластера в дереве Network Objects и выберите Detach from Cluster.

Настройка свойств ClusterXL Для настройки свойств ClusterXL для режима совместимости:

1. Активируйте опцию High Availability и выберите режим Legacy (Режим совместимости).

2. Выберите действие, выполняемое при восстановлении первичного элемента:

Maintain the current active cluster member (Оставить текущий активный элемент кластера)

Switch back to a higher priority cluster member (Переключиться на элемент кластера с более высоким приоритетом)

3. В развернутых системах High Availability New синхронизация состояний является опциональной, но по умолчанию активирована. Если вы решили отключить синхронизацию состояний, элементы кластера не синхронизируются и в случае аварийного переключения существующие соединения на отказавшем шлюзе будут прерваны.

4. Выберите опции отслеживания из списка.

Завершение процедуры определения 1. Установите нужные настройки на других страницах в объекте-кластере (NAT, VPN, Remote Access и пр.).


Переход с High Availability Legacy при минимуме усилий В этом разделе рассматривается порядок перехода с режима High Availability Legacy на режим Load Sharing Multicast или High Availability New, когда вам больше важна не минимизация простоя, а простота конфигурации.




Общие внутренние и внешние интерфейсы становятся интерфейсами кластера. Поэтому основной IP-адрес кластера остается внешним IP-адресом кластера.

На шлюзах 1. Выполните команду cpstop на всех элементах (все сетевые подключения будут потеряны).

2. Измените настройки IP-адресов на всех элементах кластера так, чтобы вместо общих (дубликатов) IP-адресов использовались уникальные IP-адреса.

Примечание: только для SecurePlatform: При изменении адресов все существующие статические маршруты будут удалены. Скопируйте их для восстановления в п. 4

3. Удалите общие MAC-адреса, выполнив команду: cphaconf uninstall_macs

4. Только для элементов кластера SecurePlatform: Переопределите статические маршруты, удаленные в п. 2.

5. Перезагрузите элементы.

На панели инструментов SmartDashboard На панели инструментов SmartDashboard откройте объект-кластер, выберите вкладку ClusterXL, измените режим кластера с Legacy mode на new mode или на Load sharing mode. Выполните инструкции мастера создания кластера шлюзов Check Point. Ручная настройка осуществляется в следующем порядке:

1. На вкладке Topology объекта-кластера

Получите интерфейсы, которые изменились с момента изменения IP-адресов, для каждого элемента кластера. Интерфейсы, которые ранее были общими, теперь должны быть определены как интерфейсы кластера.

Задайте IP-адреса кластера. Вы можете определить имена интерфейсов кластера по своему усмотрению, поскольку они будут связаны с физическими интерфейсами в соответствии с IP-адресами.

Если новые IP-адреса элементов кластера на конкретном интерфейсе находятся не в той подсети, в какой находится IP-адрес кластера в данном направлении, следует определить сеть элементов кластера в полях Members Network (Сеть элементов) интерфейса кластера (Настройка адресов кластера в разных подсетях).

2. Установите политику на новом объекте кластера (политика безопасности, QOS-политика и т.п.).

Переход с High Availability Legacy с минимизацией простоя

В этом разделе рассматривается порядок перехода с режима High Availability Legacy на режим High Availability New или Load Sharing с минимизацией простоя кластера.

Общие внутренние и внешние интерфейсы становятся интерфейсами кластера. Поскольку элементам кластера потребуются дополнительные IP-адреса, их необходимо подготовить заранее.

Если простой кластера во время изменения не большая проблема, рекомендуется использовать более простой процесс, рассмотренный в разделе "Переход от High Availability Legacy с приложением минимума усилий" (на стр. 103).

Примечание: 1. Перед началом выполнения описываемых здесь изменений

убедитесь, что у вас есть все нужные IP-адреса. 2. Перед началом этой процедуры создайте резервную копию настроек, потому что эта процедура приведет к удалению и восстановлению объектов на панели инструментов SmartDashboard.

В этой процедуре мы используем пример с машинами "A" и "B", где вначале машина "A" активна, а машина "B" находится в резерве.

1. Отключите машину "B" ото всех интерфейсов, кроме интерфейса, соединяющего ее с сервером управления безопасностью (интерфейса управления).

2. Выполните команду cphastop на машине "B".

3. Измените IP-адреса машины "В" (в соответствии с требованиями новой конфигурации).



Примечание: только для SecurePlatform: При изменении адресов все

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

4. Переопределите MAC-адреса на машине "B", выполнив команду cphaconf uninstall_macs. Если на машине установлена система Windows, то для вступления изменений в силу машину необходимо перезагрузить.

5. Только для элементов кластера SecurePlatform: Переопределите статические маршруты, удаленные в п. 3.

6. На панели инструментов SmartDashboard щелкните правой кнопкой мыши по элементу "A" и выберите Detach from cluster.

7. На вкладке Topology окна Cluster Member Properties определите топологию элемента кластера "B", щелкнув Get (Получить). Пометьте соответствующие интерфейсы как Cluster Interfaces (Интерфейсы кластера).

8. В Cluster Object (Объект-кластер) определите новую топологию кластера (определите интерфейсы кластера на вкладке Topology кластера).

9. На странице ClusterXL измените режим кластера High Availability с Legacy Mode на New Mode или выберите режим Load Sharing.

10. Проверьте правильность настроек на других страницах Cluster Object (NAT, VPN, Удаленный доступ и т.п.). В режиме Legacy Check Point High Availability настройки были заданы отдельно для каждого элемента кластера, теперь же они установлены на самом кластере.

11. Установите политику на кластере, который пока что состоит только из машины "В".

12. Снова подключите машину "B" (которую вы отключили в п. 1) к сетям.

13. В данном примере в состав кластера входят всего два элемента, но, если кластер состоит из трех и более элементов, повторите действия, указанные в пп. 1-9, для каждого элемента кластера.

14. Для режима Load Sharing Multicast настройте маршрутизаторы ("Режим Load Sharing Multicast" на стр. 31).

15. Отключите машину "А" ото всех сетей, кроме сети управления. При этом кластер прекратит обработку трафика.

16. Выполните команду cphastop на машине "А".

17. Выполните команду cpstop, а затем cpstart на машине "B" (если у вас больше двух машин, выполните

эти команды на всех машинах, кроме "A").

18. Теперь машина "В" активна и начинает обработку трафика.

19. Измените IP-адреса машины "А" (в соответствии с требованиями новой конфигурации).

20. Переопределите MAC-адреса машины "А", выполнив команду cphaconf uninstall_macs. Если на машине установлена система Windows, то для вступления изменений в силу машину необходимо перезагрузить.

21. На панели инструментов SmartDashboard откройте Cluster Object (Объект-кластер) и выберите страницу Cluster Members. Щелкните Add > Add Gateway to Cluster и выберите элемент "А", чтобы снова присоединить его к кластеру.

22. Снова подключите машину "А" к сетям, от которых она была отключена в п. 15.


24. Выполните команду cpstop, а затем cpstart на машине "A".

25. Переопределите статические маршруты.

Теперь кластер работает в новом режиме.


Приложение В

Пример скрипта cphaprob Скрипт clusterXL_monitor_process, представленный ниже, предназначен для контроля за наличием

данных процессов и инициирования аварийного переключения в случае их затухания. В нем используется

обычный механизм pnote.

Скрипт clusterXL_monitor_process находится в $FWDIR/bin.

В этом приложении

Дополнительная информация 106

Скрипт clusterXL_monitor_process 106

Дополнительная информация Команда cphaprob рассмотрена в разделе "Проверка исправной работы кластера" (на стр. 46).

Скрипт clusterXL_monitor_process

Пример скрипта cphaprob


Пример скрипта cphaprob


Алфавитный указатель

C

ClusterXL High Availability для IPv6 • 40 ClusterXL High Availability• 41

H

High Availability или Load Sharing • 29

L

Linux/SecurePlatform • 87

S

SmartView Monitor • 52 SmartView Tracker • 53

V

VPN-туннели со сторонними равноправными узлами и распределением нагрузки • 18

W

Windows • 87

A

Аварийное переключение • 28 Аварийное переключение агрегации • 79 Агрегирование каналов и кластеры • 77 Агрегирование каналов: режим High Availability •

78 Агрегирование каналов: режим Load Sharing • 81 Активация мониторинга состояния канала

интерфейса • 76 Активация протоколов динамической

маршрутизации в развернутом кластере • 96 Антиспуфинг • 94 Аппаратная совместимость ClusterXL • 31

Б

Блокировка новых соединений при нагрузке • 88

В

Важная информация • 3 Внесение изменений в MAC-адрес источника • 75 Внесение изменений в MAC-адрес назначения •

74 Возможность соединения между элементами

кластера • 93 Восстановление после отказа • 97 Выбор режима Load Sharing • 29 Выбор режима передачи CCP на элементах

кластера • 38 Вывод команды cphaprob [-reset] syncstat • 59 Выключение элемента кластера • 56 Высокая доступность и распределение нагрузки в

ClusterXL • 22

Д

Диагностика неполадок агрегированных

интерфейсов • 85 Диагностика проблем синхронизации • 58 Динамическая маршрутизация в ClusterXL • 97 Для 802.3ad: • 83 Для XOR: • 83 Добавление существующего шлюза в качестве

элемента • 39, 103 Добавление элемента в существующий кластер •

95 Дополнительная информация • 106 Дополнительное конфигурирование ClusterXL • 72 Дополнительное конфигурирование кластера • 86 Дубликаты MAC-адресов источника

Проблема • 76 Решение • 76

Дубликаты групповых MAC-адресов Проблема • 75 Решение • 75

Ж

Журналы регистрации Pnote • 54 Журналы регистрации SecureXL • 54 Журналы регистрации интерфейсов • 54 Журналы регистрации состояний • 53

З

Заблокированные пакеты • 62 Завершение процедуры определения • 40, 103 Задержки соединения на коммутаторах • 86 Запуск и выключение ClusterXL с помощью

SmartView Monitor • 52 Запуск элемента кластера • 56 Знакомство с ClusterXL • 8

И

Интегрирование виртуальных IP • 96 Интерфейс синхронизации • 100 Информирование ClusterXL о состоянии

критического устройства • 52 Использование мастера • 39

К

Как восстановленный элемент кластера получает политику безопасности • 29

Как инициировать аварийное переключение • 56 Как настроить параметры конфигурации шлюза •

86 Как присваивается MAC-адрес кластера

назначения в режиме Load Sharing Multicast • 74 Как присваивается MAC-адрес кластера-

источника • 75 Как работает ClusterXL • 8 Как работает State Synchronization • 13 Как сконфигурировать шлюз, чтобы настройки

сохранялись после перезагрузки • 87 Когда происходит аварийное переключение? • 28 Команда cphaconf • 55 Команда cphaprob • 46 Команда cphaprob в кластерах OPSEC • 45 Команды ClusterXL для агрегаций интерфейсов •

84 Команды cphastart и cphastop • 55 Команды cphastart и cphastop в кластерах OPSEC

• 45 Команды конфигурирования ClusterXL • 55 Коммутаторы (передача 2-го уровня) как

Страница 110

влияющий фактор • 101 Коммутаторы • 32 Компоненты системы • 96 Конфигурация SmartDashboard • 102 Конфигурация SmartDashboard для кластеров

OPSEC • 43 Конфигурирование ClusterXL • 37 Конфигурирование State Synchronization • 16 Конфигурирование VPN и кластеров • 72 Конфигурирование в классическом режиме • 39,

43 Конфигурирование кластеров IPv6 • 41 Конфигурирование коммутаторов Cisco для

работы в режиме Load Sharing • 82 Конфигурирование маршрутизации для машин-

клиентов • 37 Конфигурирование несинхронизируемого сервиса

• 16 Конфигурирование несинхронизируемых сервисов

• 13 Конфигурирование объектов и элементов

кластера • 38 Конфигурирование опции Sticky Decision Function •

20 Конфигурирование продуктов кластеризации,

имеющих сертификат OPSEC • 42 Конфигурирование синхронизации с ограничением

продолжительности • 17 Конфигурирование топологии кластера • 35, 40

Л

Лицензии на ClusterXL • 9 Локальные обновления • 61

М

Максимальная длина очереди на отправку • 62 Максимальное время удержания (такты) • 64 Маршрутизаторы • 32 Маршрутизирующий коммутатор • 32 Миграция IP-адресов • 30, 101 Мониторинг и диагностика неполадок кластеров

шлюзов • 46 Мониторинг интерфейсов кластера • 49 Мониторинг критических устройств • 50 Мониторинг синхронизации (fw ctl pstat) • 56 Мониторинг состояния канала интерфейса • 76 Мониторинг состояния кластера • 47 Мониторинг состояния кластера с помощью

клиентов SmartConsole • 52

Н

На машине "А" • 95 На машине "В" • 94 На одной машине-шлюзе • 94 На панели инструментов SmartDashboard • 104 На панели инструментов SmartDashboard для

машины "А" • 95 На панели инструментов SmartDashboard для

машины "В" • 95 На шлюзах • 104 Настройка IP- и MAC-адресов общих интерфейсов

• 100 Настройка IP-адресов кластера на панели

инструментов SmartDashboard • 92 Настройка ISP-резервирования на кластере • 96 Настройка NAT на кластере шлюзов • 73

Настройка NAT на элементе кластера • 73 Настройка адресов кластера в разных подсетях •

24, 91 Настройка адресов кластера в разных подсетях •

91 Настройка ведомых интерфейсов как

отключенных • 87 Настройка дополнительных опций полной

синхронизации • 89 Настройка критического минимума интерфейсов •

82 Настройка маршрутизации • 101, 102 Настройка модульных переменных в IPSO 6.1 и

последующих версиях • 87 Настройка общих свойств • 39, 103 Настройка привязок • 83 Настройка режима High Availability Legacy • 101 Настройка свойств ClusterXL • 39, 103 Настройка статических маршрутов на элементах •

92 Настройка статической ARP-записи на

маршрутизаторе • 33 Настройка тайм-аута обновления политики • 90 Не удержано в связи с отсутствием элементов •

64 Необходимость в кластерах • 8 Несинхронизированные пропущенные обновления

• 60 Несинхронизируемые сервисы • 13

О

О команде cphaprob [-reset] syncstat • 58 О продуктах кластеризации, имеющих сертификат

OPSEC • 42 О режимах High Availability и Load Sharing • 22 О режиме High Availability Legacy • 99 О соединениях с привязкой • 18 Об адресах кластера в разных подсетях • 91 Обновления других элементов • 59 Образец конфигурирования опции PortFast на

коммутаторе Cisco • 86 Обращение в службу технической поддержки • 66 Общее количество сгенерированных обновлений •

61 Общие журналы регистрации • 53 Общие сообщения об ошибках ClusterXL • 67 Общий обзор • 77 Ограничения при настройке кластера в разных

подсетях • 93 Ограничения синхронизации кластеров • 16 Определение IP-адресов элементов кластера • 23 Определение VLAN-сетей в агрегации

интерфейсов • 83 Определение агрегации интерфейсов • 80 Определение агрегации интерфейсов в режиме

Load Sharing • 82 Определение виртуальных IP-адресов кластера •

24 Определение отключенного интерфейса в Unix •

90 Определение отключенного интерфейса в

Windows • 90 Определение отключенных интерфейсов • 90 Определение равноправных кластеров VPN c

отдельными серверами управления безопасностью • 73

Определение статических CAM-записей • 32


Определение элементов кластера • 39, 103 Опции диагностики проблем синхронизации • 65 Опция Sticky Decision Function • 18 Особенности работы командной строки CPHA в

кластерах OPSEC • 44 Отказ запуска элемента после перезагрузки • 70 Отключение отправки многоадресных пакетов на

маршрутизатор • 33 Отключение отслеживания сетевого IGMP-

трафика • 32 Отмена регистрации критического устройства • 51 Отправленные запросы на повторную передачу •

59 Очереди • 65

П

Панель инструментов SmartDashboard • 10 Переконфигурирование тайм-аута подтверждения

• 66 Переход c High Availability Legacy при минимуме

усилий • 103 Переход c High Availability Legacy с минимизацией

простоя • 104 Переход от одного шлюза к кластеру ClusterXL •

94 Подготовка коммутаторов и конфигурирование

маршрутизации • 42 Подготовка машин — элементов кластера • 42 Подготовка элементов кластера • 37 Поддержка VLAN в ClusterXL • 74 Поддержка аварийного переключения для VLAN •

80 Подключение к элементам кластера из сети

кластера • 94 Подключение нескольких кластеров в одной VLAN

• 74 Полносвязное резервирование • 78 Полученные дубликаты запросов на повторную

передачу • 61 Полученные запросы на повторную передачу • 61 Порядок диагностики • 85 Порядок создания и настройки агрегации

интерфейсов в режиме Load Sharing • 81 Потерянное соединение синхронизации

(количество событий) • 60 Предупреждения в связи с использованием

PortFast • 86 Пример • 25, 26, 27 Пример адресов кластера в разных подсетях • 92 Пример конфигурации маршрутизирующего

коммутатора Cisco Catalyst • 32 Пример развернутой системы в режиме

совместимости • 100 Пример скрипта cphaprob • 52, 106 Пример соединения без привязки Трехэтапное

TCP-квитирование • 15 Пример топологии ClusterXL • 22 Примечания • 33 Проверка исправной работы агрегации • 80 Проверка исправной работы кластера • 46 Программная совместимость Check Point • 33 Протокол управления кластером • 9

Р

Работа с NAT и кластерами • 73 Работа с продуктами кластеризации, имеющими

сертификат OPSEC • 42 Работа с сетями VLAN и кластерами • 74 Работа с сетями VPN и кластерами • 72 Работа со SmartView Tracker в активном режиме •

89 Размер очереди на отправку • 65 Размер очереди на получение • 65 Расположение сервера управления

безопасностью • 101 Расширенное применение трехэтапного TCP-

квитирования • 91 Регистрация критических устройств,

перечисленных в файле • 51 Регистрация критического устройства • 51 Режим High Availability • 26 Режим High Availability Legacy • 99 Режим Load Sharing • 22 Режим Load Sharing Multicast • 25, 31 Режим Load Sharing Multicast, наполовину

поддерживаемый аппаратным обеспечением • 93

Режим Load Sharing Unicast • 25 Режимы ClusterXL • 24 Режимы HA New и Load Sharing Unicast • 30 Рекомендации по производительности

агрегирования каналов • 83 Решение ClusterXL • 8 Решение State Synchronization от Check Point • 12 Ручная настройка ARP прокси-сервера • 93

С

Сеть синхронизации • 12, 24 Синхронизация информации о соединениях в

кластере • 12 Синхронизация кластеров в глобальной

компьютерной сети • 15 Синхронизация с ограничением

продолжительности • 14 Синхронизация соединений без привязки • 15 Синхронизация таблицы маршрутизации • 97 Синхронизация часов в ClusterXL • 10 Скрипт clusterXL_monitor_process • 106 Сноски • 34 Снятие ограничений по количеству

многоадресных передач данных • 32 События с отменой удержания пакетов • 63 События с удержанием пакетов • 63 Совместимость ClusterXL (кроме IPS) • 33 Совместимость ClusterXL с IPS • 34 Совместимость с операционными системами • 33 Соединение синхронизации с истекшим тайм-

аутом • 61 Соединения c привязкой • 18 Соединения без привязки • 14 Создание агрегации интерфейсов в режиме High

Availability • 79 Создание синхронизируемых и

несинхронизируемых версий • 17 Создание стороннего шлюза в развернутой

системе Hub and Spoke • 21 Сообщения в активном режиме SmartView Tracker

• 68 Сообщения журналов регистрации ClusterXL • 53 Сообщения о несоответствии TCP таблице

состояний • 69 Сообщения об ошибках ClusterXL • 67 Сообщения об ошибках, связанные с


синхронизацией • 68 Сообщения об ошибках, специфические для IPSO

• 69 Сообщения об ошибках, специфические для

платформ • 69 Среднее время удержания (такты) • 64 Среднее количество обновлений | Пропущенные

обновления на запрос • 60 Средняя длина очереди на отправку • 63 Старые или преждевременно поступающие

обновления • 60 Статистика синхронизации (Идентификаторы

равноправных узлов F&A - 1) • 59 Сторонние шлюзы в развернутых системах Hub

and Spoke • 19 Строки, содержащие причины сообщений • 54 Сценарии блокировки • 62

Т

Таблица сравнения режимов • 27 Таймеры • 64 Такт CPHA (мс) • 65 Такт синхронизации (мс) • 64 Термины и определения • 10 Трансляции Cluster Fold и Cluster Hide • 73 Требования к аппаратному обеспечению ClusterXL

• 30 Требования к аппаратному обеспечению,

совместимость и пример Cisco • 30

У

Увеличение очереди на отправку • 65 Увеличение очереди на получение • 65 Увеличение таймера CPHA • 66 Увеличение таймера синхронизации • 66 Удаление IP-адресов с ведомых интерфейсов • 79 Удаление элемента • 39, 103 Уменьшение количества ожидающих пакетов • 89 Управление таймерами кластеризации и

синхронизации • 87 Уровень передачи данных • 35 Установка и поддерживаемые платформы • 9

Ф

Факторы, учитываемые при планировании • 101 Факторы, учитываемые при планировании

реализации • 29 Что происходит при восстановлении шлюза? • 29

Ш

Шлюз по умолчанию на SecurePlatform • 94

Documents

ClusterXL Administration Guide R75 - rrc.rurrc.ru/uploads/20180627/CP_R75.40VS_ClusterXL_AdminGuide_RUS.… · Title: ClusterXL Administration Guide R75.40VS Author: Check Point Software