что такое кластер горячего резервирования
Криптошлюз Vipnet Failover или как не надо реализовывать отказоустойчивость
Отмечу, что сам по себе Vipnet Coordinator Linux неплох, и всё портит сама схема горячего резервирования.
Весь кластер, с точки зрения других компьютеров сети, имеет один IP-адрес на каждом из своих сетевых интерфейсов. Этим адресом обладает сервер, находящийся в данный момент в активном режиме. Сервер, находящийся в пассивном режиме, имеет другой IP-адрес, который не используется другими компьютерами для связи с кластером. В отличие от адресов активного режима, в пассивном режиме каждый из серверов имеет свой собственный адрес на каждом из интерфейсов, эти адреса для двух серверов не совпадают.
В конфиге failover.ini содержатся 3 типа разделов параметров. В разделе [channel] описываются IP-адреса резервируемых интерфейсов:
В разделе [network] описываются параметры резервирования:
В [sendconfig] прописывается адрес сетевого интерфейса второго сервера, по которому будет синхронизироваться работа кластера:
Опять же приведу алгоритм резервирования из документации:
Алгоритм работы на активном сервере следующий. Через каждые checktime секунд проводится проверка работоспособности каждого из приведенных в конфигурации интерфейсов. Если параметр checkonlyidle установлен в yes, то анализируется входящий и исходящий сетевой трафик, прошедший через интерфейс. Если разница в количестве пакетов между началом и концом интервала положительна, то считается, что интерфейс функционирует нормально, и счетчик отказов для этого интерфейса обнуляется. Если в течение данного интервала не было послано и принято ни одного пакета, то включается дополнительный механизм проверки, заключающийся в посылке эхо-запросов до ближайших маршрутизаторов. Если параметр checkonlyidle установлен в no, то механизм дополнительной проверки используется вместо основного, то есть каждые checktime секунд посылаются пакеты до адресов testip. Затем в течение времени timeout ожидаются ответы. Если на каком-либо интерфейсе ответа нет ни от одного адреса testip, то его счетчик сбоев увеличивается на единицу. Если хотя бы на одном интерфейсе счетчик сбоев не равен нулю, то немедленно посылаются новые пакеты до всех testip и ожидается ответ в течение timeout. Если в процессе новых посылок на интерфейс, счетчик сбоев которого не равен нулю, приходит ответ, его счетчик сбоев обнуляется. Если после какой-либо посылки счетчики сбоев на всех интерфейсах становятся равны нулю, то происходит возврат в основной цикл, новое ожидание в течение checktime и так далее. Если же после какого-то числа новых посылок счетчик сбоев хотя бы одного интерфейса достигнет значения channelretries, то фиксируется полный отказ интерфейса и начинается перезагрузка системы. Таким образом, максимальное время неработоспособности интерфейса до того, как система защиты от сбоев сделает вывод об этом, равно checktime + (timeout * channelretries).
На пассивном сервере алгоритм немного отличается. Раз в checktime секунд производится удаление записей в системной ARP-таблице для всех activeip. Затем посылаются UDP-запросы со всех интерфейсов на адреса activeip, в результате чего система сначала посылает ARP-запрос и только в случае получения ответа посылает UDP-запрос. После окончания интервала ожидания ответа timeout проверяется наличие ARP-записи для каждого activeip в системной ARP-таблице, по наличию которой делается вывод о работоспособности соответствующего интерфейса на активном сервере. Если ни от одного интерфейса не был получен ответ, счетчик сбоев (он один на все интерфейсы) увеличивается. Если хотя бы от одного интерфейса ответ был получен, счетчик сбоев обнуляется. Если счетчик сбоев достигает значения activeretries, то производится переключение в активный режим. Максимальное время, проходящее от перезагрузки активного сервера до обнаружения пассивным сервером этого факта, равно checktime + (timeout * activeretries).
Общее время неработоспособности системы при сбое может быть немного больше, чем checktime * 2 + timeout * (channelretries + activeretries). Это связано с тем, что после начала перезагрузки сбойного сервера система переводит его интерфейсы в нерабочее состояние не сразу, а через некоторое время, после остановки других подсистем. Поэтому, например, если проверяются два интерфейса и только на одном произошел сбой, то адрес второго интерфейса будет доступен еще некоторое время, в течение которого пассивный сервер будет получать от него ответы. Обычно время от начала перезагрузки до выключения интерфейсов не превышает 30 секунд, однако оно может сильно зависеть от быстродействия компьютера и количества работающих на нем сервисов.
На первый взгляд всё верно, как только с активным сервером неполадки, он перезагружается, а его место занимает пассивный. Что же мы имеем на практике?
Получается, что отказоустойчивость файловера возможна лишь в сферическом вакууме, где вся сетевая инфраструктура работает без сбоев. Кто-то может сказать, что это вынужденная мера, но если что-то случиться с одним из серверов, например, вылетит сетевой интерфейс, то он перезагрузится, его работоспособность восстановится и алгоритм резервирования докажет свою полезность. Однако, на практике был случай когда один из интерфейсов файловера действительно заглючил, и он стал перезагружаться согласно описанной выше схеме, при этом проблема после перезагрузки никуда не делась. Чтобы избавиться от глюка пришлось вручную отключить питание, так что и в этом случае отказоустойчивость видна лишь на бумаге.
Всё это можно было исправить, если бы алгоритм включал в себя ещё одно условие: активный сервер не должен перезагружаться, если пассивный выключен. Вроде бы нехитрое условие, обеспечивающее реальную отказоустойчивость, так и не было добавлено разработчиками. Я могу лишь предполагать, что это связано с необходимостью внесения изменений в ядро и его повторной сертификации.
В случае же исправного сетевого окружения и серверного оборудования аптайм серверов был практически непрерывным. Один из первых файловеров, который мне пришлось установить работает уже 3 года и за это время схема горячего резервирования отрабатывала только во время модернизации ПО или из-за общих технических работ в ЦОДе. В общем реальная польза от такой схемы возможна лишь в случае аппаратного сбоя в одной из нод кластера, чего в моей практике ещё не случалось.
Была надежда, на Vipnet Cluster Windows, но Инфотекс, к сожалению, его не осилил, а жаль, схема резервирования была очень многообещающей.
В общем, мой совет таков, если вам не нужен отказоустойчивый криптошлюз для галочки, то с файловером лучше не заморачиваться, а пользоваться обычным Vipnet Linux координатором, он сам по себе достаточно надёжен, особенно если его не трогать 😉
Обзор вариантов реализации отказоустойчивых кластеров: Stratus, VMware, VMmanager Cloud
Есть разновидности бизнеса, где перерывы в предоставлении сервиса недопустимы. Например, если у сотового оператора из-за поломки сервера остановится биллинговая система, абоненты останутся без связи. От осознания возможных последствий этого события возникает резонное желание подстраховаться.
Мы расскажем какие есть способы защиты от сбоев серверов и какие архитектуры используют при внедрении VMmanager Cloud: продукта, который предназначен для создания кластера высокой доступности.
Предисловие
В области защиты от сбоев на кластерах терминология в Интернете различается от сайта к сайту. Для того чтобы избежать путаницы, мы обозначим термины и определения, которые будут использоваться в этой статье.
На первый взгляд самый привлекательный вариант для бизнеса тот, когда в случае сбоя обслуживание пользователей не прерывается, то есть кластер непрерывной доступности. Без КНД никак не обойтись как минимум в задачах уже упомянутого биллинга абонентов и при автоматизации непрерывных производственных процессов. Однако наряду с положительными чертами такого подхода есть и “подводные камни”. О них следующий раздел статьи.
Continuous availability / непрерывная доступность
Бесперебойное обслуживание клиента возможно только в случае наличия в любой момент времени точной копии сервера (физического или виртуального), на котором запущен сервис. Если создавать копию уже после отказа оборудования, то на это потребуется время, а значит, будет перебой в предоставлении услуги. Кроме этого, после поломки невозможно будет получить содержимое оперативной памяти с проблемной машины, а значит находившаяся там информация будет потеряна.
Для реализации CA существует два способа: аппаратный и программный. Расскажем о каждом из них чуть подробнее.
Программный способ.
На момент написания статьи самый популярный инструмент для развёртывания кластера непрерывной доступности — vSphere от VMware. Технология обеспечения Continuous Availability в этом продукте имеет название “Fault Tolerance”.
В отличие от аппаратного способа данный вариант имеет ограничения в использовании. Перечислим основные:
Мы не стали расписывать конкретные конфигурации нод: состав комплектующих в серверах всегда зависит от задач кластера. Сетевое оборудование описывать также смысла не имеет: во всех случаях набор будет одинаковым. Поэтому в данной статье мы решили считать только то, что точно будет различаться: стоимость лицензий.
Стоит упомянуть и о тех продуктах, разработка которых остановилась.
Есть Remus на базе Xen, бесплатное решение с открытым исходным кодом. Проект использует технологию микроснэпшотов. К сожалению, документация давно не обновлялась; например, установка описана для Ubuntu 12.10, поддержка которой прекращена в 2014 году. И как ни странно, даже Гугл не нашёл ни одной компании, применившей Remus в своей деятельности.
Предпринимались попытки доработки QEMU с целью добавить возможность создания continuous availability кластера. На момент написания статьи существует два таких проекта.
Первый — Kemari, продукт с открытым исходным кодом, которым руководит Yoshiaki Tamura. Предполагается использовать механизмы живой миграции QEMU. Однако тот факт, что последний коммит был сделан в феврале 2011 года говорит о том, что скорее всего разработка зашла в тупик и не возобновится.
Второй — Micro Checkpointing, основанный Michael Hines, тоже open source. К сожалению, уже год в репозитории нет никакой активности. Похоже, что ситуация сложилась аналогично проекту Kemari.
Таким образом, реализации continuous availability на базе виртуализации KVM в данный момент нет.
Итак, практика показывает, что несмотря на преимущества систем непрерывной доступности, есть немало трудностей при внедрении и эксплуатации таких решений. Однако существуют ситуации, когда отказоустойчивость требуется, но нет жёстких требований к непрерывности сервиса. В таких случаях можно применить кластеры высокой доступности, КВД.
High availability / высокая доступность
В контексте КВД отказоустойчивость обеспечивается за счёт автоматического определения отказа оборудования и последующего запуска сервиса на исправном узле кластера.
В КВД не выполняется синхронизация запущенных на нодах процессов и не всегда выполняется синхронизация локальных дисков машин. Стало быть, использующиеся узлами носители должны быть на отдельном независимом хранилище, например, на сетевом хранилище данных. Причина очевидна: в случае отказа ноды пропадёт связь с ней, а значит, не будет возможности получить доступ к информации на её накопителе. Естественно, что СХД тоже должно быть отказоустойчивым, иначе КВД не получится по определению.
Таким образом, кластер высокой доступности делится на два подкластера:
VMmanager Cloud
Наше решение VMmanager Cloud использует виртуализацию QEMU-KVM. Мы сделали выбор в пользу этой технологии, поскольку она активно разрабатывается и поддерживается, а также позволяет установить любую операционную систему на виртуальную машину. В качестве инструмента для выявления отказов в кластере используется Corosync. Если выходит из строя один из серверов, VMmanager поочерёдно распределяет работавшие на нём виртуальные машины по оставшимся нодам.
В упрощённой форме алгоритм такой:
Практика показывает, что лучше выделить одну или несколько нод под аварийные ситуации и не развёртывать на них ВМ в период штатной работы. Такой подход исключает ситуацию, когда на “живых” нодах в кластере не хватает ресурсов, чтобы разместить все виртуальные машины с “умершей”. В случае с одним запасным сервером схема резервирования носит название “N+1”.
Рассмотрим по каким схемам пользователи VMmanager Cloud реализовывали кластеры высокой доступности.
FirstByte
Компания FirstByte начала предоставлять облачный хостинг в феврале 2016 года. Изначально кластер работал под управлением OpenStack. Однако отсутствие доступных специалистов по этой системе (как по наличию так и по цене) побудило к поиску другого решения. К новому инструменту для управления КВД предъявлялись следующие требования:
Отличительные черты кластера:
Данная конфигурация подходит для хостинга сайтов с высокой посещаемостью, для размещения игровых серверов и баз данных с нагрузкой от средней до высокой.
FirstVDS
Компания FirstVDS предоставляет услуги отказоустойчивого хостинга, запуск продукта состоялся в сентябре 2015 года.
К использованию VMmanager Cloud компания пришла из следующих соображений:
В случае общего отказа Infiniband-сети связь между хранилищем дисков ВМ и вычислительными серверами выполняется через Ethernet-сеть, которая развёрнута на оборудовании Juniper. “Подхват” происходит автоматически.
Благодаря высокой скорости взаимодействия с хранилищем такой кластер подходит для размещения сайтов со сверхвысокой посещаемостью, видеохостинга с потоковым воспроизведением контента, а также для выполнения операций с большими объёмами данных.
Эпилог
Подведём итог статьи. Если каждая секунда простоя сервиса приносит значительные убытки — не обойтись без кластера непрерывной доступности.
Однако если обстоятельства позволяют подождать 5 минут пока виртуальные машины разворачиваются на резервной ноде, можно взглянуть в сторону КВД. Это даст экономию в стоимости лицензий и оборудования.
Кроме этого не можем не напомнить, что единственное средство повышения отказоустойчивости — избыточность. Обеспечив резервирование серверов, не забудьте зарезервировать линии и оборудование передачи данных, каналы доступа в Интернет, электропитание. Всё что только можно зарезервировать — резервируйте. Такие меры исключают единую точку отказа, тонкое место, из-за неисправности в котором прекращает работать вся система. Приняв все вышеописанные меры, вы получите отказоустойчивый кластер, который действительно трудно вывести из строя.
Если вы решили, что для ваших задач больше подходит схема высокой доступности и выбрали VMmanager Cloud как инструмент для её реализации, к вашим услугам инструкция по установке и документация, которая поможет подробно ознакомиться с системой. Желаем вам бесперебойной работы!
P. S. Если у вас в организации есть аппаратные CA-серверы — напишите, пожалуйста, в комментариях кто вы и для чего вы их используете. Нам действительно интересно услышать для каких проектов использование такого оборудование экономически целесообразно 🙂
Вариант №1. Подключение с помощью кластера горячего резервирования
Для организации подключения кластера горячего резервирования ViPNet следует:
1. Обеспечить выделение IP адресов в сети, в соответствии с типовой схемой и таблицей (нумерация в таблице соответствует нумерации в типовой схеме):
IP адрес/маска
Назначение
Активный и физические адреса внешних интерфейсов кластера. Могут быть как из частного, так и из публичного адресного пространства, но должны принадлежать одной подсети.
Активный и физические адреса внутренних интерфейсов кластера. Должны принадлежать одной подсети, но ip ext и ip int обязательно должны принадлежать разным подсетям.
Адрес шлюза по умолчанию в сети, в которую включаются внешние интерфейсы кластера.
Публичный транслируемый адрес, через который осуществляется доступ к активному внешнему адресу кластера.
Указывается в случае использования частных адресов на внешних интерфейсах кластера.
Адрес шлюза для доступа к внутренним ресурсам.
Указывается в случае нахождения ресурсов и внутренних интерфейсов кластера в разных сетях.
Адрес АРМа взаимодействующий с серверами ИС ГИС ГМП/КЭП.
При подключении нескольких АРМов ip res транслирует ресурсы до активного внутреннего адреса кластера.
2. Обеспечить физическое размещение 2-х мест размером 19 дюймов Rack 1U глубиной не менее 480 мм, на площадке.
3. Обеспечить подключение оборудования максимальной потребляемой мощностью 200 Вт (каждый) к сети гарантированного электропитания питания 220 В с помощью кабеля типа С13 – СЕЕ7/7 (евровилка).
4. Обеспечить возможность подключения интерфейсов Ethernet Base T 100/1000 ПАКов к сетевому оборудованию.
5. Обеспечить связность на втором уровне модели OSI/ISO внутренних, отдельно внешних и отдельно, интерфейсов горячего резервирования ПАКов, другими словами, размещение двух физических внутренних интерфейсов в одном широковещательном сегменте, внешних в другом, интерфейсов горячего резервирования в третьем.
6. Обеспечить отсутствие логических препятствий для прохождения трафика по протоколу UDP и порту 55777 между внешним активным адресом кластера (ip ext active) и адресами криптошлюзов ИС ГИС ГМП/КЭП.
7. При использовании частных адресов на внешних интерфейсах кластера – обеспечить статическую трансляцию адреса частного внешнего активного адреса кластера (ip ext active) в публичный адрес (ip fw) и трансляцию публичного адреса (ip fw) в частный внешний активный адрес кластера (ip ext active) по протоколу UDP и порту 55777.
9. Обеспечить маршрутизацию пакетов АРМов через внутренний активный адрес кластера (ip int active) для адресов:
10. Обеспечить выделение на внешних и внутренних интерфейсах адресацию, не пересекающуюся с сетью Электронного Правительства.
Вопросы и ответы: ViPNet Coordinator HW
Вопросы и ответы: ViPNet Coordinator HW
Настройка двух DHCP-relay для двух разных подсетей, на разные DHCP-сервера. Необходимо настроить два DHCP relay для двух разных подсетей, настроенных на разных интерфейсах координатора. (Одна подсеть должна посылать запрос на один DHCP-сервер, другая на другой соответственно.) Как настроить такую функцию? Можно ли сделать такую схему с использованием других служб (Например, NAT)? Coordinator ПАК HW, версия 4.2.1.
В версии 4.2.1 такой возможности нет.
Возможность настройки двух dhcp-relay на разных интерфейсах для двух разных DHCP серверов реализовано HW4.3.0 и выше.
На Coordinator HW1000 загрузка демона alg на 100%. Во время работы ПАК HW загрузка демона ALG регистрируется в 100%, при этом пропадает доступ до ПАК по сети. Для восстановления доступа к ПАК HW1000, помогает перезагрузка ALG, командой alg restart.
При задействованном процессе ALG, такая ситуация возможна по нескольким причинам.
В качестве быстрого устранения проблемы, в случае если нет необходимости в обработке трафика приклодных протоколов (TFTP, SCCP, NTP, DNS, SIP, H323) рекомендуется отключить ALG (см. документ «ViPNet Coordinator HW 4. Справочное руководство по командному интерпретатору», раздел «Команды группы alg»). Если отключение ALG не помогло, необходимо обратиться в техническую поддержку ИнфоТеКС по следующему адресу электронной почты: hotline@infotecs.ru.
Изменили пароль пользователя, но он не применился на координаторе. В ПО ViPNet Администратор изменили пароль для пользователя сетевого узла ПАК HW, сформировали и отправили справочники на узел, справочники применились, но пароль пользователя не изменился.
Все действия над учетной записью пользователя (смена пароля, удаление) необходимо выполнять только локально на ViPNet Coordinator HW.
Пароль пользователя ViPNet Coordinator HW можно изменить только локально, как описано ниже. Смена пароля пользователя удаленно (с помощью программы ViPNet Центр управления сетью (ЦУС)) невозможна.
Чтобы изменить пароль пользователя, выполните следующие действия:
В результате с помощью нового пароля будут перешифрованы ключи пользователя, в том числе резервный набор персональных ключей при наличии.
Более подробно, см. в документе: «ViPNet Coordinator HW 4. Настройка с помощью командного интерпретатора» раздел «Настройка параметров безопасности».
Необходимо заменить программный координатор на ПАК HW. Возникла необходимость заменить программный координатор (Windows/Linux) на программно-аппаратный комплекс HW. Программный координатор является основным, на нем зарегистрирован ЦУС + он имеет связи с другими HW. Можно ли это сделать без переноса клиентов на новый координатор?
Для реализации переноса необходимо выполнить следующие действия:
Плюсы данного сценария в том, что для пользователей замена происходит незаметно, никаких настроек менять не нужно.
В случае возникновения проблем на выполнении п. 4–7 можно произвести переключение обратно на программный координатор.
Внимание! В данном примере не рассматривается задача по переносу очереди MFTP с программного координатора на ПАК HW.
Аналогично, можно проводить замену ПАК HW различных платформ, например, в случае замены ПАК HW на более производительную платформу.
Необходимо обновить ПАК HW с версии 3.х на 4.х. Какова последовательность обновления версий?
Первоначально, необходимо убедиться, что платформа ПАК поддерживает версию 4.х*.
Для корректного обновления на версию прошивки 4.х необходимо обновиться до версии (3.5) и лишь затем переходить к обновлению на 4.1., и лишь потом на 4.2.
Перед удаленным обновлением необходимо разослать из ЦУС на координаторы актуальный файл лицензии, который позволит обновиться до следующей версии ПО координатору HW. Затем из ЦУС поочередно с версии на версию отправлять обновления ПО. Нужно убедиться в применении обновления каждой посланной версии. Более подробный порядок версий, на которые нужно обновляться до актуальной версии прошивки HW 4.2.1, а также промежуточные версии ПО, можно запросить в отделе технического сопровождения ИнфоТеКС, по электронной почте hotline@infotecs.ru.
При локальном обновлении, также нужно применять последовательность в установке перечисленных версий.
Кроме того, можно перепрошить ПАК сразу на версию 4.2, однако придется производить настройки ПАК заново.
* — начиная с версии 4.0 более не поддерживаются следующие платформы: HW100 E1, HW100 E2, HW100 K1, HW1000 Q1/S1.
При обновлении ViPNet Coordinator HW версии 3.х до версии 4.х и последующей перезагрузки ПАК, обновление на версию 4.х не выполнено.
Перед выполнением обновления с версии 3.х до версии 4.х необходимо предварительно убедиться, что данная платформа поддерживает версию 4.х.
К тому же до проведения обновления необходимо выполнить команду смены пароля пользователя ViPNet Coordinator HW — admin passwd.
Пароль можно оставить тот же что и был, после чего повторить обновление ПАК.
Более подробно о команде «admin passwd» см. в документе «ViPNet Coordinator HW 4. Справочное руководство по командному интерпретатору» раздел «Команды группы admin».
При входе в консоль ViPNet Coordinator HW и вводе пароля пользователя или администратора долго не удается войти.
В ViPNet Coordinator HW реализован механизм создания временных задержек при неуспешном вводе пароля.
Если пользователь или администратор вводит неверный пароль, перед следующей попыткой ввода пароля ему нужно подождать несколько секунд. Задержка реализована для предотвращения возможности подбора пароля методом перебора. С каждой новой неуспешной попыткой ввода пароля задержка увеличивается. Если был введен неверный пароль 10 раз подряд, задержка составит 25 минут, но после нее можно повторить очередную попытку ввода пароля. При успешном вводе пароля счетчик, который фиксирует неуспешные попытки, обнуляется.
Кроме этого, информация обо всех неуспешных попытках ввода пароля фиксируются в журнале устранения неполадок.
Возможность изменения размера MTU на сетевых интерфейсах ПАК HW.
По умолчанию в ViPNet Coordinator HW при передаче данных через сетевые интерфейсы используется фиксированный размер MTU, равный 1500 байт.
Возможность изменения MTU на сетевых интерфейсах реализована в HW4.2.2 и выше.
При работе в режиме кластера горячего резервирования не работает DHCP-relay или DHCP-сервер.
Поддержка функция DHCP-relay и DHCP-сервер при работе в кластере горячего резервирования будет реализована HW4.3.0 и выше.
Отсутствует принудительное переназначение виртуальных адресов.
В предыдущих версиях ViPNet Coordinator HW можно было принудительно запустить автоматическое переназначение виртуальных адресов всех защищенных узлов с помощью параметра startvirtualiphash в секции [virtualip] файла iplir.conf. В результате такого переназначения некоторые узлы могли стать недоступны, поэтому больше данный параметр не используется.
В текущей версии, для автоматического переназначения виртуальных адресов, необходимо изменить значения параметра — startvirtualip, это стартовый адрес для формирования базовых виртуальных адресов защищенных узлов (по умолчанию — 11.0.0.1). При изменении данного параметра назначение всех базовых виртуальных адресов производится заново, как при начальном формировании файлов конфигурации.
Подробнее о настройке виртуальных адресов, см. документ «ViPNet Coordinator HW 4. Настройка с помощью командного интерпретатора», раздел «Настройка параметров виртуальных адресов».
После смены мастер-ключей в сети ViPNet координатор стал недоступен.
При компрометации и смене мастер-ключей в сети ViPNet обновления справочников и ключей на ViPNet Coordinator HW могут быть приняты только в том случае, если на узле есть резервный набор персональных ключей (РНПК).
Необходимо до смены мастер-ключей проверить наличие РНПК на узле. Узнать о наличии или отсутствии файла с РНПК на узле можно, просмотрев информации о ключах с помощью команды iplir show key-info.
Если файла с РНПК нет, добавьте его на ViPNet Coordinator HW с помощью команды admin add spare keys. В противном случае, выполнить обновление справочников и ключей будет возможно только вручную.
Организована межсеть, координатор собственной сети HW 1000, координатор сторонней сети HW 50. Координаторы друг другу доступны, так же как и клиенты. Обмен сообщениями между клиентами проходит хорошо, но обмен письмами через деловую почту не работает, как с вложениями, так и без них. Письма висят в статусе «Отправлено».
В исполнениях ViPNet Coordinator HW50 A, B и ViPNet Coordinator HW100 A, B не поддерживаются функции шлюзового координатора (см. документ «ViPNet Coordinator HW 4. Общее описание», раздел «Лицензирование ViPNet Coordinator HW») и транспортного сервера. Вследствие этого возникают следующие ограничения при формировании структуры сети ViPNet:
> Координатор, созданный для одного из этих исполнений, нельзя регистрировать в качестве шлюзового координатора в другие сети ViPNet. В противном случае работоспособность ViPNet Coordinator HW может быть нарушена.
> Клиенты ViPNet нельзя регистрировать за таким координатором. Координатор в данном случае может использоваться для туннелирования открытого IP-трафика.
Подключили ПАК HW к коммутатору через оптический кабель, но интерфейс на ПАК неактивен — нет линка.
Аппаратные платформы HW, поддерживают только определенные модели SFP-трансиверов.
– Аппаратные платформы HW100 N1, N2, N3 имеют однопортовый сетевой адаптер SFP (порт Ethernet 4), с которым совместим SFP-трансивер модели AFBR 5710PZ производства Avago Technologies.
SFP-трансивер модели Avago AFBR 5710PZ.
– Аппаратная платформа HW1000 Q6 имеет двухпортовый сетевой адаптер (порты Ethernet 4 и Ethernet 5), с которым совместим SFP-трансивер модели Avago AFBR 5710PZ (1 трансивер этой модели входит в комплект поставки).
SFP-трансивер модели AFBR 5710PZ.
– Все аппаратные платформы для исполнения ViPNet Coordinator HW2000 имеют двухпортовые сетевые адаптеры Intel Ethernet SPF+. С адаптерами этой серии совместимы только следующие модели SFP-трансиверов
> AFBR-709SMZ/SFBR-709SMZ производства Avago Technologies;
> E10GSFPSR производства Intel Corporation;
> E10GSFPLR производства Intel Corporation.
– Аппаратная платформа HW5000 Q1 имеет двухпортовый сетевой адаптер Intel Ethernet SFP+. С адаптерами этой серии совместимы только следующие модели SFP-трансиверов:
> AFBR-709SMZ/SFBR-709SMZ производства Avago Technologies;
> E10GSFPSR производства Intel Corporation;
> E10GSFPLR производства Intel Corporation.
– Аппаратная платформа HW5000 Q1 имеет двухпортовый сетевой адаптер Broadcom Ethernet SFP+. С этим адаптером совместимы только следующие модели SFP-трансиверов:
> AFBR-709SMZ/SFBR-709SMZ производства Avago Technologies;
> E10GSFPLR производства Intel Corporation.
Более подробно о совместимых SFP-трансиверах и параметрах кабеля для подключения к адаптерам, см. документ: «ViPNet Coordinator HW 4. Общее описание», раздел «Описание исполнений ViPNet Coordinator HW».
Необходимо настроить мониторинг работы ПАК HW по протоколу SNMP.
ViPNet Coordinator HW поддерживает протокол SNMP версий 1 и 2.
Для получения информации о сетевых узлах ViPNet по протоколу SNMP необходимо выделить компьютер и установить на него специальное программное обеспечение управления сетью (NMS), например WhatsUp Gold. Чтобы получение информации было возможно, импортируйте файл VIPNET-MIB.txt, в котором описаны используемые ПО ViPNet объекты SNMP, в NMS (подробнее см. в документации по используемой NMS).
Опрос ViPNet Coordinator HW по протоколу SNMP рекомендуется выполнять с защищенных узлов ViPNet. Соответствующие сетевые фильтры по умолчанию включены в список фильтров защищенной сети. Если опрос будет осуществляться с открытого узла, в список локальных фильтров открытой сети необходимо добавить аналогичные разрешающие фильтры, указав в них IP-адрес этого узла.
Для получения MIB-файлов необходимо обратиться в техническую поддержку ИнфоТеКС по следующему адресу электронной почте: hotline@infotecs.ru.
Настройка SNMP-агента описана в документации «ViPNet Coordinator HW 4. Настройка с помощью командного интерпретатора», раздел «Мониторинг по протоколу SNMP».
При работе через веб-gui на hw100с версии 4.2.1-1407 служба прокси-сервера долго запускается и останавливается, при этом выполнение в cli занимает гораздо меньше времени.
При работе в веб-gui для остановки и запуска службы прокси-сервера задействованы несколько дополнительных служб, большую часть времени занимает проверка правил firewall.
Время запуска и остановки служб будет уменьшено в новых версиях ПО.
При работе SIP-телефонии в сети ViPNet наблюдается обрыв связи или односторонняя связь, при этом на координаторе, в журнале IP-пакетов фиксируются пакеты с событием-104.
По умолчанию в ViPNet Coordinator HW включена обработка всех поддерживаемых прикладных протоколов для открытого и защищенного трафика. Для обработки заданы наиболее часто используемые сетевые протоколы и порты (по умолчанию настроены порты 5060, 5080 по протоколам tcp, udp).
В первую очередь необходимо убедиться, что на всем пути следования пакета, не происходит обработки данного пакета правилами NAT, так как между SIP-клиентами нельзя использовать статическую или динамическую трансляцию адресов.
Чтобы установить сеанс связи между SIP-клиентами, убедитесь, что включена обработка протокола SIP, это можно сделать, выполнив команду: alg show (см. документ «ViPNet Coordinator HW 4. Настройка с помощью командного интерпретатора», раздел «Настройка параметров обработки прикладных протоколов), а также создайте фильтр открытой сети, разрешающий входящее и исходящее соединение по протоколам TCP и UDP на порт 5060 (если хотя бы один из SIP-клиентов является открытым узлом).
Кроме того, рекомендуется проверить, что в модуле обработки прикладных протоколов [alg] заданы корректные протоколы и порты, по которым работает ваши SIP-сервер и SIP-клиент.
Не поддерживаются SIP-клиенты и телекоммуникационные серверы, использующие при подключении протокол TLS, SIP-клиенты, использующие (compact headers), а также SIP-клиенты, использующие сжатие данных в сообщениях SIP.
Для некоторых SIP-клиентов могут не обрабатываться такие дополнительные данные, как телефонные справочники, информация о доступности абонента и другие.
Список поддерживаемых прикладных протоколов изменить нельзя.
ViPNet Coordinator HW также поддерживает обработку прикладного протокола Cisco NetMeeting для организации видеоконференций, но только при использовании видимости по реальным IP-адресам между клиентским ПО Cisco NetMeeting Application в сети ViPNet и туннелируемым сервером Cisco NetMeeting.
Между координатором и другими защищенными или туннелируемыми узлами успешно проходит проверка соединения (ping), но не устанавливается TCP-соединение, а также возможна задержка передачи конвертов и деловой почты.
Причиной блокирования шифрованных IP-пакетов, передаваемых в рамках TCP-соединения, может быть фрагментация этих IP-пакетов на устройствах, стоящих на пути от отправителя к получателю.
Проблема возникает при инкапсуляции больших пакетов, например: PPPoE + ViPNet, GRE + ViPNet и т.д. Подробнее о работе стека протокола TCP/IP, параметров MSS и MTU, можно найти в открытых источниках интернет.
Во избежание фрагментации рекомендуется уменьшить размер IP-пакетов, принимаемых на узле, присвоив параметру mssdecrease* значение от 50 до 200 байт. Чтобы уменьшить размер исходящих IP-пакетов узла, значение параметра mssdecrease следует изменить на узле получателя этих IP-пакетов. Для установления TCP-соединения достаточно изменить параметр mssdecrease на одном из взаимодействующих узлов.
* — подробнее см. в документе «ViPNet Coordinator HW 4. Справочное руководство по конфигурационным файлам», глава «Файл iplir.conf» раздел «Секция [misc]».
Для решения этой проблемы необходимо выполнить переинициализацю ПАК. Для этого нужно удалить ключи командой: admin remove keys*.
На запрос подтверждения удаления, набрать команду Yes, нажать клавишу «Ввод» (Enter).
* — более подробно о данной команде см. «ViPNet Coordinator HW 4. Справочное руководство по командному интерпретатору» раздел «Команды группы admin».
При инициализации ПАК HW выходит ошибка: «Virtual appliance is detected».
Неправильно настроен BIOS. Необходимо зайти в BIOS и выполнить настройки для данной платформы, согласно документу «ViPNet Coordinator HW 4. Подготовка к работе» раздел «Настройка параметров BIOS».
Если вход в BIOS на вашей платформе заблокирован, следует отправить ПАК в сервисный центр ИнфоТеКС, предварительно обратившись в техническую поддержку ИнфоТеКС по следующему адресу электронной почты: hotline@infotecs.ru.
При включении ПАК HW50 на мониторе нет изображения.
Такое возможно, если монитор подключен к ПАК через переходники, например через переходник VGA-HDMI. ПАК HW50 необходимо подключать напрямую к монитору, имеющему разъем HDMI, без использования каких-либо переходников.
Необходимо организовать подключение координатора к двум провайдерам для обеспечения использования несколько шлюзов (провайдеров), например для распределения нагрузки на каналы сети или резервирования каналов при использовании нескольких интернет-провайдеров на случай отказа одного из них (чтобы избежать потерь трафика).
Механизм, позволяющий распределить нагрузку на сеть или настроить резервные каналы доступа в интернет для сетей, в инфраструктуре которых используется несколько шлюзов (провайдеров), реализован в HW4.3.0.
После настройки координатора HW в режиме работы системы защиты от сбоев (кластер горячего резервирования/Failover) ноды циклически перезагружаются.
Рекомендуется проверить корректность выполненных настроек в файле failover.ini, согласно документу «ViPNet Coordinator HW 4. Сценарии работы», раздел «Назначение и принципы работы системы защиты от сбоев».
На практике часто применяются схемы подключения кластера горячего резервирования к коммутаторам, маршрутизаторам и другому коммутационному оборудованию. Настройки данного оборудования могут влиять на работу кластера горячего резервирования. В частности, администратор такого оборудования может настроить блокирование тех или иных сетевых пакетов, среди которых могут оказаться служебные пакеты, необходимые для корректного функционирования ViPNet Coordinator HW в режиме кластера горячего резервирования.
В связи с этим при использовании коммутационного оборудования с кластером горячего резервирования необходимо убедится, что на этом оборудовании пропускаются эхо-запросы ICMP с IP-адресов активного сервера до всех узлов c IP-адресами, заданными в параметрах testip секции [channel] файла failover.ini и ответы на них, а также ARP-запросы с IP-адресов пассивного сервера до IP-адресов активного сервера и ответы на них. Данные рекомендации касаются всех сетевых интерфейсов ViPNet Coordinator HW, для которых существует секция [channel] в файле failover.ini.
Если проблема остается, необходимо обратиться в техническую поддержку ИнфоТеКС по следующему адресу электронной почты: hotline@infotecs.ru.
Невозможно подключиться к ПАК HW по SSH, при этом есть доступ через веб-консоль.
Убедитесь, что координатор доступен по 22 порту (например, выполнив команду telnet с любого защищенного узла, связанного с координатором). Если координатор недоступен, проверьте наличие и активность разрешающих правил доступа в настройках межсетевого экрана на координаторе.
Если проверка прошла успешно, но по SSH подключиться невозможно, рекомендуется выполнить перепрошивку ПАК. Следует обратиться в техническую поддержку ИнфоТеКС по следующему адресу электронной почты: hotline@infotecs.ru.
Функционал сброса ключей авторизации будет реализован в новых версиях ПО ViPNet Coordiantor HW.
При подключении к веб-интерфейсу координатора, выдается сообщение: «Действующий персональный ключ станет неактуальным: [дата] / Действующий персональный ключ истек» или при входе в режим администратора на ПАК появляется надпись: «User keys will expire. »
Необходимо обновить ключи; для этого следует обратиться к администратору сети ViPNet. Кроме того, перед обновлением ключей вы должны убедиться, что на узле присутствует резервный набор персональных ключей пользователя (РНПК). При отсутствии РНПК его следует добавить на узел.
Подробнее см. документ «ViPNet Coordinator HW 4. Настройка с помощью командного интерпретатора», разделы «Обновление ключей при истечении срока их действия», «Добавление резервного набора персональных ключей (РНПК)».
Для продления срока действия персонального ключа необходимо в УКЦ поднять вариант ключей пользователя для сетевого узла данного координатора, сформировать справочники и отправить на проблемный узел. Предварительно убедиться, что на ПАК установлен действующий резервный набор персональных ключей (РНПК).
Во избежание возможных ошибок рекомендуется предварительно создать резервную копию настроек ПАК, выполнив команду admin export keys binary-encrypted
См. документ «ViPNet Coordinator HW 4. Справочное руководство по командному интерпретатору», «ViPNet Удостоверяющий и ключевой центр 4. Руководство администратора» раздел «Изменение вариантов персонального ключа пользователя и ключей узла».
При просмотре журнала пакетов на ПАК HW отображается информация только о заблокированных пакетах.
Для отображения всех пакетов необходимо включить функцию регистрации всех пакетов на сетевых интерфейсах координатора.
Завершите работу демона iplir с помощью команды iplir stop.
Откройте конфигурационный файл для редактирования с помощью команды iplir config ethX, где Х — номер сетевого интерфейса.
В секции [db] измените следующие параметры установите параметр registerall = on.
Сохраните изменения в файле и запустите демон iplir с помощью команды iplir start.
Более подробно см. в документе «ViPNet Coordinator HW 4. Справочное руководство по конфигурационным файлам».
От узлов сторонней сети ViPNet, с которой не задана связь в ЦУСе, блокируется трафик, который должен проходить через координатор собственной сети ViPNet.
Для решения проблемы необходимо настроить межсетевое взаимодействие между этими сетями или выполнить настройку прохождения трафика от узла сторонней сети в «обход» координатора вашей сети.
Функционал обработки защищенных IP-пакетов для узлов ViPNet, связь с которыми не задана в программе «ViPNet Центр управления сетью», реализован в HW4.2.2 и выше.
Невозможно зайти в BIOS ПАК HW.
В новых платформах доступ в BIOS заблокирован для пользователей.
Если требуется перепрошивка ПАК, следует отправить ПАК в сервисный центр ИнфоТеКС, предварительно необходимо обратиться в техническую поддержку ИнфоТеКС по следующему адресу электронной почты: hotline@infotecs.ru.
При входе в режим enable не подходит пароль администратора сети.
При наличии связи между узлом администратора сети ViPNet и координатором необходимо в ПО ViPNet Администратор (УКЦ/ЦУС) сформировать актуальные справочники, отправить их на Координатор и убедиться, что они применились*.
При отсутствии связи необходимо выполнить перепрошивку ПАК.
* См. документы «ViPNet Удостоверяющий и ключевой центр 4. Руководство администратора» и «ViPNet Центр управления сетью 4. Руководство администратора».
Между координаторами в очереди MFTP зависают конверты; после перезапуска MFTP конверты отправляются.
Для устранения проблемы необходимо изменить параметр outenv_timeout секции [misc] конфигурационного файла mftp.conf.
Более подробно см. в документе «ViPNet Coordinator HW 4. Справочное руководство по конфигурационным файлам».