Как исправить ошибки "The driver could not establish a secure connection to SQL Server" и "SocketTimeoutException" при обновлении базы 1С в новом режиме реструктуризации v2?

При использовании нового, оптимизированного механизма реструктуризации базы данных (версия 2) в 1С:Предприятии могут возникать различные технические сложности, особенно когда система взаимодействует с SQL Server и Java. В этом материале мы подробно разберем наиболее частые ошибки, связанные с безопасным подключением к SQL Server через SSL/TLS и таймаутами сетевого соединения, а также предложим проверенные способы их решения. Мы будем действовать пошагово, чтобы вы могли успешно обновить свою базу.

Для начала, давайте проясним, что механизм реструктуризации v2 (далее – ОМР v2) является частью платформы 1С:Предприятие, начиная с версии 8.3.16. Он предназначен для значительного ускорения процесса обновления конфигурации базы данных, особенно на больших объемах данных, за счет использования внешнего Java-процесса, который напрямую взаимодействует с СУБД (SQL Server или PostgreSQL). Именно этот Java-процесс и является источником большинства ошибок подключения, поскольку он имеет свои требования к среде и безопасности соединения.

Обязательные условия для работы Оптимизированного механизма реструктуризации v2

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

1. Клиент-серверный вариант работы: ОМР v2 предназначен только для информационных баз, работающих в клиент-серверном варианте. Файловые базы данных не поддерживаются.
2. Поддерживаемые СУБД: В качестве системы управления базами данных (СУБД) должна использоваться Microsoft SQL Server или PostgreSQL.
3. Протокол TCP/IP для SQL Server: Если мы используем Microsoft SQL Server, сервер 1С:Предприятия (и, соответственно, Java-процесс ОМР v2) должен использовать сетевой протокол TCP/IP для соединения с СУБД. Работа ОМР v2 не поддерживается, если сервер 1С:Предприятия подключается к SQL Server с использованием сетевых протоколов «Разделяемая память» (Shared Memory) или «Именованные каналы» (Named Pipes).

Чтобы проверить и настроить протокол TCP/IP, выполните следующие действия:

1. Откройте «Диспетчер конфигурации SQL Server» (SQL Server Configuration Manager).
2. Перейдите в раздел «Сетевая конфигурация SQL Server» (SQL Server Network Configuration).
3. Выберите экземпляр вашего SQL Server.
4. Убедитесь, что протокол TCP/IP включен. Если он отключен, включите его и перезапустите службу SQL Server для применения изменений.

Решение проблемы "The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption"

Это одна из самых частых ошибок, возникающих при запуске ОМР v2. Полный текст ошибки, который вы можете увидеть в логах (для оперативного реагирования есть мониторинг ошибок 1С с уведомлением в Telegram) или в окне конфигуратора, выглядит следующим образом:

В процессе обновления конфигурации базы данных при работе оптимизированного механизма обновления произошла критическая ошибка по причине: Критическая ошибка работы Java-процесса. Путь к Java: C:\Program Files (x86)\BellSoft\LibericaJRE-8-Full\bin\java.exe Действие: prepare Process ID: 2596 Код возврата: 1 Ошибка: Exception in thread "main" com._1c.dmf.v8.cli.ApplicationException: com.microsoft.sqlserver.jdbc.SQLServerException: The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: "The server selected protocol version TLS10 is not accepted by client preferences [TLS13, TLS12]". ClientConnectionId:52ff6245-493e-4fd6-8333-24be583d1fd3

Перевод основной части ошибки: "Драйверу не удалось установить безопасное соединение с SQL Server с использованием шифрования Secure Sockets Layer (SSL). Ошибка: «Версия протокола сервера TLS10 не принимается клиентскими предпочтениями [TLS13, TLS12]»."

Почему это происходит?

Эта ошибка прямо указывает на конфликт версий протокола TLS (Transport Layer Security) между Java-процессом 1С (клиентом) и вашим SQL Server (сервером). Современные версии Java Runtime Environment (JRE), такие как те, что используются 1С для ОМР v2, по умолчанию отключают устаревшие и менее безопасные версии протоколов TLS (TLS 1.0 и TLS 1.1). Это сделано из соображений безопасности. Однако, если ваш SQL Server настроен или по умолчанию использует только эти устаревшие версии TLS, или если у него отсутствуют необходимые обновления для поддержки более новых версий (TLS 1.2 или TLS 1.3), то Java-клиент отвергнет соединение, поскольку сервер предлагает протокол, который клиент считает небезопасным или нежелательным.

Как мы можем это исправить?

Существует два основных подхода к решению этой проблемы: быстрое (но менее безопасное) и рекомендуемое (более безопасное).

1. Изменение конфигурации Java: Включение поддержки устаревших версий TLS (быстрое решение)

Этот метод временно позволяет Java-процессу 1С использовать устаревшие протоколы TLS, чтобы установить соединение. Это может помочь быстро решить проблему и продолжить обновление, но мы должны понимать, что это снижает общий уровень безопасности соединения. Мы не рекомендуем использовать этот подход на постоянной основе в продуктивной среде.

1. Найдите файл java.security: Этот файл находится в каталоге установки вашей Java Runtime Environment (JRE). Путь к Java обычно указывается в сообщении об ошибке (например, C:\Program Files (x86)\BellSoft\LibericaJRE-8-Full\bin\java.exe). Мы должны найти файл по пути, подобному C:\Program Files (x86)\BellSoft\LibericaJRE-8-Full\lib\security\java.security или C:\Program Files\Java\jre1.8.0_291\lib\security\java.security. Если вы не уверены в используемой JRE, проверьте переменную окружения JAVA_HOME или настройки сервера 1С.
2. Откройте файл java.security: Откройте его в любом текстовом редакторе с правами администратора (например, Блокнот от имени администратора).
3. Найдите строку jdk.tls.disabledAlgorithms: Внутри файла найдите строку, которая начинается с jdk.tls.disabledAlgorithms=. Эта строка содержит список алгоритмов и протоколов, которые Java отключает по умолчанию. Пример такой строки:
   Скопировать код

   
   jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, ...
   

4. Удалите устаревшие протоколы: Мы должны удалить TLSv1 и TLSv1.1 из этого списка. После изменений строка должна выглядеть примерно так:
   Скопировать код

   
   jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, ...
   

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

5. Сохраните изменения: Сохраните файл.
6. Перезапустите сервер 1С:Предприятия: Чтобы изменения вступили в силу, нам необходимо перезапустить службу сервера 1С:Предприятия (для этого подойдёт обработка принудительного завершения сеансов 1С), а затем повторить попытку обновления базы данных.

После выполнения этих шагов, как правило, проблема с SSL/TLS соединением исчезает, и обновление продолжается. Об этом свидетельствует сообщение 11, где автор подтверждает, что решение с java.security сработало.

2. Настройка SQL Server для поддержки TLS 1.2 и выше (рекомендуемое и безопасное решение)

Наиболее правильным и безопасным подходом является обновление и настройка вашего Microsoft SQL Server для поддержки современных версий протокола TLS, в частности TLS 1.2 и TLS 1.3. Это устранит корень проблемы, повысит безопасность всей системы и избавит нас от необходимости снижать уровень безопасности Java-среды.

Для этого мы должны предпринять следующие шаги:

1. Обновите SQL Server: Убедитесь, что ваш SQL Server обновлен до версии, которая официально поддерживает TLS 1.2 или выше. Для старых версий SQL Server (например, SQL Server 2008 R2, SQL Server 2012, SQL Server 2014) может потребоваться установка соответствующих пакетов обновлений (Service Packs) и накопительных обновлений (Cumulative Updates).
2. Включите TLS 1.2 на уровне операционной системы и SQL Server: Для SQL Server поддержка TLS регулируется на уровне операционной системы Windows через реестр, а также через настройки самого SQL Server. Мы можем использовать следующие шаги:
   • Убедитесь, что на сервере с SQL Server установлены все последние обновления безопасности для Windows.
   • Проверьте и, при необходимости, настройте параметры реестра для активации TLS 1.2. Обычно это включает добавление или изменение параметров в ветках HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2. Для получения точных инструкций по настройке реестра мы рекомендуем обращаться к официальной документации Microsoft.
   • Перезапустите SQL Server после любых изменений в реестре или обновлений.
3. Обновите драйвер JDBC для SQL Server: Убедитесь, что Java-процесс 1С использует актуальный драйвер JDBC для SQL Server. Платформа 1С обычно поставляется с собственными версиями драйверов, но стоит убедиться в их актуальности.

Этот подход требует более глубоких знаний в администрировании SQL Server (поможет инструмент администрирования кластера и баз 1С) и операционной системы, но обеспечивает наиболее надежное и безопасное решение проблемы.

Дополнительные проверки для SSL/TLS

В некоторых случаях, даже при включении TLS, могут возникать проблемы с SSL-сертификатами:

• Проверка сертификатов: Если SQL Server настроен на использование SSL с серверным сертификатом, этот сертификат (или сертификат выпускающего центра) должен быть импортирован в хранилище сертификатов Java (cacerts) на машине, где работает сервер 1С. Для временного обхода этой проблемы (небезопасно для продуктивной среды) можно попробовать добавить параметры encrypt=true;trustServerCertificate=true в строку подключения JDBC. Однако 1С управляет этим подключением внутренне, и такой прямой контроль над параметрами может быть недоступен пользователю.

Решение проблемы "java.net.SocketTimeoutException: Receive timed out"

Помимо проблем с SSL/TLS, мы можем столкнуться с ошибками таймаута при попытке подключения к SQL Server. Пример такой ошибки:

В процессе обновления конфигурации базы данных при работе оптимизированного механизма обновления произошла критическая ошибка по причине: Критическая ошибка работы Java-процесса. Путь к Java: C:\Program Files\JAVA\\bin\java.exe Действие: prepare Process ID: 13496 Код возврата: 1 Ошибка: Exception in thread "main" com._1c.dmf.v8.cli.ApplicationException: com.microsoft.sqlserver.jdbc.SQLServerException: The connection to the host SQLTORG, named instance MSSQLSERVERDEV, 1415 failed. Error: "java.net.SocketTimeoutException: Receive timed out". Verify the server and instance names and check that no firewall is blocking UDP traffic to port 1434. For SQL Server 2005 or later, verify that the SQL Server Browser Service is running on the host.

Перевод основной части: "Соединение с хостом SQLTORG, именованным экземпляром MSSQLSERVERDEV, порт 1415 не удалось. Ошибка: «java.net.SocketTimeoutException: Таймаут получения». Проверьте имена сервера и экземпляра, а также убедитесь, что брандмауэр не блокирует UDP-трафик на порт 1434. Для SQL Server 2005 или более поздних версий убедитесь, что на хосте запущена служба SQL Server Browser."

Почему это происходит?

Эта ошибка указывает на то, что Java-процесс 1С не смог установить соединение с SQL Server в течение заданного времени ожидания. Это обычно связано с сетевыми проблемами, неправильными именами сервера/экземпляра или некорректной конфигурацией SQL Server.

Как мы можем это исправить?

1. Проверьте имя сервера и экземпляра SQL Server: Мы должны убедиться, что имя хоста (SQLTORG) и имя именованного экземпляра (MSSQLSERVERDEV), указанные в настройках подключения 1С к СУБД, абсолютно корректны. Малейшая опечатка приведет к невозможности подключения.
2. Проверьте службу SQL Server Browser: Для именованных экземпляров SQL Server (то есть тех, которые подключаются не по стандартному порту 1433, а по имени экземпляра) служба SQL Server Browser играет критически важную роль. Она прослушивает UDP-порт 1434 и предоставляет информацию о портах, на которых запущены именованные экземпляры SQL Server.
   • Убедитесь, что служба SQL Server Browser запущена на сервере с SQL Server.
   • Проверьте, что брандмауэр на сервере SQL Server не блокирует UDP-порт 1434.
3. Проверьте брандмауэр: Убедитесь, что брандмауэр Windows (или любой другой сетевой брандмауэр) на сервере 1С и на сервере SQL Server не блокирует необходимые порты.
   • Стандартный порт для SQL Server — TCP 1433.
   • Порт для службы SQL Server Browser — UDP 1434.
   • Если ваш именованный экземпляр SQL Server использует динамические порты, или вы явно настроили ему статический порт, мы должны убедиться, что этот порт также открыт.
4. Проверьте протокол TCP/IP: Как мы уже упоминали выше, убедитесь, что протокол TCP/IP включен для вашего экземпляра SQL Server в SQL Server Configuration Manager. Если мы изменили настройки, необходимо перезапустить службу SQL Server.
5. Проверьте доступность SQL Server: Мы должны убедиться, что сам экземпляр SQL Server запущен и принимает входящие соединения на указанном порту. Мы можем попробовать подключиться к SQL Server с машины сервера 1С с помощью SQL Server Management Studio (SSMS) или с помощью команды ping и telnet (если telnet-клиент установлен) для проверки сетевого доступа к порту. Например, telnet SQLTORG 1433 (если SQLTORG - это имя сервера и используется стандартный порт).
6. Укажите имя сервера СУБД без префиксов: В консоли сервера 1С при настройке соединения с СУБД иногда используются префиксы типа lpc: (для локальных подключений). Для Java-компонента ОМР v2 это может быть непонятно и вызывать таймаут. Мы должны указывать имя сервера СУБД так, как если бы мы обращались к нему по сетевому доступу, например, просто SQLTORG или SQLTORG\MSSQLSERVERDEV.

Общие рекомендации и дополнительные аспекты при работе с ОМР v2

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

1. Резервное копирование: Перед использованием ОМР v2 крайне важно выполнить полную резервную копию базы данных. Механизм v2 работает иначе, чем v1, и в случае сбоя он может необратимо повредить базу, не предоставляя привычного «второго шанса» с окном отмены. Как подчеркивает сообщение 12, "там нет второго шанса, как при v1 с получением окошка, а чего там менять собственно будем и кнопочкой отмены. Запустил и жди..". Мы должны быть готовы к любой нештатной ситуации.
2. Разрядность Java и 1С: Убедитесь, что установленная вами Java Runtime Environment (JRE) имеет ту же разрядность (32-бит или 64-бит), что и сервер 1С:Предприятия. Различия в разрядности могут приводить к проблемам с запуском Java-процесса.
3. Путь к Java: Проверьте правильность пути к исполняемому файлу Java (java.exe), который использует 1С. Этот путь может быть указан в файле conf.cfg сервера 1С или определяться через системную переменную окружения JAVA_HOME. Убедитесь, что сервер 1С способен найти и запустить соответствующую JRE. В некоторых случаях мы можем попробовать добавить путь до папки bin вашей JRE в системную переменную Path.
4. Актуальная версия платформы 1С: Мы должны убедиться, что используем актуальную версию платформы 1С:Предприятие. Разработчики постоянно выпускают обновления, которые содержат исправления ошибок и улучшения, в том числе и для оптимизированного механизма реструктуризации.
5. Очистка кэша 1С: В некоторых редких случаях ошибки при обновлении 1С могут быть связаны с поврежденным кэшем программы. Попробуйте очистить кэш 1С, удалив папки с длинными именами (состоящими из случайных символов) в каталогах, таких как C:\Users\Username\AppData\Roaming\1C\1CE\ и C:\Users\Username\AppData\Local\1C\1CE\.
6. Мониторинг логов: В процессе обновления всегда внимательно следите за логами сервера 1С и SQL Server. Они могут предоставить ценные дополнительные детали об ошибках, которые помогут нам в диагностике — для этого пригодится анализ производительности 1С и SQL Server.
7. Влияние расширений конфигурации: Имейте в виду, что использование расширений конфигурации может влиять на работу нового механизма реструктуризации. Иногда ошибки, подобные NoSuchElementException: Сущность "ReferenceChngR58055" не имеет разделителя с идентификатором... (сообщение 18), могут указывать на проблемы с метаданными или их изменением через расширения.

Мы надеемся, что этот подробный разбор поможет вам успешно справиться с ошибками при использовании нового режима реструктуризации v2 в 1С:Предприятии и обеспечить стабильную работу вашей системы.