Не найден ключ защиты 1С: с чего начать, если ключ USB, сетевой или программный

Сообщение «не найден ключ защиты» почти никогда не значит, что ключ сломался. Сначала определите, откуда программа должна взять лицензию: из USB-ключа на этом компьютере, из сетевого ключа на сервере или из файла программной лицензии. Дальше проверка идёт по короткой цепочке, и ниже она разобрана по шагам с командами и разбором реального случая.

Что на самом деле означает «не найден ключ защиты» и как за минуту определить тип лицензии

Я занимаюсь поддержкой офисов до 50 рабочих мест больше пятнадцати лет, и это сообщение звонит мне чаще любого другого по 1С. Диагноз по нему не ставится, пока не выяснен один вопрос: где лежит лицензия. Если вы разбираетесь с нуля или готовите офис к переезду, подключайте настройку и сопровождение 1С сразу: половина таких вызовов возникает после того, как что-то «немного» поменяли в сети или на сервере.

Лицензия может прийти тремя путями. Первый: локальный аппаратный ключ, USB-брелок, воткнутый в тот компьютер, где запускается клиент или сервер 1С. Второй: сетевой аппаратный ключ, он стоит в одной машине, а менеджер лицензий раздаёт места по сети. Третий: программная лицензия, файл с расширением lic, привязанный к параметрам машины. Про программные лицензии, СЛК и привязку к оборудованию у нас есть отдельный материал: лицензирование 1С, программные ключи и СЛК. Здесь мы идём с другой стороны: что делать, когда пользователь уже видит ошибку и работа стоит.

Определить тип можно за минуту, не гадая. Спросите, на какой машине появилась ошибка: на сервере 1С или на клиентской. Спросите, у всех ли она или у части пользователей. Если ошибка у всех сразу и началась после перезагрузки или обновления сервера, виновата серверная сторона: служба, драйвер, файл лицензии. Если ошибка у одного человека, ищите на его компьютере: клиентский драйвер, настройки сети, файл nethasp.ini. Если у части людей и есть общее у этой группы, это почти всегда подсеть, VLAN или правило файрвола.

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

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

Локальный USB-ключ не виден: драйвер, служба и порт

Начинаем с самого простого, потому что оно же самое частое. Драйвер защиты нужен только там, где ключ воткнут физически. Документация платформы прямо говорит, что драйвер HASP Device Driver требуется для локального ключа и его надо ставить до того, как ключ вставлен в USB-порт. Если ключ сетевой, на клиентских машинах без своего брелка драйвер не нужен. Лишний драйвер там не помогает, а иногда мешает, особенно когда на сервере стоят две версии платформы.

Физическая проверка занимает полминуты. У брелка есть светодиод. По документации Thales, если он не горит, ключ нужно вынуть и вставить через несколько секунд, а если светится, приложение в принципе способно получить к нему доступ. Затем откройте диспетчер устройств и посмотрите, есть ли запись Sentinel. Если её нет, драйвер не установлен или установлен криво. Переткните ключ в другой порт, лучше на задней панели системного блока, а не в передний разъём через удлинитель, и отключите лишние USB-устройства.

Самая надёжная проверка видимости ключа в системе делается через панель Admin Control Center. Она ставится вместе с драйвером Sentinel и открывается в браузере по адресу http://localhost:1947. Перед этим должна работать служба менеджера лицензий: в Windows она отображается как Sentinel LDK License Manager, внутреннее имя hasplms. Если страница не открывается, документация называет две типичные причины: служба не запущена или испорчена конфигурация Winsock из-за стороннего сетевого софта. На странице Sentinel Keys вы увидите, определился ли ключ. Если определился, проблема уже не в железе. Одна оговорка, на которой путаются многие: hasplms и панель на 1947 — это уровень драйвера Sentinel, а сетевые лицензии 1С раздаёт отдельная программа HASP License Manager. О ней в следующем разделе.

Если ключ в панели не виден, переустанавливайте драйвер. Утилита haspdinst, которую Thales описывает в руководстве по установке Run-time Environment, принимает ключи -i для установки или обновления, -r для удаления и -info для вывода состояния установки. Запускайте от имени администратора и в каталоге, где лежит утилита из вашего дистрибутива (проверьте путь в своей версии платформы, я не рекомендую брать драйвер с произвольных сайтов):

# Состояние службы менеджера лицензий (Windows)
sc qc hasplms
Get-Service -Name hasplms

# Состояние установки Run-time Environment
.\haspdinst.exe -info

# Переустановка: сначала удалить, потом поставить
.\haspdinst.exe -r
.\haspdinst.exe -i

Мой порядок после удаления драйвера такой: ключ вынимаю из порта и вставляю обратно уже при установленном драйвере. Это согласуется с требованием документации 1С ставить драйвер до подключения ключа. На Linux логика та же, а демоны называются aksusbd и hasplmd. Состояние смотрите так:

sudo systemctl status aksusbd
sudo systemctl status hasplmd
systemctl list-units | grep -i hasp

Сетевой ключ: клиент не находит менеджер лицензий

Сетевой ключ сложнее, потому что отказать может любое звено: сама машина с ключом, служба, сеть между ней и клиентом, настройки клиента. Идите от ключа к клиенту. Сначала убедитесь на машине с ключом, что он виден (панель на порту 1947, как в предыдущем разделе) и что запущен именно менеджер лицензий для 1С. Для сетевого ключа платформы 8.3 это HASP License Manager из дистрибутива 1С; в списке служб Windows он обычно виден как HASP Loader, и слушает он порт 475. Наличие одного драйвера Sentinel без менеджера лицензий — частая причина, по которой локально ключ виден, а по сети нет. В новых версиях платформы (по материалам ИТС — начиная с 8.5.4) появился собственный «1С:Предприятие 8 – Менеджер лицензий» (процесс rmlic), который по умолчанию занимает порты 475 и 1544; если вы на такой версии, сверьтесь с инструкцией ИТС по переходу. Потом проверьте, что тот же ключ не занят: у сетевого ключа есть число одновременных подключений, и когда оно исчерпано, новые пользователи получают отказ.

Дальше клиент. Платформа 1С читает параметры обращения к менеджеру лицензий из файла nethasp.ini. При установке платформы пример файла копируется в каталог конфигурационных файлов, и документация оговаривает, что он почти целиком состоит из закомментированных строк и ничего сам не переопределяет. Типичная ошибка: все ждут, что клиент найдёт сервер сам. Он находит его широковещательным запросом, а широковещание не проходит через маршрутизатор. Поэтому в офисе с одним сегментом всё работает годами, а стоит выделить отдел в отдельный VLAN, часть людей остаётся без лицензии.

Минимальная настройка для такого случая берётся из руководства администратора. В разделе NH_TCPIP по документации 1С задаются адрес менеджера лицензий (NH_SERVER_ADDR), номер порта (NH_PORT_NUMBER, по умолчанию 475), способ обращения (NH_TCPIP_METHOD, по умолчанию UDP) и широковещание (NH_USE_BROADCAST, по умолчанию включено). Руководство прямо предупреждает: обращение к менеджеру лицензий всегда идёт по UDP, указание TCP в файле игнорируется. Пример из руководства приведён с адресом из документации, подставьте свой:

[NH_COMMON]
NH_TCPIP=Enabled

[NH_TCPIP]
NH_SERVER_ADDR=192.0.2.12
NH_PORT_NUMBER=475
NH_TCPIP_METHOD=UDP
NH_USE_BROADCAST=Disabled

Теперь о том, куда класть файл. Если платформа установлена и 32-битная, и 64-битная, у каждой свой каталог conf, и править надо тот, из которого запускается нужный клиент. На Linux это каталог conf внутри каталога установленной версии (в актуальных релизах вида /opt/1cv8/x86_64/<версия>/conf) и пользовательский ~/.1cv8/1C/1cv8/conf. На десятках рабочих мест вручную это делать нельзя: раскладывайте файл групповой политикой или скриптом входа, иначе через полгода никто не вспомнит, где он лежит. Если у вас домен и вы раздаёте настройки через GPO, это тоже часть нашей работы по аудиту Active Directory и групповых политик.

Про файрвол. Клиенты 1С с сетевым ключом обращаются к HASP License Manager по UDP на порт 475 (если в nethasp.ini не задан другой NH_PORT_NUMBER), поэтому на машине с ключом в первую очередь нужно разрешить именно его. Порт 1947 (TCP) — это панель и менеджер Sentinel LDK; для раздачи лицензий 1С клиентам он не нужен, и открывать его на всю сеть я не советую. На платформах с новым менеджером лицензий rmlic по документации ИТС добавляется порт 1544. Не открывайте всё подряд: посмотрите, что реально слушает машина с ключом (netstat -ano на Windows, ss -lunp на Linux), и разрешите это только для адресов клиентов. Не публикуйте порт менеджера лицензий в интернет ни при каких обстоятельствах.

Терминальный сервер и виртуальная машина: куда пропадает ключ

Два сценария я разбираю чаще остальных. Первый: 1С запущена на терминальном сервере, а USB-ключ воткнут в компьютер сотрудника. Ключ по RDP в терминальную сессию, как правило, не пробрасывается так, как нужно приложению, и сообщение «не найден ключ защиты» выскакивает только в сессии, а на самом компьютере всё хорошо. Нормальное решение одно: ключ живёт на сервере или на выделенной машине как сетевой, а клиенты в сессиях обращаются к менеджеру лицензий по сети. Подробнее про терминальный доступ к 1С у нас есть в статье про тонкий клиент и терминальный сервер.

Второй сценарий: сервер 1С переехал в виртуальную машину. Физический ключ в гипервизор приходится пробрасывать: либо USB-проброс, либо отдельное устройство, которое отдаёт ключ по сети. Проброс отваливается при живой миграции между хостами и после перезагрузки гостя, причём без видимых причин. Я такие конструкции стараюсь не плодить. Если у клиента осталась аппаратная лицензия и виртуализация, мы обычно переводим его на сетевой ключ на отдельном небольшом устройстве либо на программные лицензии, предварительно проверив, что нет ограничений на количество активаций.

С программными лицензиями в виртуальной среде своя ловушка. Лицензия привязывается к параметрам машины, и после клонирования ВМ, смены типа сетевого адаптера или переноса на другой хост её файл становится недействительным, а ошибка снова выглядит как «ключ не найден». Поэтому перед любой миграцией сервера заранее сохраните файлы лицензий и пин-коды и убедитесь, что оставшиеся попытки активации есть. Это же правило важно для запасного сервера, о котором подробно в материале про холодный резерв сервера 1С.

Программная лицензия: где лежит файл и почему сервер его не видит

Если в организации стоят программные лицензии, физического ключа нет вообще, а проблема та же. Файлы лицензий платформа ищет в нескольких каталогах по порядку. По руководству администратора для Windows это каталог conf самой платформы, пользовательский профиль, общие каталоги в ProgramData, в частности %ProgramData%\1C\licenses, и каталог из параметра ConfLocation файла conf.cfg. Для Linux перечень включает conf версии, /opt/1cv8/conf, домашний каталог пользователя и /var/1C/licenses. Порядок и список немного меняются от релиза к релизу, поэтому сверьтесь с руководством именно вашей версии.

Главное, что я проверяю в такой ситуации: от какой учётной записи запущена служба сервера 1С, и есть ли у неё права на чтение каталога с лицензией. Руководство отмечает, что при активации серверной лицензии из конфигуратора на другой машине файл сохраняется в профиле учётной записи, под которой работает служба сервера (на Linux это по умолчанию usr1cv8). Поменяли пользователя службы, и лицензия «пропала». Файл на месте, но сервер его не видит. На Linux первым делом смотрите владельца и права на каталог:

ls -la /var/1C/licenses
ps -o user= -C ragent
sudo -u usr1cv8 ls /var/1C/licenses

Теперь предупреждение, на котором люди теряют лицензии. Руководство прямо запрещает хранить один файл программной лицензии сразу в нескольких каталогах, доступных платформе: это может привести к тому, что файл станет непригодным из-за нарушения лицензионного соглашения. Поэтому «положу копию на всякий случай рядом» — плохая идея. Резервную копию держите вне каталогов поиска платформы, например в архиве с учётной документацией, и при повторном получении лицензии убирайте старый файл из всех мест поиска.

Смотрите и вторую сторону вопроса: сервер лицензий, если он у вас выделен. Если клиенты не получают лицензии, а на самом сервере всё нормально, проверьте цепочку «клиент → кластер → сервер лицензий», а не только ключ. Чаще всего причина оказывается в том, что неактивные сеансы держат лицензии и свободных не осталось. Тогда сообщение другое, но пользователи формулируют его так же («1С не пускает»), поэтому до начала диагностики стоит свериться с текстом ошибки и с логом сервера.

Разбор из практики: 11 пользователей из 28 остались без лицензии после переезда

Условный клиент, организационный консалтинг «ПроцессКонсалт»: 28 рабочих мест, 1С на клиент-серверном варианте, платформа 8.3.22, сетевой аппаратный ключ в маленьком выделенном компьютере в серверной. В понедельник утром у отдела продаж (11 человек) 1С не запускалась с сообщением о том, что ключ защиты не найден. Остальные 17 сотрудников работали. Звонок поступил в 9:10.

Первым делом я отсёк сторону ключа: открыл панель на порту 1947 на машине с ключом, ключ был виден, служба HASP Loader работала, а с машины из «рабочей» подсети запрос на UDP 475 проходил. Значит, ключ жив, и отказывает путь до него. Общее у проблемных пользователей: отдел продаж за выходные перенесли в отдельную подсеть, чтобы выделить гостевой Wi-Fi и принтеры. Широковещательный запрос клиента до менеджера лицензий больше не доходил, в nethasp.ini на этих машинах адрес сервера не был указан. Диагноз занял около 25 минут, и я не пользовался ничем, кроме панели на сервере и просмотра подсетей на коммутаторе.

Исправление: я выложил единый nethasp.ini с адресом менеджера лицензий и отключённым широковещанием (как в примере выше) через групповую политику, а на файрволе машины с ключом разрешил UDP 475 только для двух подсетей клиентов. Через час после звонка отдел работал. Простой составил около 55 минут, потеряно примерно 11 × 0,9 часа рабочего времени. Итог для клиента: файл лежит в политике, схема подсетей и порт записаны в паспорте инфраструктуры, а любой новый сегмент проверяется на доступ к менеджеру лицензий до переезда.

Почему я рассказываю именно эту историю. Потому что ровно в такие моменты мне звонят с фразой «ключ сломался». Ключ ни разу не сломался. Тремя шагами (виден ли ключ на своей машине, одинакова ли ошибка у всех, что общего у пострадавших) диагностика сужается за полчаса. Остальное — уже настройка, а не поиск.

Порядок проверки и профилактика: чтобы ключ не терялся в понедельник утром

Соберу всё в короткий порядок действий, по которому мы работаем. Шаг первый: текст ошибки и место его появления. Шаг второй: тип лицензии (USB, сетевой ключ, файл). Шаг третий: виден ли ключ на своей машине, через панель Sentinel на порту 1947 и состояние службы. Шаг четвёртый: путь до ключа, то есть nethasp.ini, подсеть, файрвол. Шаг пятый: для программных лицензий каталоги, права и учётная запись службы. Шаг шестой: только после этого переустановка драйвера и обращение к поставщику лицензий.

Профилактика скучная, но работает. Держите в учёте тип и расположение каждого ключа и копии пин-кодов. Держите актуальную схему подсетей и правила файрвола, которые касаются менеджера лицензий. Раскладывайте nethasp.ini политикой, а не руками. Обновляйте драйвер защиты осознанно: если вы переходите на новую ветку платформы, сверяйтесь с примечаниями к релизу, потому что в них иногда рекомендуют удалить старый драйвер и поставить поставляемый вместе с платформой. Сами не меняйте оборудование сервера, не сохранив лицензии. И не сводите диагностику лицензий к «переткни ключ»: это помогает в одном случае из пяти.

Если сомневаетесь, что вы справитесь без простоя, сначала скажу, на что можно не тратить время. Не нужно переустанавливать платформу целиком, не нужно ставить сторонние «универсальные» драйверы и не стоит искать «кряки» и обходы защиты: это нарушение лицензии и прямой риск для данных. Если проблема не решается по порядку выше, в вашем случае, скорее всего, нужна проверка лицензий с участием поставщика ключа. Помощь с лицензиями 1С входит в нашу IT-поддержку компаний, и мы чаще всего находим причину за один выезд или одну удалённую сессию.

Частые вопросы