Что делать, если часть пользователей 1С не видит сетевой ключ лицензии после сбоя сервера?

← На главную

В крупных распределенных сетях нередко возникает ситуация, когда аппаратные ключи HASP (NetHASP) перестают определяться на конкретной группе компьютеров. При этом остальная часть пользователей (например, 150 из 170) продолжает работать в штатном режиме. Ситуация осложняется, если "традиционные" методы (перезагрузка, чистка кэша) не помогают. В этой статье мы разберем сложный случай, связанный с сетевыми ошибками, и научимся диагностировать проблему с помощью технологического журнала и анализа сетевого трафика.

Анализируем исходную ситуацию

Рассмотрим сценарий: имеется три выделенных сервера лицензий, на каждом из которых проброшен USB-ключ на 100 лицензий. Изначально все работало корректно, но после внезапного зависания и перезагрузки виртуального сервера 1С часть клиентов (15-20 рабочих станций) перестала получать лицензии. При запуске программа выдает стандартное сообщение: "Информационная база не обнаружена. Не найдена лицензия. Не обнаружен ключ защиты программы...".

При этом первичная диагностика показывает противоречивые данные:

Файл nethasp.ini настроен верно, в нем явно прописаны IP-адреса серверов.
Утилита Aladdin Monitor на проблемных машинах видит все ключи и свободные лицензии.
Команда telnet на порт 475 проходит успешно.
Локальные базы также не запускаются, что исключает проблему конкретной серверной базы данных.

Диагностика через Технологический журнал 1С

Когда внешние признаки не дают ответа, необходимо обратиться к "первоисточнику" — Технологическому журналу (ТЖ) на стороне клиента. Для этого создадим файл logcfg.xml в папке conf платформы. Проанализируем фрагмент лога, полученного с проблемного компьютера:


11:16.167006-0,EXCP,0,process=1cv8,ClientID=0,Exception=NetDataExchangeException,
Descr='descr=10038(0x00002736): Сделана попытка выполнить операцию на объекте, не являющемся сокетом. 
line=955 file=src\HeartbeatThreadImpl.cpp'

Разберем, что означает эта ошибка. Системная ошибка 10038 (WSAENOTSOCK) указывает на то, что сетевая подсистема Windows попыталась выполнить операцию с дескриптором, который уже не является валидным сокетом. В контексте 1С это часто происходит в потоке HeartbeatThread, который отвечает за поддержание связи с ключом защиты. Если пакеты лицензирования "теряются" или обрываются на уровне сетевого оборудования, сокет закрывается, и при следующей попытке обращения 1С получает отказ.

Проблема протоколов: Почему Telnet врет?

Частая ошибка системных администраторов — проверка доступности порта 475 через telnet. Дело в том, что telnet работает по протоколу TCP. Однако менеджер лицензий HASP License Manager (HASP LM) и платформа 1С для поиска ключа преимущественно используют протокол UDP.

Проанализируем файл настроек nethasp.ini. Многие пытаются форсировать использование TCP:


[NH_COMMON]
NH_TCPIP = Enabled

[NH_TCPIP]
NH_SERVER_ADDR = 10.1.15.166, 10.1.15.167, 10.1.15.168
NH_TCPIP_METHOD = TCP
NH_USE_BROADCAST = Disabled

Важно понимать: параметр NH_TCPIP_METHOD = TCP во многих версиях HASP LM игнорируется или работает нестабильно. Основной обмен идет по UDP. Если в сети между подсетями настроены правила фильтрации, которые пропускают TCP, но блокируют или ограничивают UDP-трафик (например, из-за политик Flood Control), то telnet покажет "ОК", а лицензия получена не будет.

Выявление сетевых аномалий и влияние MTU

В рассматриваемом случае выяснилось, что перевод компьютера в другую подсеть мгновенно решал проблему. Это доказывает наличие ошибок в сетевом сегменте или на маршрутизаторе. Рассмотрим причины, почему пакеты лицензирования могут отбрасываться:

Фрагментация пакетов (MTU): Если путь от клиента к серверу лицензий проходит через туннели (VPN) или оборудование с заниженным значением Maximum Transmission Unit, UDP-пакеты могут фрагментироваться. Некоторые брандмауэры настроены так, чтобы отбрасывать фрагментированные UDP-пакеты в целях безопасности. Проверить это можно командой: ping -f -l 1472 [IP_сервера]. Если пакет не проходит без фрагментации, нужно корректировать настройки сети.
Ошибки ARP-таблиц: После сбоя сервера сетевое оборудование могло закэшировать некорректные записи. Помогает очистка таблицы ARP или перезагрузка промежуточных коммутаторов.
Интерференция со стороны ПО безопасности: Ошибка 10038 часто вызывается драйверами фильтрации (WFP), которые используют антивирусы и DLP-системы. Даже если антивирус отключен в интерфейсе, его драйвер в стеке TCP/IP может продолжать блокировать "подозрительные" (с его точки зрения) UDP-пакеты 1С.

Исследование логов HASP (статус 129)

Проанализируем еще один лог из ТЖ, касающийся непосредственно работы с HASP:


22:52.924002-1,HASP,2,process=1cv8c,Txt=' NETHASP_LASTSTATUS(,prog=17,ser=ORG8A,,,,)->NStat=129,SysErr=0,stat=0,'

Код статуса NStat=129 (HASP_BROKEN_CONNECT) является ключевым. Он говорит о том, что соединение с менеджером лицензий было успешно инициировано, но затем было принудительно разорвано. Это типичное поведение при нестабильной работе сети или при срабатывании таймаутов на сетевом оборудовании. Если бы ключ просто не был найден, мы бы увидели статус 131 (ключ не найден) или 133 (сервер не отвечает).

Пошаговый план решения проблемы

Если вы столкнулись с подобной ситуацией, выполните следующие действия вместе с сетевыми инженерами:

Шаг 1. Оптимизация nethasp.ini

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


[NH_COMMON]
NH_TCPIP = Enabled

[NH_TCPIP]
NH_SERVER_ADDR = 10.1.15.166  ; Указываем только один сервер для теста
NH_PORT_NUMBER = 475
NH_TCPIP_METHOD = UDP         ; Явно указываем UDP
NH_USE_BROADCAST = Disabled

Шаг 2. Проверка аппаратной части и драйверов

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

Перезапустите службу Sentinel LDK License Manager.
Если используется USB-over-IP (например, AnywhereUSB), проверьте состояние подключения в концентраторе.
Убедитесь, что в файле nhsrv.ini на сервере не заданы ограничения по IP (параметр NHS_IP_LIMIT).

Шаг 3. Анализ сетевого оборудования

Попросите администраторов проверить логи на коммутаторах, обслуживающих "проблемную" подсеть. Ищите ошибки входа/выхода (Inbound/Outbound errors) на портах и признаки срабатывания защиты от штормов. Как показала практика в данной теме, именно некорректная работа сетевого сегмента (возможно, после скачка напряжения или программного сбоя коммутатора) стала причиной отказа в получении лицензий.

Резюме

Проблема с лицензиями 1С не всегда лежит в плоскости самой программы. Когда "один работает, а другой — нет", всегда смотрите в сторону сетевой топологии и системных ошибок сокетов. Ошибка 10038 и статус HASP 129 — это прямые маркеры того, что пакеты лицензирования "режутся" инфраструктурой. Временным решением может стать использование терминального сервера (где клиент 1С и ключ находятся в одном сегменте), но для полноценного исправления требуется аудит сетевого оборудования в проблемной подсети.