При работе с платформой 1С:Предприятие через веб-интерфейс технические специалисты часто сталкиваются со специфической проблемой: пользователи не могут войти в базу через браузер, получая сообщение "Не найдена лицензия. Не обнаружен ключ защиты программы или полученная программная лицензия!". При этом на тех же компьютерах и под теми же учетными записями тонкий клиент 1С запускается без каких-либо сложностей. Дополнительную загадочность ситуации придает то, что проблема может внезапно возникать и так же неожиданно исчезать без видимых изменений в инфраструктуре.
В этой статье мы подробно разберем, как устроена архитектура лицензирования веб-клиентов, почему стандартные логи 1С не помогают в диагностике, какие ограничения накладывает использование нескольких аппаратных ключей одной серии и как настроить систему так, чтобы навсегда застраховаться от подобных сбоев.
Прежде чем переходить к настройкам, давайте разберем особенности поведения платформы, которые упоминают администраторы при столкновении с данной ошибкой.
Странность №1: В Журнале регистрации пишется только «Ошибка аутентификации» без подробностей.
При попытке входа через веб-клиент сервер 1С:Предприятия делает запись в Журнале регистрации: Ошибка аутентификации пользователя *******. Ни кодов ошибок, ни явного указания на отсутствие лицензии в логах нет. Почему так происходит? Дело в том, что веб-сервер (Apache или IIS) взаимодействует с кластером 1С через специальный программный модуль расширения. Когда веб-клиент инициирует сеанс, сервер 1С начинает процедуру авторизации и одновременно пытается выделить сеансовую лицензию. Если на этапе создания сеанса сервер не может выдать лицензию, процесс авторизации аварийно прерывается на самом раннем этапе. Платформа интерпретирует это как невозможность корректно завершить вход пользователя и записывает общую ошибку аутентификации.
Странность №2: Разница в поведении параметра «Разрешить выдачу лицензий сервером».
Обратим внимание на поведение системы при изменении настроек информационной базы в консоли кластера:
Выясним причину такой разницы. Когда серверу запрещено раздавать лицензии (значение «Нет»), веб-клиент пытается найти лицензию самостоятельно. Модуль расширения веб-сервера начинает локальный поиск файлов программных лицензий (*.lic) на самом веб-сервере, а затем отправляет широковещательный UDP-запрос в сеть по порту 475 для поиска HASP License Manager. Ожидание ответов от сетевых менеджеров лицензий и тайм-ауты сетевых пакетов как раз и создают ту самую видимую паузу в несколько секунд. Если же параметр установлен в значение «Да», сервер 1С берет поиск на себя. Поскольку сервер уже имеет в своей памяти готовый пул доступных лицензий или точно знает, что связи с HASP-менеджером нет, он мгновенно возвращает отказ веб-клиенту без ожидания сетевых таймаутов.
Для понимания причин сбоя важно уяснить фундаментальное различие между механизмами получения лицензий тонким и веб-клиентом.
Тонкий клиент умеет искать ключи защиты самостоятельно. Он может прочитать локальный ключ на компьютере пользователя, отправить широковещательный запрос в локальную сеть для поиска менеджера лицензий HASP LM или обратиться к серверу 1С (если включена раздача лицензий сервером).
Веб-клиент (браузер) физически не имеет доступа к локальным портам компьютера пользователя и не может отправлять широковещательные UDP-запросы в сеть предприятия. Веб-клиент может получить лицензию только от сервера 1С:Предприятие (или от веб-сервера, если на нем локально установлены файлы программных лицензий). Таким образом, работоспособность веб-интерфейса напрямую зависит от способности сервера 1С обнаружить и забрать лицензии с HASP-ключей.
Здесь мы сталкиваемся с критическим аппаратным ограничением платформы 1С:
Сервер 1С:Предприятие принципиально не может использовать несколько многопользовательских сетевых ключей HASP одной серии.
Ключи серии ORGL8 (это стандартные клиентские аппаратные ключи красного цвета на 5, 10, 20, 50 и 100 пользователей) сервер 1С видит по следующим правилам:
ORGL8 (вставленный непосредственно в USB-порт сервера 1С).ORGL8, доступный через менеджер лицензий HASP LM.Если в вашей локальной сети находятся, например, три ключа (два по 50 лицензий и один на 100), сервер 1С физически сможет работать только с одним из них. Он не умеет суммировать лицензии с разных ключей одной серии по сети.
Многие администраторы отмечают, что система может работать стабильно месяцами, а затем внезапно «сломаться» на день и так же внезапно «починиться». Рассмотрим механизмы, которые приводят к такому плавающему эффекту.
Когда служба сервера 1С запускается, она отправляет широковещательный запрос в сеть для поиска HASP License Manager. Тот менеджер лицензий, который первым успел ответить на запрос сервера, «бронируется» сервером 1С для работы. Оставшиеся в сети ключи той же серии сервер просто игнорирует.
Проанализируем ситуацию: у вас в сети есть ключ на 100 пользователей и два ключа по 50 пользователей. Если при старте сервера первым ответил ключ на 100 пользователей — сервер 1С успешно раздает лицензии веб-клиентам, так как свободных мест много. Если же из-за кратковременной задержки в сети или загрузки процессора первым ответил один из ключей на 50 пользователей (который к тому же уже забит обычными пользователями тонких клиентов), сервер 1С привязывается к нему. Как только лимит лицензий на этом ключе исчерпывается, веб-клиенты начинают получать ошибку "Не найдена лицензия", хотя на ключе 100 пользователей в этот момент может быть свободно 90% лицензий. После планового или внезапного перезапуска служб порядок ответов ключей может измениться, и проблема «исчезнет сама».
При некорректном завершении работы пользователей с веб-клиентом (например, закрыли вкладку браузера крестиком, пропал интернет на стороне пользователя, произошел микросбой сети) сессия в HASP License Manager не закрывается мгновенно. Такие лицензии переходят в режим ожидания. В утилите Aladdin Monitor параметр Timeout у таких сессий принимает значение 0.
Согласно спецификации HASP, время автоматического сброса неактивной («зависшей») сессии может составлять до 36 часов. Все это время лицензия удерживается ключом и считается занятой. Когда лимит лицензий исчерпывается, новые веб-клиенты не могут зайти. Как только проходит 36 часов, HASP LM принудительно освобождает «зомби-сессии», лицензии возвращаются в пул, и работоспособность восстанавливается «сама собой» без вмешательства администратора.
Чтобы гарантировать стабильную работу веб-клиентов и исключить влияние сетевого хаоса на выдачу лицензий, выполним ряд последовательных шагов по настройке.
Мы должны запретить серверу 1С опрашивать сеть широковещательными запросами и жестко указать ему IP-адрес сервера лицензирования, на котором установлен самый большой ключ (в нашем примере — на 100 пользователей). Это делается с помощью настройки файла nethasp.ini.
C:\Program Files\1cv8\conf\ (или в папку конкретной версии, например, C:\Program Files\1cv8\8.3.X.X\bin\conf\).nethasp.ini в этой папке нет, скопируем его шаблон из папки установки платформы или создадим текстовый файл с этим именем.[NH_COMMON] и [NH_TCPIP] к следующему виду:
[NH_COMMON]
NH_TCPIP = Enabled
[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.100 ; Укажите здесь IP-адрес сервера, где установлен ключ на 100 пользователей
NH_PORT_NUMBER = 475
NH_USE_BROADCAST = Disabled
Параметр NH_USE_BROADCAST = Disabled отключает широковещательный поиск по сети. Теперь сервер 1С больше не будет устраивать "гонку ответов" и будет обращаться целенаправленно к указанному IP-адресу, где гарантированно находится нужный ключ.
Чтобы избежать блокирования лицензий "зависшими" сессиями веб-клиентов, настроим регулярный принудительный перезапуск службы менеджера лицензий HASP LM на серверах, где установлены физические ключи.
Для этого создадим простой командный файл (скрипт) с расширением .bat:
@echo off
net stop "HASP Loader"
timeout /t 5
net start "HASP Loader"
Затем с помощью Планировщика задач Windows (Task Scheduler) настроим запуск этого скрипта в нерабочее время (например, каждую ночь в 03:00). Это гарантирует, что каждый рабочий день пользователи веб-клиентов будут начинать с абсолютно чистым пулом свободных лицензий.
Нам необходимо убедиться, что базы данных не конфликтуют за лицензии. Проанализируем настройки всех баз в консоли администрирования кластера 1С:
Если инфраструктура компании продолжает масштабироваться, лучшим стратегическим решением станет постепенный отказ от нескольких аппаратных сетевых ключей одной серии в пользу программных лицензий (файлов .lic).
В отличие от аппаратных ключей HASP, программные лицензии 1С обладают огромным преимуществом:
475, блокировками брандмауэра и зависанием службы HASP Loader.Выполнив указанные шаги по настройке файла nethasp.ini и регламентному перезапуску служб, мы обеспечим отказоустойчивую и прогнозируемую работу веб-интерфейса 1С:Предприятия.