← На главную

Мы сталкиваемся с необычной ситуацией: клиент использует МИНИ-сервер 1С на 5 подключений, однако в консоли администрирования сервера мы видим 8 или более открытых сеансов пользователей. Это вызывает закономерный вопрос: как такое возможно при строгих ограничениях МИНИ-сервера?

Согласно лицензионной политике, "1С:Предприятие 8.3 Сервер МИНИ на 5 подключений" является фактически сервером уровня ПРОФ, но с жестким ограничением на 5 одновременных сеансов пользователей в режиме "1С:Предприятие" и один сеанс в режиме "Конфигуратор". То есть, общее количество активных подключений не должно превышать шести. Увеличение этого количества невозможно путем простого добавления клиентских лицензий; для этого требуется апгрейд на другую серверную лицензию, например, ПРОФ или КОРП. МИНИ-сервер 1С поставляется с программной защитой, что означает отсутствие аппаратных USB-ключей для его работы.

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

Возможные причины превышения количества сеансов

Рассмотрим основные версии и причины, по которым мы можем наблюдать такое поведение.

1. Использование модифицированной (патченной) платформы 1С

Это одна из наиболее распространенных причин такого рода аномалий. Существуют модифицированные сборки платформы 1С или отдельные измененные DLL-файлы, которые позволяют серверу 1С работать без полноценной проверки лицензионных ограничений на количество сеансов. Даже если сервер все еще требует наличия файла лицензии для старта, он может игнорировать заложенные в него ограничения.

1. Модифицированные файлы платформы: В частности, часто подвергаются изменениям такие файлы, как techsys.dll, backbas.dll, backend.dll, расположенные в каталоге bin установленной платформы. Изменение контрольных сумм (MD5 хешей) этих файлов, несоответствие их даты и времени дате установки платформы, или наличие рядом файлов с похожим названием (например, techsys_[число].dll) может быть явным признаком взлома.
2. Особенности операционной системы: Учитывая, что сервер установлен на Windows 7 64-bit, это вполне благоприятная среда для установки и функционирования подобных модификаций, которые могут быть распространены в интернете.
3. Парадокс с файлом лицензии: Тот факт, что сервер перестает работать при удалении файла лицензии, может казаться противоречивым. Однако это объясняется тем, что модифицированная платформа может быть настроена так, чтобы не требовать действительной серверной лицензии, но все же проверять наличие любого файла лицензии (например, клиентской) для старта, игнорируя при этом количество разрешенных сеансов.

2. Некорректная установка или использование лицензий

Другой вероятной причиной может быть некорректная настройка системы лицензирования или установка полного сервера вместо МИНИ.

1. Установка полноценного сервера 1С вместо МИНИ: Клиент мог приобрести лицензию на МИНИ-сервер, но по ошибке или умыслу был установлен полноценный сервер 1С (ПРОФ или КОРП). Если этот полноценный сервер был модифицирован (взломан) для работы без серверного ключа, или же он использует клиентские лицензии для авторизации, это могло бы объяснить ситуацию.
2. Отображение лицензий в "О программе": Это критически важный диагностический шаг. В нормальной ситуации для МИНИ-сервера в разделе "О программе" должно быть указано легкий сервер 1/6. Если же мы видим строки типа Локальный HASP4 ORGL8 10, получило клиентское приложение или другие многочисленные упоминания HASP4-лицензий, это указывает на то, что сервер 1С либо не является МИНИ-сервером, либо некорректно использует клиентские лицензии для своей работы. Сервер 1С может произвольно выбрать один из нескольких обнаруженных многопользовательских клиентских ключей серии ORGL8.
3. HASP License Manager (HASP LM): Если в системе установлены аппаратные HASP-ключи, HASP LM может раздавать клиентские лицензии. Взломанный сервер может "видеть" эти клиентские лицензии и использовать их для авторизации сеансов, при этом игнорируя ограничения на количество подключений, которые должны быть наложены серверной лицензией.

3. Использование эмуляторов HASP-ключа

Хотя МИНИ-сервер использует программную защиту, наличие эмуляторов аппаратных HASP-ключей в системе все равно может влиять на работу сервера 1С и обходить другие лицензионные проверки, даже если администратор утверждает их отсутствие.

Эмуляторы могут маскировать использование нелицензионного ПО или создавать конфликт с реальными лицензиями.

4. Фоновые задания

Важно исключить возможность того, что часть сеансов являются фоновыми заданиями. Однако автор темы подтверждает, что это именно активные сеансы пользователей, а не фоновые задачи.

Методы диагностики и проверки

Чтобы точно определить причину аномального поведения, мы рекомендуем выполнить следующие шаги:

1. Тщательная проверка информации о лицензиях в "О программе"

Мы должны получить точные данные из раздела "О программе" любого клиентского приложения, подключенного к этому серверу. Особое внимание уделим блоку "Текущая" и "Информационная база".

1. "Текущая" лицензия: В этой строке должно быть четко указано легкий сервер 1/6, если это действительно МИНИ-сервер. Если вы видите что-то вроде Локальный HASP4 ORGL8 10, получило клиентское приложение или другие упоминания HASP-ключей, это указывает на то, что клиентское приложение получает лицензию напрямую от HASP LM или от другого источника, а не от МИНИ-сервера.
2. "Информационная база" лицензии: Проанализируем все перечисленные лицензии. Если там присутствуют многочисленные HASP4 лицензии (например, Сетевой HASP4 ORGL8 20, Локальный HASP4 ORGL8 5 и т.д.), это может свидетельствовать о наличии физических или эмулированных ключей, которые система 1С использует для авторизации.
3. Регистрационный номер: Запишем регистрационный номер, указанный в лицензии. Он может помочь в идентификации типа лицензии.

2. Анализ файлов платформы 1С

Мы проверим целостность и оригинальность ключевых файлов платформы 1С на сервере.

1. Проверка techsys.dll:
   • Найдем файл techsys.dll в каталоге bin установленной платформы 1С на сервере (например, C:\Program Files\1cv8\8.3.Х.ХХХХ\bin\techsys.dll).
   • Сравним дату и время изменения этого файла с датой и временем установки платформы. Значительное расхождение является сильным индикатором того, что файл был модифицирован.
   • Проверим наличие в том же каталоге файлов, имена которых начинаются на techsys_ (например, techsys_old.dll, techsys_backup.dll, techsys_патч.dll). Наличие таких файлов – почти однозначный признак взлома.
2. Проверка backbas.dll и backend.dll: Эти файлы также часто подвергаются модификациям. Для полной уверенности мы можем вычислить MD5 хеши этих файлов и сравнить их с эталонными хешами для официальной, немодифицированной платформы 1С соответствующей версии.
3. Использование официального дистрибутива: В идеале, мы должны всегда устанавливать платформу только из проверенных, официальных источников (например, с портала ИТС).

3. Поиск эмуляторов HASP-ключа

Мы должны убедиться в отсутствии сторонних программных решений, которые могут имитировать наличие аппаратных ключей.

1. Диспетчер устройств: Откроем Диспетчер устройств Windows и проверим наличие устройств типа "HASP" или "Sentinel" в разделах "Системные устройства" или "Контроллеры универсальной последовательной шины USB" при отсутствии физически подключенных аппаратных ключей.
2. Реестр Windows: Проверим ветки реестра, которые могут быть связаны с эмуляторами (например, поиском по ключевым словам Emulator, Emu, haspflt, multikey).
3. Системные файлы: Проверим наличие файлов haspflt.sys, vusbbus.sys, VUsb.sys в системных папках (например, C:\Windows\System32\drivers). Их наличие при отсутствии аппаратных ключей может указывать на установку эмулятора.

4. Проверка максимального количества сеансов

Мы можем попытаться открыть максимально возможное количество сеансов (например, 15 или 20) для подтверждения отсутствия лимита. Если сервер позволяет запускать значительно больше сеансов, чем официально разрешено для МИНИ-сервера, это явное подтверждение проблемы.

5. Проверка версии платформы и обновление

Мы должны обратить внимание на текущую версию платформы (8.3.18.1520) и заявления администратора о попытках установки более свежих версий (например, 8.3.20). Если после установки официальной, свежей версии платформы проблема сохраняется, это может указывать на более глубокий взлом или проблему с операционной системой.

Важный момент: Мы можем использовать процесс обновления как способ диагностики. Берем официальный дистрибутив последней стабильной версии платформы с портала ИТС и пытаемся установить его на сервер. Если платформа была модифицирована, официальное обновление может либо не установиться, либо привести к сбоям в работе сервера. Это также предоставляет весомое обоснование для клиента: "Ваша текущая конфигурация требует обновления платформы, и мы не можем ее установить из-за проблем с текущей инсталляцией 1С."

6. Ограничения кластера серверов 1С

Напомним, что для МИНИ-сервера в кластере может быть не более одного рабочего сервера. Убедимся, что это условие соблюдается.

Рекомендации по решению проблемы

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

1. Полная переустановка операционной системы и платформы 1С "с нуля":

   Это самый радикальный, но и самый надежный способ исключить наличие любых модификаций, эмуляторов или скрытых проблем с лицензированием. Мы рекомендуем:

   1. Сделать резервную копию всех информационных баз.
   2. Полностью переустановить операционную систему на чистый диск.
   3. Установить сервер 1С:Предприятие только из официальных дистрибутивов, полученных с портала ИТС или от надежного партнера 1С.
   4. Активировать лицензию МИНИ-сервера в соответствии с официальной документацией.
   5. Восстановить информационные базы.
2. Приобретение необходимых лицензий:

   Если фактическое количество пользователей клиента постоянно превышает или планирует превышать 5, необходимо приобрести соответствующую серверную лицензию (ПРОФ или КОРП) и достаточное количество клиентских лицензий. Использование нелицензионного ПО влечет за собой юридические риски.

3. Аудит лицензий:

   Проведем полный аудит легальности всего используемого ПО 1С на стороне клиента, включая клиентские лицензии, файлы лицензий и параметры сервера, чтобы предотвратить подобные ситуации в будущем.

4. Понимание работы лицензий:

   Убедимся, что клиент понимает разницу между клиентскими и серверными лицензиями, а также ограничения МИНИ-сервера. Напомним, что 32-разрядные серверные лицензии работают только с 32-разрядными серверами, тогда как 64-разрядные универсальны. Клиентские лицензии одинаково подходят для 32- и 64-разрядных клиентов.

Помните, что использование нелицензионного программного обеспечения, даже по незнанию, может привести к серьезным юридическим последствиям и угрозам безопасности данных. Ваша задача — обеспечить легальную и стабильную работу системы 1С для клиента.