Почему 1С не видит лицензионный ключ при включенном Radmin VPN и как это исправить?

Многие системные администраторы и специалисты 1С сталкиваются с неприятной ситуацией: после очередного обновления программы Radmin VPN (или при ее первичном запуске) пользователи внезапно теряют связь с базой данных, получая критическое сообщение "Лицензия не обнаружена". При этом физический USB-ключ (HASP) исправно горит на сервере, служба лицензирования запущена, а в локальной сети до этого момента всё работало без нареканий.

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

Выясняем причину конфликта: почему Radmin VPN «ломает» видимость HASP-ключей

Для того чтобы выбрать правильный метод лечения, давайте разберем физику процесса. Проблема кроется во взаимодействии службы Sentinel HASP License Manager, платформы 1С и сетевой подсистемы операционной системы Windows. Когда на компьютере активируется Radmin VPN, происходят следующие изменения:

1. Конфликт нескольких сетевых интерфейсов (Multi-homed Server): Виртуальная сеть создает собственный сетевой адаптер с выделенным IP-адресом. Менеджер лицензий HASP, особенно устаревших версий, при перезапуске или инициализации может ошибочно начать «слушать» только этот новый виртуальный интерфейс, полностью игнорируя запросы, приходящие из реальной физической локальной сети.
2. Проблема приоритета сетевых адаптеров (Метрика): Операционная система Windows распределяет приоритеты между сетями с помощью метрик. Виртуальный адаптер Radmin VPN очень часто получает неоправданно высокий приоритет (низкую метрику). В результате платформа 1С при запуске пытается искать ключ защиты именно через виртуальный туннель VPN, где менеджера лицензий нет, и, не получая ответа, выдает ошибку.
3. Блокировка широковещательных UDP-пакетов: По умолчанию поиск сетевого ключа HASP платформой 1С происходит методом широковещательного запроса (broadcast) по протоколу UDP. Виртуальные адаптеры VPN-сетей, как правило, не умеют корректно транслировать или целенаправленно блокируют подобные пакеты в целях безопасности, из-за чего связь клиента с сервером лицензирования обрывается.

Давайте рассмотрим детальные практические варианты решения этой проблемы — от простых к более глубоким системным настройкам.

Решение 1: Тонкая настройка файла nethasp.ini (Рекомендуемый способ)

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

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

Рассмотрим этот процесс по шагам:

1. Найдите файл nethasp.ini. Обычно он располагается в каталоге установленной платформы 1С. Путь по умолчанию для 64-битных систем: C:\Program Files\1cv8\conf\ или для более старых 32-битных версий: C:\Program Files (x86)\1cv8\conf\. Если вы используете запуск конкретных версий, файл может находиться внутри папки с номером релиза (например, C:\Program Files\1cv8\8.3.23.1688\bin\conf\).
2. Откройте файл nethasp.ini с помощью любого текстового редактора (например, Блокнота) от имени Администратора.
3. Найдите секцию [NH_TCPIP] и приведите ее к следующему виду, раскомментировав (убрав знак сеcomponent-а или точки с запятой ; в начале строк) и изменив ключевые параметры:

[NH_TCPIP]
NH_TCPIP = Enabled
NH_SERVER_ADDR = 192.168.1.100 ; Укажите здесь реальный локальный IP-адрес вашего сервера с HASP-ключом
NH_PORT_NUMBER = 475
NH_TCPIP_METHOD = TCP
NH_USE_BROADCAST = Disabled

Давайте проанализируем, что дают эти настройки:

• NH_SERVER_ADDR — жестко указывает платформе IP-адрес сервера, на котором физически установлен USB-ключ и запущен менеджер лицензий. 1С больше не будет опрашивать все адаптеры подряд.
• NH_TCPIP_METHOD = TCP — переводит сетевой обмен между платформой и HASP LM с нестабильного в условиях VPN-сетей протокола UDP на гарантированный протокол TCP.
• NH_USE_BROADCAST = Disabled — полностью запрещает широковещательный поиск ключа. Это исключает задержки при запуске 1С и предотвращает отправку "мусорных" пакетов в виртуальный адаптер Radmin VPN.

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

Решение 2: Корректировка метрики сетевого интерфейса в Windows

Если по каким-то причинам вы не хотите настраивать файл nethasp.ini на каждом клиентском компьютере, можно решить проблему на уровне приоритетов операционной системы Windows. Нам нужно принудительно заставить Windows считать физическую локальную сеть более приоритетной, чем виртуальный канал Radmin VPN.

Для этого выполните следующие действия:

1. Нажмите комбинацию клавиш Win + R на клавиатуре, введите команду ncpa.cpl и нажмите Enter. Откроется окно "Сетевые подключения".
2. Найдите сетевой адаптер, созданный программой Radmin VPN. Нажмите на него правой кнопкой мыши и выберите пункт "Свойства".
3. В списке компонентов найдите строку "IP версии 4 (TCP/IPv4)", выделите ее и нажмите кнопку "Свойства" под списком.
4. В открывшемся окне нажмите кнопку "Дополнительно..." (она находится в самом низу).
5. Вкладка "Параметры IP", раздел "Метрика интерфейса". Снимите галочку с пункта "Автоматическое назначение метрики".
6. В поле "Метрика интерфейса" введите число 100 (чем выше число метрики, тем ниже приоритет данного подключения для операционной системы).
7. Нажмите ОК во всех окнах для сохранения настроек.

Для закрепления результата рекомендуется проделать аналогичную операцию для вашего физического адаптера локальной сети, но назначить ему приоритетную метрику — например, значение 10. Таким образом, ОС Windows и платформа 1С будут всегда в первую очередь отправлять запросы в физическую локальную сеть, где находится HASP-ключ, и только при отсутствии связи переключаться на виртуальные интерфейсы.

Решение 3: Проверка и настройка сетевых портов брандмауэра

Виртуальные сетевые адаптеры часто накладывают дополнительные ограничения безопасности на входящий и исходящий трафик. Даже если вы настроили nethasp.ini, брандмауэр Windows (Firewall) на сервере или клиенте может блокировать пакеты лицензирования, проходящие через интерфейс Radmin VPN.

Для корректного обмена информацией с HASP-ключом необходимо убедиться, что в брандмауэре открыты следующие порты:

• Порт 475 (как по протоколу TCP, так и по UDP) — это стандартный порт, используемый службой Менеджера лицензий HASP (hasplms.exe).
• Порт 1947 (TCP и UDP) — используется современными драйверами защиты Sentinel LDK для управления аппаратными и программными ключами.

Для быстрого открытия портов на сервере можно создать правила для входящих подключений в режиме повышенной безопасности брандмауэра Windows, разрешив трафик для указанных портов, либо добавить сам исполняемый файл службы C:\Windows\System32\hasplms.exe в список исключений брандмауэра.

Решение 4: Временный откат версии Radmin VPN

Как показывает практика практикующих специалистов и обсуждения на форумах, проблема с автоматической потерей ключей часто обостряется на конкретных версиях сборки Radmin VPN. Если у вас нет возможности оперативно перенастроить файлы конфигурации на множестве рабочих станций, в качестве быстрого временного решения (workaround) можно выполнить откат программы.

Удалите текущую версию программы через "Панель управления" -> "Программы и компоненты", перезагрузите компьютер и установите стабильную предыдущую версию (например, релиз 1.1.3907 или более ранний), в котором сетевой драйвер виртуального адаптера работал корректно и не перехватывал широковещательный трафик локальной сети.

Резюме

Мы проанализировали проблему конфликта сетевых ключей защиты 1С с программным обеспечением Radmin VPN. Наиболее эффективным, надежным и профессиональным подходом является точечная настройка файла nethasp.ini с жестким ограничением широковещательного поиска и указанием целевого IP-адреса сервера. Изменение метрики интерфейса в операционной системе Windows выступает отличным вспомогательным средством, гарантирующим стабильность работы локальной инфраструктуры при использовании любых VPN-клиентов.