Не обнаружен сетевой ключ защиты 1С на Windows 10: устраняем ошибку Warning=142

← На главную

Перевод пользователей на новые операционные системы часто сопровождается неожиданными сбоями в работе защитных механизмов 1С:Предприятия. Типичная ситуация: после замены старого компьютера с Windows 7/8 на современную рабочую станцию под управлением Windows 10 пользователи сталкиваются с тем, что клиент-серверные базы запускаются без проблем, а при попытке открыть локальную файловую базу система выдает критическую ошибку:

«Не найден файл программной лицензии. Не обнаружен ключ защиты программы или полученная программная лицензия!»

При этом в детальном системном отчете (логе поиска лицензий) фигурируют следующие строки:

nethasp.ini: C:/Program Files (x86)/1cv8/conf/nethasp.ini, прочитан успешно, ошибка соединения с менеджером лицензий: Net Status=0, System Error=0, Warning=142, ORGL8 Сетевой, не установлен

Давайте подробно разберем, почему возникает эта проблема, проанализируем разницу в поведении платформ и пошагово восстановим доступ к базам данных.

Почему SQL-базы запускаются, а файловые выдают ошибку?

Для начала выясним причину такого избирательного поведения платформы. Разница кроется в механизме раздачи лицензий:

Клиент-серверный вариант (SQL): В настройках информационной базы по умолчанию активна опция «Разрешить выдачу лицензий сервером 1С:Предприятия». При подключении пользователя к серверной базе сам сервер (служба ragent.exe) обращается к физическому USB-ключу, установленному непосредственно в его разъем, забирает свободную лицензию и передает ее сеансу клиента. Клиентскому компьютеру при этом не нужно напрямую видеть сетевой ключ.
Файловый вариант: При запуске локальной или сетевой файловой базы (с расширением .1CD) сервер 1С отсутствует. Вся нагрузка ложится на локальное клиентское приложение 1cv8.exe. Именно оно обязано самостоятельно найти лицензию в локальной сети, обратившись к службе HASP License Manager (HASP LM), запущенной на сервере, где физически установлен многопользовательский ключ.

Код ошибки Warning=142 в протоколе 1С означает таймаут сетевого запроса (Connection Timeout). Это указывает на то, что файл конфигурации nethasp.ini на клиенте прочитан успешно, правила поиска заданы, но ответа от сервера с ключом за отведенное время клиентское приложение так и не получило.

---

Шаг 1. Локализуем роль HASP License Manager

Распространенная ошибка начинающих администраторов — попытка установить службу HASP LM (HASP Loader) на новый клиентский компьютер с Windows 10. Рассмотрим, почему этого делать не нужно:

Служба HASP License Manager должна работать исключительно на том компьютере (или сервере), в который физически вставлен сетевой многопользовательский ключ защиты (красный USB-ключ на 5, 10, 20, 50 или более рабочих мест).
На клиентском компьютере под управлением Windows 10 устанавливать HASP LM не требуется. Здесь необходим только стандартный драйвер защиты HASP (Hasp Device Driver), который устанавливается по умолчанию вместе с платформой 1С.

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

---

Шаг 2. Проверяем доступность сетевого порта 475

Работа сетевых ключей HASP базируется на отправке сетевых пакетов по порту 475. Обмен данными может идти как по протоколу UDP (по умолчанию для широковещательного поиска), так и по протоколу TCP (при явном указании IP-адреса сервера). Если обычный сетевой пинг (ping [IP_сервера]) проходит успешно, это еще не означает, что порт 475 открыт.

Проанализируем доступность порта с помощью встроенного сетевого инструментария Windows. Для этого активируем компонент Telnet. Зайдем в «Панель управления» -> «Программы и компоненты» -> «Включение или отключение компонентов Windows» и установим галочку напротив «Клиент Telnet».

После установки откроем командную строку (cmd) на клиентской машине с Windows 10 и выполним команду:

telnet 192.168.0.100 475

(Где 192.168.0.100 — фактический IP-адрес вашего сервера с ключом).

Если экран очистился или появился мигающий курсор — порт открыт, соединение успешно установлено. Если же вы увидели сообщение «Сбой подключения» или «Не удалось открыть подключение к этому узлу», значит, сетевой трафик по порту 475 заблокирован брандмауэром или маршрутизатором.

Для современных систем Windows 10 более предпочтительно использовать утилиту PowerShell для проверки сетевого сокета:

Test-NetConnection -ComputerName 192.168.0.100 -Port 475

Если в результатах выполнения команды строка TcpTestSucceeded принимает значение False, порт заблокирован.

---

Шаг 3. Настройка сетевого профиля и брандмауэра в Windows 10

Одной из главных причин блокировки порта 475 на новых компьютерах с Windows 10 является неверно определенный сетевой профиль.

При первом подключении к локальной сети Windows 10 часто определяет тип подключения как «Общедоступная сеть» (Public Network). В этом режиме встроенный брандмауэр Windows (Windows Defender Firewall) работает по максимально жестким правилам безопасности и полностью блокирует входящий и исходящий трафик по нестандартным портам, включая HASP (UDP/TCP 475).

Выполним следующие действия для исправления ситуации:

Переведем сетевой профиль в состояние «Частная сеть» (Private Network). Для этого зайдем в «Параметры» -> «Сеть и Интернет» -> «Свойства» вашего активного сетевого подключения и переключим тумблер на «Частные».
Откроем «Монитор брандмауэра защитника Windows в режиме повышенной безопасности» (команда wf.msc в строке Выполнить).
В левом меню выберем «Правила для входящих подключений» и создадим новое правило для порта:
- Тип правила: Для порта.
- Протоколы и порты: Протокол TCP, в поле «Определенные локальные порты» укажем 475.
- Действие: Разрешить подключение.
- Профили: Отметим галочками «Доменный» и «Частный».
Аналогичным образом создадим еще одно входящее правило для протокола UDP по порту 475.
Повторим процедуру создания аналогичных правил в разделе «Правила для исходящих подключений».

---

Шаг 4. Тонкая настройка конфигурационного файла nethasp.ini

Широковещательный поиск ключа в сети (Broadcast) часто блокируется интеллектуальным сетевым оборудованием или не работает, если клиентский компьютер находится в другом сегменте сети (подсети) относительно сервера. Чтобы гарантировать доставку пакетов до менеджера лицензий, настроим файл nethasp.ini на принудительную работу по протоколу TCP с указанием точного IP-адреса сервера.

Рассмотрим, где физически находится конфигурационный файл. В зависимости от разрядности установленной платформы 1С на Windows 10, пути могут различаться:

Для 32-битного клиента: C:\Program Files (x86)\1cv8\conf\nethasp.ini
Для 64-битного клиента: C:\Program Files\1cv8\conf\nethasp.ini

Откроем файл nethasp.ini с помощью текстового редактора (например, Блокнот) от имени Администратора. Полностью очистим его содержимое и запишем оптимизированные параметры:


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

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

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

NH_TCPIP = Enabled — активирует использование сетевого протокола TCP/IP для связи с ключом.
NH_IPX = Disabled и NH_NETBIOS = Disabled — отключают устаревшие протоколы IPX и NetBIOS, существенно ускоряя время инициализации защиты при запуске программы.
NH_SERVER_ADDR = 192.168.0.100 — жестко задает целевой IP-адрес сервера, где установлен HASP-ключ. Замените этот адрес на фактический IP вашего сервера.
NH_TCPIP_METHOD = TCP — принудительно переводит обмен данными с ненадежного протокола UDP на гарантированный протокол TCP. Это позволяет обойти ограничения на потерю пакетов и решить проблему Warning=142.
NH_USE_BROADCAST = Disabled — полностью отключает фоновый широковещательный опрос локальной сети, предотвращая зависание платформы при старте.

После сохранения изменений обязательно перезапустите приложение 1С:Предприятие и проверьте запуск файловой базы.

---

Шаг 5. Конфликт адресации IPv6 в Windows 10

Еще один скрытый нюанс работы современных сборок Windows 10 — включенный по умолчанию протокол IPv6, имеющий более высокий приоритет маршрутизации, чем классический IPv4. Старые версии HASP License Manager (особенно установленные на Windows Server 2008) не умеют обрабатывать запросы по протоколу IPv6.

Если в файле nethasp.ini вместо явного IP-адреса указано имя сервера (например, NH_SERVER_ADDR = srv-1c), Windows 10 попытается разрешить имя узла через DNS и в первую очередь получит IPv6-адрес сервера. Запрос уйдет по этому адресу, менеджер лицензий его проигнорирует, и мы снова получим ошибку таймаута.

Решение: Всегда прописывайте в nethasp.ini статический IP-адрес сервера в формате IPv4 (например, 192.168.x.x). Также рекомендуется временно отключить протокол IPv6 в свойствах сетевого адаптера на клиентском компьютере в меню сетевых подключений Windows 10.

---

Шаг 6. Настройка менеджера лицензий на стороне сервера (nhsrv.ini)

Если проделанные на стороне клиента манипуляции не привели к успеху, проанализируем настройки службы HASP LM непосредственно на Windows Server 2008. Настройки службы хранятся в конфигурационном файле nhsrv.ini, который обычно находится в папке установки утилиты (по умолчанию C:\Program Files (x86)\Aladdin\HASP LM\).

Обратим внимание на следующие критические параметры в файле nhsrv.ini на сервере:

Наличие ограничений по IP-адресам (IP limits): Проверьте параметр NHS_IP_LIMIT в секции [NHS_IP]. Если там прописаны конкретные диапазоны адресов, а новый компьютер с Windows 10 получил от DHCP-сервера новый IP-адрес, не входящий в разрешенный список, сервер будет молча сбрасывать входящие пакеты от этого клиента. По возможности временно закомментируйте эту строку символом точки с запятой (;).
Проблема нескольких сетевых интерфейсов (Multi-homed Server): Если на сервере установлено две сетевые карты (одна смотрит в локальную сеть, другая — во внешнюю) или настроены виртуальные коммутаторы Hyper-V/VMware, служба HASP LM могла привязаться к неактивному или внешнему интерфейсу. Для решения этой проблемы в файле nhsrv.ini найдите параметр NHS_USER_IP и явно пропишите локальный IP-адрес сервера, который слушает запросы клиентов:
```
[NHS_IP]
NHS_USER_IP = 192.168.0.100
```

После изменения параметров конфигурации на сервере не забудьте перезапустить службу HASP Loader через консоль services.msc.

---

Шаг 7. Совместимость драйверов защиты с изоляцией ядра Windows 10

В современных обновлениях Windows 10 (версии 20H2 и новее) по умолчанию активна функция безопасности «Целостность памяти» (Memory Integrity), базирующаяся на технологии изоляции ядра (Core Isolation). Эта функция блокирует загрузку драйверов, содержащих известные уязвимости.

Устаревшие драйверы HASP, которые поставляются в комплекте со старыми релизами платформы 1С (включая 8.3.13), распознаются операционной системой как небезопасные и блокируются на системном уровне при старте ОС. При этом физический ключ на клиенте может светиться, но драйвер фактически не функционирует.

Для решения этой проблемы выполним полное обновление драйвера защиты на клиентской машине:

Скачайте актуальную версию драйвера Sentinel LDK Run-time Command Line Installation с официального сайта разработчика защиты (Thales Group, ранее Gemalto/Aladdin).
Распакуйте архив, откройте командную строку от имени Администратора, перейдите в папку с утилитой и выполните команду полной очистки старых драйверов: haspdinst.exe -purge
Дождитесь сообщения об успешном удалении компонентов, перезагрузите клиентский компьютер.
Установите обновленный драйвер, запустив команду: haspdinst.exe -i

Этот шаг полностью исключит конфликты на уровне ядра Windows 10 и гарантирует стабильное сопряжение сетевой библиотеки защиты платформы с аппаратным ключом.