← На главную

Перевод инфраструктуры «1С:Предприятия» на платформы виртуализации и отказоустойчивые кластеры серверов часто сталкивается с проблемой миграции аппаратных ключей защиты USB (HASP HL). При динамическом перемещении виртуальных машин между физическими хостами (vMotion, Live Migration) физический USB-порт сервера привязан к одной ноде. Популярным решением является использование отдельных сетевых концентраторов USB-over-IP (например, линейки Digi AnywhereUSB). Однако администраторы часто наблюдают ситуацию: ключ вставлен в сетевой концентратор, но на нем даже не загорается светодиод, а виртуальная машина не видит лицензий. Разберем детально, почему так происходит и как правильно настроить передачу лицензий в виртуальную среду.

Почему не горит светодиод на ключе 1С в сетевом концентраторе

Проанализируем поведение аппаратных ключей HASP (в частности, серий H4 M1 ORGL8). В отличие от стандартных флеш-накопителей или простых токенов, ключи HASP ведут себя иначе:

1. При подключении в пассивный USB-разъем или в сетевой хаб без установленного сеанса питания на порт не подается полная инициализация, либо ключ переходит в режим ожидания. В этот момент светодиод на ключе не горит.
2. Светодиод активируется только тогда, когда драйвер хостовой операционной системы (виртуальной машины) захватывает физический порт по сети, успешно передает USB-дескрипторы и переводит устройство в рабочий режим.
3. При выключении виртуальной машины или разрыве сетевого соединения с хабом светодиод на ключе немедленно гаснет.

Таким образом, отсутствие индикации непосредственно при установке ключа в аппаратную коробку не означает неисправность порта или ключа. Ключ начнет светиться только после полной цепочки проброса и инициализации драйвером на целевом сервере.

Пошаговая настройка проброса ключа через AnywhereUSB

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

1. Настройка сетевого концентратора: подключаем устройство к коммутатору, задаем статический IP-адрес через веб-интерфейс. В настройках многопортовых устройств обязательно проверяем распределение портов по группам (Group Assignment). Если порт с ключом не назначен активной группе, клиент не сможет его подключить.
2. Установка клиентского ПО на виртуальную машину: на гостевую ОС устанавливаем драйвер и утилиту управления концентратором (AnywhereUSB Remote Hub Configuration Utility).
3. Подключение группы портов: в утилите находим сетевой хаб по его IP-адресу и выполняем подключение (Connect) нужной группы портов к виртуальной машине.
4. Установка драйверов защиты: после того как порт успешно примонтирован как локальный USB-контроллер, устанавливаем драйвер защиты Sentinel LDK / HASP. Рекомендуется использовать официальную утилиту командной строки для чистой установки стека драйверов: haspdinst.exe -i -fi Параметр -fi принудительно обновляет и перезаписывает файлы драйвера в системе.
5. Проверка состояния: убеждаемся, что светодиод на ключе загорелся. В диспетчере устройств виртуальной машины в ветке контроллеров USB или устройств чтения смарт-карт должен появиться SafeNet Inc. HASP Key или Sentinel HASP Key.

Сетевые требования и тайм-ауты протокола HASP

Проанализируем требования к локальной сети между концентратором USB-over-IP и виртуальной машиной. Протокол обмена с ключами защиты крайне чувствителен к задержкам передачи пакетов:

1. Задержка (Latency): пинг между виртуальной машиной и сетевым хабом не должен превышать 10–15 мс. В идеальных условиях они должны находиться в одном сегменте L2 или быстром коммутируемом VLAN. При потере пакетов ключ внезапно пропадает из системы, что приводит к аварийному завершению сеансов пользователей в 1С.
2. Сетевые порты: сетевые экраны не должны блокировать служебные порты обмена концентратора (стандартно TCP 3385, 3422 в зависимости от модели оборудования) и трафик службы лицензирования 1С (порт TCP/UDP 475).
3. Режим работы USB: ключи HASP базируются на стандарте USB 1.1 / 2.0. Если веб-интерфейс сетевого концентратора позволяет переключать стандарты портов, рекомендуется принудительно зафиксировать порт в режиме совместимости USB 2.0, чтобы исключить сбои на контроллерах USB 3.0.

Ограничения HASP: несколько ключей и правило одной серии

Если в инфраструктуре используется несколько клиентских аппаратных ключей, важно учитывать архитектурные ограничения защиты HASP. Распространенная ошибка — проброс двух ключей одной серии (например, двух сетевых ключей по 20 пользователей с маркировкой ORGL8) в одну и ту же виртуальную машину.

Менеджер лицензий HASP License Manager способен работать только с одним ключом одной серии на уровне одной операционной системы. Если в одну виртуальную машину подключить два ключа одной серии, служба инициализирует только один из них (как правило, с большим номиналом), а второй будет полностью проигнорирован. Суммирования лицензий на одном сервере не произойдет.

Чтобы задействовать несколько ключей одной серии, разделим их между разными узлами сети:

1. Назначаем в конфигураторе сетевого USB-концентратора порты с ключами в разные группы (например, Port 1 -> Group 1, Port 2 -> Group 2).
2. Пробрасываем Group 1 в первую виртуальную машину (Server-Lic1), а Group 2 — во вторую виртуальную машину (Server-Lic2).
3. На каждой виртуальной машине поднимаем отдельную службу HASP License Manager (файл nhsrvice.exe).
4. На стороне клиентов и серверов кластера 1С выполняем тонкую настройку файла nethasp.ini. Отключаем широковещательные рассылки и жестко прописываем адреса обеих машин:
   Скопировать код

   
   [NH_COMMON]
   NH_TCPIP = Enabled
   
   [NH_TCPIP]
   NH_SERVER_ADDR = 192.168.1.10, 192.168.1.11
   NH_USE_BROADCAST = Disabled
   NH_TCPIP_METHOD = TCP
   

Альтернативные архитектурные решения для виртуальной среды

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

1. Выделенный микросервер лицензирования: вместо проброса портов в тяжелые, постоянно перемещающиеся виртуальные машины баз данных создаем одну легкую, статичную виртуальную машину. На ней разворачивается менеджер лицензий HASP, куда монопольно направляется сетевой ключ. Кластер 1С обращается к ней исключительно по сети через протокол TCP 475. Это изолирует сервер 1С от сбоев в работе USB-стека.
2. Требования назначения функциональности кластера 1С: если используется 64-битный серверный ключ защиты, в кластере серверов «1С:Предприятия 8.3» настраиваем требования назначения функциональности. Закрепляем сервис лицензирования за конкретным сервером кластера, на котором физически или виртуально доступен ключ, освобождая остальные рабочие процессы от необходимости локального доступа к USB.
3. Программные лицензии: наиболее естественным решением для динамических облачных сред и кластеров с частой миграцией нод является переход с аппаратных ключей HASP на программные пин-коды (электронные лицензии), которые не зависят от физических USB-устройств и сетевых хабов.