Правила эксплуатации и обработки информации в программно-аппаратных комплексах ViPNet Coordinator HW

Воронежский институт МВД России Кафедра информационной безопасности УТВЕРЖДАЮ Заместитель начальника кафедры информационной безопасности полковник полиции А.В. Мельников «___» ___________ 2018 г. Тезисы лекции по программе повышения квалификации сотрудников подразделений территориальных органов МВД России по теме: «ПАК ViPNet Coordinator HW1000/2000, правила эксплуатации и обработки информации» (c использованием системы дистанционных образовательных технологий) Блок дистанционного обучения в системе MOODLE Тема №2. «Защита каналов связи ИМТС МВД России с помощью программно-аппаратной технологии ViPNet» Лекция №11. «Правила эксплуатации и обработки информации в программно-аппаратных комплексах ViPNet Coordinator HW» Подготовил: старший преподаватель кафедры информационной безопасности подполковник полиции С.В. Зарубин Обсуждены и одобрены на заседании методической секции кафедры информационной безопасности протокол № __ от _______ 2018 г. Обсуждены и одобрены на заседании кафедры информационной безопасности протокол № __ от _______ 2018 г. Воронеж 2018 1. Отказоустойчивая эксплуатация ПАК Coordinator HW. Система защиты от сбоев предназначена для создания отказоустойчивого решения на базе ПАК Coordinator HW. Данная система имеет два режима функционирования: • одиночный режим (режим одиночного ПАК); • режим кластера (режим кластера горячего резервирования ПАК). Внимание! Кластер горячего резервирования можно организовать только на базе ПАК Coordinator HW1000, HW-VPNM, HW2000 и NME-RVPN. ПАК ViPNet Coordinator HW100 можно использовать только как одиночный ПАК, поэтому на HW100 система защиты от сбоев всегда функционирует в одиночном режиме. При работе в одиночном режиме, который устанавливается автоматически на ПАК ViPNet Coordinator HW, система защиты от сбоев выполняет функции, обеспечивающие постоянную работоспособность его основных служб: • постоянный контроль состояния служб и ведение статистики использования системных ресурсов; • обнаружение факта сбоя службы и осуществление последующих попыток восстановления работоспособности сбойного приложения; • предотвращение внутренних сбоев в работе самой системы защиты от сбоев. Режим кластера горячего резервирования обеспечивает передачу функций вышедшего из строя ПАК другому (резервному) ПАК. Кластер горячего резервирования состоит из двух взаимосвязанных ПАК, один из которых (активный ПАК) выполняет функции координатора сети ViPNet, а другой ПАК (пассивный) находится в режиме ожидания. С точки зрения топологии сети ViPNet, кластер представляет собой один сетевой узел ViPNet. В случае сбоев, критичных для работоспособности ПО ViPNet на активном ПАК, пассивный ПАК переключается в активный режим для выполнения функций сбойного ПАК. При этом сбойный ПАК перезагружается и становится пассивным. При работе в режиме кластера система защиты от сбоев также выполняет функции одиночного режима, то есть обеспечивает постоянную работоспособность основных служб, входящих в состав ПО ПАК ViPNet Coordinator HW. Для поддержки режима кластера горячего резервирования узел, который будет разворачиваться на ПАК кластера, необходимо зарегистрировать в прикладной задаче «ViPNet Failover» (дополнительно к регистрации в прикладной задаче «Координатор HW1000» или «Координатор HW-VPNM»). Регистрация сетевых узлов в приклад- пых задачах осуществляется в Центре управления сетью в процессе формирования сети ViPNet. Режимы работы системы защиты от сбоев. Одиночный режим В одиночном режиме работы система защиты от сбоев выполняет работу, связанную с обеспечением работоспособного состояния основных служб ПАК ViPNet Coordinator HW. Данный функционал обеспечивается совместной работой драйвера watchdog и демона failoverd, работающего в фоновом режиме. Драйвер watchdog работает на очень низком уровне и в большинстве случаев сохраняет работоспособность даже в случаях, когда система уже не реагирует на внешние события. При соответствующей настройке демон failoverd при запуске регистрируется в драйвере и периодически опрашивает его, подтверждая работоспособность системы. Если по истечении заданного промежутка времени драйвер обнаруживает, что опроса не было, то он перезагружает систему. Перед этим он делает попытку записать на диск кеш-буферы системы, чтобы не возникло ошибок в файловой системе, однако это не всегда возможно. При корректной остановке демона (например, для изменения настроек системы защиты от сбоев) она сообщает драйверу об этом, и драйвер перестает следить за временем опроса, так что система не будет перезагружена. Такой механизм обеспечивает предотвращение внутренних сбоев в демоне failoverd. Демон failoverd осуществляет постоянный контроль за работоспособностью следующих служб ПО ViPNet: • управляющий демон ViPNet (iplircfg); • транспортный модуль MFTP (mftpd). При старте ОС демон системы защиты от сбоев failoverd осуществляет старт подконтрольных служб, а также дальнейшее слежение за ними. Контроль работы этих служб производится путем их регистрации в системе защиты от сбоев в момент старта с установкой периода оповещения. В процессе работы контролируемая служба (приложение) периодически определяет свое состояние и оповещает о нем систему слежения. Если контролируемое приложение в течение периода оповещения не сообщило о своем состоянии или сообщило о внутреннем сбое, то система защиты от сбоев идентифицирует сбой приложения и инициирует процедуру восстановления работоспособности этого приложения. Для этого сначала делается попытка корректной остановки сбойного приложения. Если эта попытка оказывается неудачной, то осуществляется принудительная «некорректная» остановка приложения. После этот система защита от сбоев перезапускает остановленное приложение. В процессе работы демон защиты от сбоев failoverd ведет статистику сбоев для каждого контролируемого приложения, в том числе и для самого себя. Если обнаруживается, что для какого-либо из приложений произошло 5 сбоев подряд, то есть в течение 5 попыток восстановления работоспособности приложение не смогло корректно стартовать, то делается вывод о полной неработоспособности приложения. В этом случае, в зависимости от настроек системы защиты от сбоев, произ водится либо перезагрузка ОС, либо остановка сбойного приложения и прекращение слежения за ним. Если контролируемое приложение было корректно остановлено администратором системы с помощью соответствующей команды (iplir stop или mftp stop), то оно производит дерегистрацию в системе защиты от сбоев, слежение за ним отключается. В этом случае для дальнейшей работы администратор должен вручную запустить приложение. Если при запуске демона failoverd выясняется, что какие-либо из подконтрольных демонов были остановлены вручную, то об этом формируется предупреждение в системный журнал syslog. Предупреждение формируется также в случае, если в течение десяти проверок подряд одного демона он находится в режиме ручной остановки. Чтобы предупреждения попадали в системный журнал, необходимо настроить удаленное протоколирование на основе протокола syslog. Режим кластера горячего резервирования Весь кластер, с точки зрения остальных узлов сети, имеет один IP- адрес на каждом из своих сетевых интерфейсов. Этим адресом обладает сервер (ПАК), находящийся в данный момент в активном режиме. Сервер, находящийся в пассивном режиме, имеет иной IP- адрес, который не используется другими компьютерами для связи с кластером. В отличие от адресов активного режима, в пассивном режиме каждый из серверов имеет свой собственный адрес на каждом из интерфейсов, эти адреса для двух серверов не совпадают. Стек IP на каждом из серверов настраивается администратором таким образом, чтобы после перезагрузки сервер получал свои адреса пассивного режима. При загрузке запускается демон системы защиты от сбоев failoverd, который стартует в пассивном режиме. В этом режиме пассивный сервер периодически посылает в сеть запросы на поиск IP-адресов активного сервера. Если все адреса активного сервера недоступны в течение заданного времени (следовательно, активного сервера нет в сети), то пассивный сервер переходит в активный режим. При этом он устанавливает себе на всех интерфейсах соответствующие адреса активного сервера (адреса, под которыми кластер известен другим компьютерам сети) и входит в цикл проверки своих сетевых интерфейсов. Активный сервер периодически проверяет работоспособность сети на каждом заданном в настройках интерфейсе по следующей схеме. Периодически, по истечении заданного в настройках временного интервала, анализируются входящий и исходящий сетевые трафики, прошедшие через интерфейс. Если разница в количестве пакетов между началом и концом интервала положительна, то считается, что интерфейс функционирует нормально, и счетчик отказов для этого интерфейса сбрасывается. Если в течение данного интервала не было послано и принято ни одного пакета, то включается дополнительный механизм проверки, заключающийся в посылке эхо-запросов до стабильных объектов сети. Данный механизм можно использовать не только как дополнительный, но и как основной. Это достигается настройкой параметров в файлах конфигурации системы защиты от сбоев. Если на какой-либо из интерфейсов в заданное время не приходят ответы на эхо-запросы, счетчик отказов для этого интерфейса увеличивается на единицу. При достижении счетчиком определенного значения фиксируется полный отказ интерфейса. При возникновении полного отказа одного из интерфейсов активный сервер перезагружается. В момент перезагрузки (она занимает, как правило, около 30 секунд) все адреса активного сервера становятся недоступны, что служит сигналом для пассивного сервера о переходе в активный режим. После перезагрузки сервер, как описано выше, переходит в пассивный режим и остается в нем, а второй сервер из пары, если он работоспособен, работает теперь как активный. При установке на каком-либо интерфейсе ПАК 1-го режима безопасности блокируется любой открытый (в том числе служебный) трафик на этом интерфейсе. Вследствие этого при проверке работоспособности интерфейсов, находящихся в 1-ом режиме безопасности, с использованием открытых объектов сети всегда будет фиксироваться отказ этих интерфейсов, что повлечет за собой циклическую перезагрузку серверов кластера. Оба сервера в используемой схеме абсолютно равноправны. При начальном запуске кластера активным станет тот сервер, который будет запущен раньше. Однако поскольку переключение серверов из одного режима в другой занимает некоторое время, то при практически одновременном старте серверов может случиться, что они оба перейдут сначала в пассивный режим, а затем в активный. Для предотвращения такой ситуации серверы постоянно обмениваются по резервному каналу пакетами синхронизации, содержащими информацию о режиме работы. Если обнаруживается, что оба сервера находятся в активном режиме, то запускается специальная схема выборов, которая однозначно определяет тот сервер, который должен перезагрузиться и перейти в пассивный режим. 2. Сценарии эксплуатации кластера горячего резервирования. Типовая схема Рис. 1. Типовая схема кластера горячего резервирования Схема при ограниченном количестве IP-адресов В ряде случаев, когда выделение трех IP-адресов в одной сети для организации типовой схемы не представляется возможным (использование реальных интернет-адресов, ограничения адресного пространства сети), можно использовать схему организации кластера, в которой потребуется выделить лишь один IP-адрес для активного режима работы кластера. Пример такой схемы организации кластера приведен на рис. 143. Рис. 2. Схема организации кластера горячего резервирования при ограниченном количестве IP-адресов Из схемы видно, что, в отличие от типовой схемы включения, для внешней сети (на схеме External Network, интерфейсы eth2) выделен только один реальный IP-адрес (для активного режима) вместо трех реальных адресов в случае использования типовой схемы. Пассивные адреса выбраны из диапазона частной сети. Подключение к внутренней сети (на схеме Internal Network, интерфейсы ethl) выполнено по типовой схеме. Общий принцип работы состоит в том, чтобы использовать на пассивном сервере адреса из другой подсети - например, из диапазона частных адресов. Чтобы пассивный сервер мог проверить наличие в сети адресов активного, на пассивном сервере устанавливаются на соответствующих интерфейсах маска подсети 0.0.0.0 и широковещательный адрес 255.255.255.255. Такая конфигурация интерфейса заставляет пассивный сервер пытаться отправить любой пакет, проходящий через такой интерфейс, напрямую, запросив в сети МАС-адрес получателя. Таким образом, если пассивный сервер попытается послать пакет активному серверу и маршрутизация на адрес активного будет настроена через интерфейс с маской 0.0.0.0, то пассивный сервер всегда запросит МАС-адрес активного путем посылки ARP-запроса - независимо от того, к каким подсетям принадлежат адреса активного и пассивного серверов, и затем пошлет пакет на этот МАС-адрес. Подобный механизм позволяет осуществлять пассивному серверу контроль работоспособности интерфейсов активного путем проверки наличия ответов на ARP-запросы. При этом важно, чтобы маршрутизация через интерфейсы с маской подсети 0.0.0.0 была настроена только на адреса активного сервера, принадлежащие соответствующим интерфейсам, чтобы такая конфигурация не нарушала работы других интерфейсов.