Вопросы и ответы: ViPNet Coordinator HW

При задействованном процессе ALG, такая ситуация возможна по нескольким причинам.

В качестве быстрого устранения проблемы, в случае если нет необходимости в обработке трафика приклодных протоколов (TFTP, SCCP, NTP, DNS, SIP, H323) рекомендуется отключить ALG (см. документ «ViPNet Coordinator HW 4. Справочное руководство по командному интерпретатору», раздел «Команды группы alg»). Если отключение ALG не помогло, необходимо обратиться в техническую поддержку ИнфоТеКС по следующему адресу электронной почты: hotline@infotecs.ru.

Все действия над учетной записью пользователя (смена пароля, удаление) необходимо выполнять только локально на ViPNet Coordinator HW.

Пароль пользователя ViPNet Coordinator HW можно изменить только локально, как описано ниже. Смена пароля пользователя удаленно (с помощью программы ViPNet Центр управления сетью (ЦУС)) невозможна.

Чтобы изменить пароль пользователя, выполните следующие действия:

  1. В режиме администратора (enable) выполните команду: admin passwd.
  2. Введите текущий пароль пользователя или пароль администратора сетевого узла.
    Внимание! При вводе паролей на экране ничего не отображается, введенные символы отредактировать нельзя.
  3. Введите новый пароль пользователя и подтвердите его. Появится сообщение об успешном изменении пароля пользователя.

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

Более подробно, см. в документе: «ViPNet Coordinator HW 4. Настройка с помощью командного интерпретатора» раздел «Настройка параметров безопасности».

Для реализации переноса необходимо выполнить следующие действия:

  1. В ЦУС для данного координатора изменить роль на необходимую: например, при замене программного координатора на ПАК HW1000 следует указать роль «Coordinator HW1000».
    Внимание! Рассылку справочников до полного завершения работ выполнять не нужно!
  2. Сформировать новый dst файл для этого узла, выполнить первичную инициализацию и настройку ПАК HW в соответствии с настройками действующего программного координатора.
  3. Подключить ПАК HW в изолированном сегменте и проверить, что связь работает корректно.
  4. В технологический перерыв произвести переключение на ПАК HW, убедиться, что связь с узлами установлена.
  5. Проверить работоспособность бизнес-сценариев.
  6. В ЦУС сформировать и отправить справочники на тестовую группу АП, проверить, что они проходят и применяются корректно.
  7. В ЦУС переименовать пользователя программного координатора на ПАК HW (при необходимости), после чего разослать справочники на все узлы.

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

В случае возникновения проблем на выполнении п. 4–7 можно произвести переключение обратно на программный координатор.

Внимание! В данном примере не рассматривается задача по переносу очереди MFTP с программного координатора на ПАК HW.

Аналогично, можно проводить замену ПАК HW различных платформ, например, в случае замены ПАК HW на более производительную платформу.

Первоначально, необходимо убедиться, что платформа ПАК поддерживает версию 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.

Перед выполнением обновления с версии 3.х до версии 4.х необходимо предварительно убедиться, что данная платформа поддерживает версию 4.х.

К тому же до проведения обновления необходимо выполнить команду смены пароля пользователя ViPNet Coordinator HW — admin passwd.

Пароль можно оставить тот же что и был, после чего повторить обновление ПАК.

Более подробно о команде «admin passwd» см. в документе «ViPNet Coordinator HW 4. Справочное руководство по командному интерпретатору» раздел «Команды группы admin».

В ViPNet Coordinator HW реализован механизм создания временных задержек при неуспешном вводе пароля.

Если пользователь или администратор вводит неверный пароль, перед следующей попыткой ввода пароля ему нужно подождать несколько секунд. Задержка реализована для предотвращения возможности подбора пароля методом перебора. С каждой новой неуспешной попыткой ввода пароля задержка увеличивается. Если был введен неверный пароль 10 раз подряд, задержка составит 25 минут, но после нее можно повторить очередную попытку ввода пароля. При успешном вводе пароля счетчик, который фиксирует неуспешные попытки, обнуляется.

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

По умолчанию в ViPNet Coordinator HW при передаче данных через сетевые интерфейсы используется фиксированный размер MTU, равный 1500 байт.

Возможность изменения MTU на сетевых интерфейсах реализована в HW4.2.2 и выше.

Поддержка функция DHCP-relay и DHCP-сервер при работе в кластере горячего резервирования будет реализована HW4.3.0 и выше.

В предыдущих версиях ViPNet Coordinator HW можно было принудительно запустить автоматическое переназначение виртуальных адресов всех защищенных узлов с помощью параметра startvirtualiphash в секции [virtualip] файла iplir.conf. В результате такого переназначения некоторые узлы могли стать недоступны, поэтому больше данный параметр не используется.

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

Подробнее о настройке виртуальных адресов, см. документ «ViPNet Coordinator HW 4. Настройка с помощью командного интерпретатора», раздел «Настройка параметров виртуальных адресов».

При компрометации и смене мастер-ключей в сети ViPNet обновления справочников и ключей на ViPNet Coordinator HW могут быть приняты только в том случае, если на узле есть резервный набор персональных ключей (РНПК).

Необходимо до смены мастер-ключей проверить наличие РНПК на узле. Узнать о наличии или отсутствии файла с РНПК на узле можно, просмотрев информации о ключах с помощью команды iplir show key-info.

Если файла с РНПК нет, добавьте его на ViPNet Coordinator HW с помощью команды admin add spare keys. В противном случае, выполнить обновление справочников и ключей будет возможно только вручную.

В исполнениях 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, поддерживают только определенные модели 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».

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 для остановки и запуска службы прокси-сервера задействованы несколько дополнительных служб, большую часть времени занимает проверка правил firewall.

Время запуска и остановки служб будет уменьшено в новых версиях ПО.

По умолчанию в 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.

Причиной блокирования шифрованных 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».

Неправильно настроен BIOS. Необходимо зайти в BIOS и выполнить настройки для данной платформы, согласно документу «ViPNet Coordinator HW 4. Подготовка к работе» раздел «Настройка параметров BIOS».

Если вход в BIOS на вашей платформе заблокирован, следует отправить ПАК в сервисный центр ИнфоТеКС, предварительно обратившись в техническую поддержку ИнфоТеКС по следующему адресу электронной почты: hotline@infotecs.ru.

Такое возможно, если монитор подключен к ПАК через переходники, например через переходник VGA-HDMI. ПАК HW50 необходимо подключать напрямую к монитору, имеющему разъем HDMI, без использования каких-либо переходников.

Механизм, позволяющий распределить нагрузку на сеть или настроить резервные каналы доступа в интернет для сетей, в инфраструктуре которых используется несколько шлюзов (провайдеров), реализован в HW4.3.0.

Рекомендуется проверить корректность выполненных настроек в файле 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.

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

Если проверка прошла успешно, но по SSH подключиться невозможно, рекомендуется выполнить перепрошивку ПАК. Следует обратиться в техническую поддержку ИнфоТеКС по следующему адресу электронной почты: hotline@infotecs.ru.

Функционал сброса ключей авторизации будет реализован в новых версиях ПО ViPNet Coordiantor HW.

Необходимо обновить ключи; для этого следует обратиться к администратору сети ViPNet. Кроме того, перед обновлением ключей вы должны убедиться, что на узле присутствует резервный набор персональных ключей пользователя (РНПК). При отсутствии РНПК его следует добавить на узел.

Подробнее см. документ «ViPNet Coordinator HW 4. Настройка с помощью командного интерпретатора», разделы «Обновление ключей при истечении срока их действия», «Добавление резервного набора персональных ключей (РНПК)».

Для продления срока действия персонального ключа необходимо в УКЦ поднять вариант ключей пользователя для сетевого узла данного координатора, сформировать справочники и отправить на проблемный узел. Предварительно убедиться, что на ПАК установлен действующий резервный набор персональных ключей (РНПК).

Во избежание возможных ошибок рекомендуется предварительно создать резервную копию настроек ПАК, выполнив команду admin export keys binary-encrypted {tftp | usb}.

См. документ «ViPNet Coordinator HW 4. Справочное руководство по командному интерпретатору», «ViPNet Удостоверяющий и ключевой центр 4. Руководство администратора» раздел «Изменение вариантов персонального ключа пользователя и ключей узла».

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

  1. Завершите работу демона iplir с помощью команды iplir stop.

  2. Откройте конфигурационный файл для редактирования с помощью команды iplir config ethX, где Х — номер сетевого интерфейса.

  3. В секции [db] измените следующие параметры установите параметр registerall = on.

  4. Сохраните изменения в файле и запустите демон iplir с помощью команды iplir start.

Более подробно см. в документе «ViPNet Coordinator HW 4. Справочное руководство по конфигурационным файлам».

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

Функционал обработки защищенных IP-пакетов для узлов ViPNet, связь с которыми не задана в программе «ViPNet Центр управления сетью», реализован в HW4.2.2 и выше.

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

Если требуется перепрошивка ПАК, следует отправить ПАК в сервисный центр ИнфоТеКС, предварительно необходимо обратиться в техническую поддержку ИнфоТеКС по следующему адресу электронной почты: hotline@infotecs.ru.

При наличии связи между узлом администратора сети ViPNet и координатором необходимо в ПО ViPNet Администратор (УКЦ/ЦУС) сформировать актуальные справочники, отправить их на Координатор и убедиться, что они применились*.

При отсутствии связи необходимо выполнить перепрошивку ПАК.

* См. документы «ViPNet Удостоверяющий и ключевой центр 4. Руководство администратора» и «ViPNet Центр управления сетью 4. Руководство администратора».

Для устранения проблемы необходимо изменить параметр outenv_timeout секции [misc] конфигурационного файла mftp.conf.

  1. Завершите работу демона mftpd с помощью команды mftp stop.
  2. Откройте конфигурационный файл mftp.conf для редактирования с помощью команды mftp config.
  3. В секции [misc] измените следующие параметры: установите параметр outenv_timeout = 280.
  4. Сохраните изменения в файле mftp.conf и запустите демон mftpd с помощью команды mftp start.

Более подробно см. в документе «ViPNet Coordinator HW 4. Справочное руководство по конфигурационным файлам».