Как решить проблему подключения старого HASP-ключа 1С (HASP4) к CentOS 7.5 при ошибке «Лицензия не найдена»?

При переходе на новые серверные платформы под управлением операционных систем семейства Linux, в частности CentOS 7.5, системные администраторы часто сталкиваются с аппаратной несовместимостью старых HASP-ключей защиты 1С (семейства HASP4, обычно красного цвета, без технологического отверстия на корпусе) и современных драйверов Sentinel LDK Runtime. В то время как более новые ключи (HASP HL) определяются и раздают лицензии без дополнительных манипуляций, старые HASP4 выдают критическую ошибку «Лицензия не найдена». При этом физически ключ может определяться в операционной системе и его индикатор будет светиться.

Проанализируем причины такого поведения. Главная сложность кроется в версии микропрограммы (firmware) ключа HASP4. В старых сетевых ключах 1С (например, NET20 ORGL8) используется аппаратная прошивка версии 2.17. В отличие от версий 2.16 или более поздних, прошивка 2.17 защищена от перезаписи и не может быть автоматически обновлена современным драйвером Sentinel LDK до версии 3.25. Соответственно, служба Sentinel Admin Control Center (работающая на порту 1947) физически не видит этот ключ. Для его стабильной работы требуется использовать старый менеджер лицензий hasplm версии 8.30 (работающий по протоколу NetHASP через порт UDP 475) или специализированные сборки драйверов.

Рассмотрим подробные шаги по исправлению данной ситуации и разберем, как заставить старый ключ полноценно функционировать в среде CentOS 7.5.

Шаг 1. Установка библиотек совместимости 32-бит

Рассмотрим первый важный нюанс. Старый менеджер лицензий hasplm версии 8.30, а также сопутствующие утилиты Aladdin являются 32-битными приложениями. В чистой 64-битной системе CentOS 7.5 поддержка 32-битной архитектуры по умолчанию отсутствует. Из-за этого исполняемый файл драйвера может молча аварийно завершать работу. Для решения этой проблемы выполним принудительную установку библиотек совместимости:

yum clean all
yum install glibc.i686 libstdc++.i686 -y

Шаг 2. Корректировка правил udev (80-hasp.rules)

Выясним причину, почему ключ виден в выводе команды lsusb, но драйвер его игнорирует. Современный демон systemd-udevd в CentOS 7 не поддерживает устаревшие параметры правил udev, такие как PHYSDEVBUS и SYSFS. Из-за ошибок разбора udev-правила в логе journalctl менеджер устройств отказывается создавать символическую ссылку на ключ в каталоге /dev/aks/hasp/, куда обращается драйвер.

Отредактируем файл правил udev. Откроем файл /etc/udev/rules.d/80-hasp.rules и приведем его к современному синтаксису, заменив устаревшие параметры на ATTRS:

ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0001", MODE="664", ENV{HASP}="1", SYMLINK+="aks/hasp/%k"

После сохранения файла правил udev обязательно выполним их перезагрузку и применим изменения:

udevadm control --reload-rules
udevadm trigger

Шаг 3. Решение проблемы с отсутствием /proc/bus/usb

Старые версии драйверов HASP жестко завязаны на обращение к USB-устройствам через виртуальную файловую систему usbfs, которая монтировалась по пути /proc/bus/usb/. В ядре CentOS 7 (3.10 и выше) эта подсистема полностью удалена. Разберем, как обойти это ограничение путем привязки директории устройств через опцию bind.

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

mkdir -p /proc/bus/usb
mount --bind /dev/bus/usb /proc/bus/usb

Чтобы монтирование происходило автоматически при каждом запуске сервера CentOS, добавим соответствующую строчку в конфигурационный файл /etc/fstab:

none /proc/bus/usb usbfs defaults 0 0

Шаг 4. Устранение конфликтов служб лицензирования и портов

Проанализируем частую ошибку администраторов: cannot bind to local address: Address already in use. Она возникает, когда в системе одновременно запущены современная служба Sentinel LDK (демон hasplmd) и старый менеджер лицензий hasplm. Они могут пытаться занять одинаковые порты или перехватывать управление USB-интерфейсом.

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

netstat -lunp | grep -E "475|1947"

Если в выводе присутствует запущенный процесс hasplmd, который слушает порт TCP/UDP 1947, его необходимо полностью остановить и исключить из автозапуска, так как он мешает работе старого HASP4 с прошивкой 2.17:

systemctl stop aksusbd
systemctl disable aksusbd

Затем загрузим оригинальный дистрибутив старого HASP LM 8.30. Распакуем его и запустим исполняемый файл hasplm:

tar -xvf hasplm_linux_8.30.tgz
./hasplm

Убедимся, что служба теперь корректно слушает только порт UDP 475:

netstat -pan | grep hasplm

Шаг 5. Альтернативное решение: использование готовых драйверов от Etersoft

Разберем наиболее надежный и проверенный на практике метод автоматизации всех предыдущих шагов. Российская компания Etersoft выпускает специализированную сборку драйверов haspd для Linux, которая содержит все необходимые исправления udev, автоматическое монтирование каталогов USB и правильные версии демонов.

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

yum remove aksusbd

Перейдем к установке пакетов от Etersoft. Нам понадобятся RPM-пакеты, совместимые с CentOS 7. Скачаем и установим актуальную версию HASP-драйвера:

yum install https://download.etersoft.ru/pub/Etersoft/HASP/last/CentOS/7/haspd-7.90-etersoft1.x86_64.rpm -y

После завершения установки добавим службу в автозапуск системы и запустим её:

systemctl enable haspd
systemctl start haspd

Служба Etersoft автоматически определит подключенный ключ HASP4 (даже с проблемной прошивкой 2.17) и запустит корректный менеджер лицензий на порту UDP 475.

Шаг 6. Настройка клиентских компьютеров (nethasp.ini)

Поскольку старый менеджер лицензий под управлением Linux работает исключительно по протоколу NetHASP через порт UDP 475, широковещательный поиск (Broadcast) в современных корпоративных сетях часто работает нестабильно. Чтобы рабочие станции гарантированно получали лицензии, настроим конфигурационный файл nethasp.ini на стороне клиентов.

Найдем файл nethasp.ini на клиентском компьютере с ОС Windows (обычно он располагается в каталоге C:\Program Files\1cv8\conf\ или в папке установки платформы). Отредактируем секцию [NH_TCPIP], отключив широковещательный поиск и принудительно указав статический IP-адрес нашего сервера CentOS 7.5:

[NH_COMMON]
NH_TCPIP = MicroSoft Spx

[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.100  ; Укажите IP-адрес вашего сервера CentOS
NH_PORT_NUMBER = 475
NH_TCPIP_METHOD = TCP_or_UDP
NH_USE_BROADCAST = Disabled

Сохраним изменения в файле nethasp.ini и запустим 1С:Предприятие. После выполнения данных настроек подключение к старому ключу HASP4 будет происходить мгновенно в обход стандартных механизмов Sentinel ACC.

Шаг 7. Настройка брандмауэра Firewalld и политики SELinux

Проанализируем еще одну частую проблему: даже если все службы запущены корректно, брандмауэр firewalld или система безопасности SELinux в CentOS 7.5 могут блокировать сетевые запросы к портам HASP. Разберем, как правильно разрешить сетевой трафик.

Для корректной работы NetHASP нам требуется открыть порты UDP 475 и TCP/UDP 1947. Выполним следующие команды в терминале CentOS:

firewall-cmd --permanent --zone=public --add-port=475/udp
firewall-cmd --permanent --zone=public --add-port=1947/tcp
firewall-cmd --permanent --zone=public --add-port=1947/udp
firewall-cmd --reload

Если SELinux переведен в режим жесткой фильтрации (Enforcing), он может заблокировать доступ процесса hasplm к USB-шине. Проверим статус SELinux:

sestatus

Для временного перевода SELinux в режим предупреждений выполним команду:

setenforce 0

Чтобы зафиксировать это изменение перманентно, отредактируем конфигурационный файл /etc/selinux/config, установив параметр:

SELINUX=permissive

Выполнив указанные шаги по настройке брандмауэра и SELinux, мы гарантируем, что сетевые пакеты беспрепятственно дойдут от клиентских ПК с 1С до нашего сервера CentOS с HASP-ключом.