Как настроить nethasp.ini, чтобы клиенты 1С брали лицензии с нужного сервера HASP?

В корпоративных сетях нередко возникает ситуация, когда в инфраструктуре одновременно функционируют два менеджера лицензий HASP License Manager: например, один с ключом на 20 пользователей, а второй — на 5 пользователей. При работе пользователей через терминальный сервер (RDP) часто обнаруживается проблема: несмотря на указание целевого сервера, клиентские сессии продолжают опрашивать второй сервер и занимать слоты на небольшом ключе. Разберем по шагам, почему так происходит и как правильно сконфигурировать сетевой доступ к ключам защиты.

Анализ причин некорректного захвата лицензий

Проанализируем ситуацию: клиентская платформа 1С при запуске инициирует поиск доступного аппаратного ключа по определенному алгоритму. Если настройки заданы не полностью или с ошибками, драйвер переходит к широковещательному опросу сети (Broadcast). В результате клиенты перехватывают первый ответивший менеджер лицензий, игнорируя предполагаемое разделение.

Выясним основные причины подобного поведения:

1. Включенный широковещательный опрос: если параметр NH_USE_BROADCAST не отключен явным образом, служба ищет ключ по всей подсети через широковещательные пакеты.
2. Ошибки в секциях конфигурационного файла: параметры настройки протокола TCP/IP указаны вне соответствующего блока или содержат синтаксические ошибки.
3. Проблемы с NetBIOS и разрешением имен: указание сетевых имен серверов (NH_SERVER_NAME) на современных версиях Windows Server может работать нестабильно, поэтому надежнее использовать прямую IP-адресацию.
4. Дублирование файлов конфигурации: на терминальном сервере может присутствовать несколько версий файла nethasp.ini, и платформа считывает не тот файл, который редактировался администратором.

Корректная настройка файла nethasp.ini

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

Откроем файл текстовым редактором и зададим явное ограничение по протоколу TCP/IP, выключив остальные сетевые протоколы и широковещание:

[NH_COMMON]
NH_TCPIP = Enabled
NH_IPX = Disabled
NH_NETBIOS = Disabled

[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.20
NH_USE_BROADCAST = Disabled
NH_TCPIP_METHOD = TCP

Разберем подробнее ключевые директивы данного примера:

1. Параметр NH_TCPIP = Enabled включает обработку только протокола TCP/IP, в то время как NH_IPX и NH_NETBIOS со значением Disabled предотвращают паразитные сетевые запросы.
2. Параметр NH_SERVER_ADDR задает конкретный статический IP-адрес сервера с ключом на 20 лицензий (без масок подсетей и лишних символов).
3. Параметр NH_USE_BROADCAST = Disabled принудительно запрещает широковещательный поиск по локальной сети, исключая случайное обращение к серверу с 5 лицензиями.
4. Директива NH_TCPIP_METHOD = TCP переключает механизм обмена пакетами на протокол TCP, что обеспечивает стабильное соединение в современных терминальных средах.

Где должен располагаться файл nethasp.ini на сервере терминалов

Выясним причину, по которой изменения могут не вступать в силу даже при идеальном синтаксисе. Платформа 1С ищет файл настроек в каталоге исполняемого файла текущего релиза (папка bin), в рабочем каталоге ярлыка и в системных директориях Windows. При установке нового релиза платформы клиенты начинают запускаться из новой папки, где файла nethasp.ini по умолчанию нет.

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

1. Для 32-разрядного клиента 1С на 64-битной операционной системе скопируем файл в каталог C:\Windows\SysWOW64.
2. Для 64-разрядного клиента 1С скопируем файл в каталог C:\Windows\System32.

Важно: убедимся, что в папках bin установленных версий платформы отсутствуют другие файлы nethasp.ini, которые могут переопределять глобальные правила.

Ограничение доступа на стороне сервера лицензий (nhsrv.ini)

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

Перейдем на сервер с 5 лицензиями, откроем файл nhsrv.ini (находится в каталоге установки HASP License Manager) и в секции [NHS_IP] настроим параметр NHS_IP_LIMIT. Данный параметр позволяет строго определить диапазон IP-адресов, которым разрешено запрашивать лицензии с данного ключа. Если исключить из этого списка IP-адрес терминального сервера, служба будет сбрасывать запросы от RDP-пользователей на сетевом уровне, вынуждая платформу работать только с сервером на 20 лицензий.

Диагностика и проверка получения лицензий

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

1. Диалоговое окно «О программе»: запустим клиент 1С от имени пользователя на RDP-сервере и откроем пункт меню «Справка — О программе». В блоке Лицензия найдем строчку «Текущая». Там отображается точный сетевой адрес HASP LM, порт, сетевое имя машины и номер серии ключа, с которого была получена лицензия.
2. Монитор лицензий: используем утилиту HASP Monitor (Aladdin Monitor) для наблюдения за распределением лицензий в режиме реального времени. В окне утилиты отображаются оба менеджера лицензий, списки активных сессий и IP-адреса подключенных рабочих мест, что позволяет мгновенно зафиксировать несанкционированные подключения.

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