Поделиться через

Существующее подключение было принудительно закрыто удаленным узлом (ошибка ОС 10054)

  • Статья

Применяется к: SQL Server

Примечание.

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

В этой статье описаны различные сценарии и приведены способы устранения следующих ошибок:

  • Подключение к серверу успешно установлено, но затем произошла ошибка при входе. (Поставщик: поставщик SSL, ошибка: 0 — существующее подключение было принудительно закрыто удаленным узлом.)

  • Соединение было успешно установлено с сервером, но при подтверждении перед входом возникла ошибка. (поставщик: поставщик TCP, ошибка: 0 — существующее подключение было принудительно закрыто удаленным узлом.)

Ошибка операционной системы 10054 возникает на уровне сокетов Windows. Дополнительные сведения см. в статье Коды ошибок сокетов Windows: WSAECONNRESET 10054.

Когда вы видите ошибку?

Secure Channel, также известный как Schannel, является поставщиком поддержки безопасности (SSP). Он содержит набор протоколов безопасности, которые обеспечивают проверку подлинности удостоверений и безопасный частный обмен данными с помощью шифрования. Одной из функций Schannel SSP является реализация различных версий протокола TLS. Этот протокол является отраслевым стандартом, предназначенным для защиты конфиденциальности информации, сообщаемой через Интернет.

Протокол ПОДТВЕРЖДЕНИЯ TLS отвечает за обмен ключами, необходимый для создания или возобновления безопасных сеансов между двумя приложениями, обменивающимися данными по ПРОТОКОЛу TCP. На этапе перед входом в процесс подключения SQL Server и клиентские приложения используют протокол TLS для создания безопасного канала для передачи учетных данных.

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

Сценарий 1. Между клиентом и сервером не существует соответствующих протоколов TLS

Протокол SSL и версии TLS, предшествующие TLS 1.2, имеют несколько известных уязвимостей. Рекомендуется выполнить обновление до TLS 1.2 и по возможности отключить более ранние версии. Соответственно, системные администраторы могут отправлять обновления с помощью групповой политики или других механизмов, чтобы отключить эти небезопасные версии TLS на различных компьютерах в вашей среде.

Ошибки подключения возникают, если приложение использует более раннюю версию драйвера ODBC, поставщика OLE DB, компонентов платформы .NET или версию SQL Server, которая не поддерживает TLS 1.2. Проблема возникает из-за того, что сервер и клиент не могут найти соответствующий протокол (например, TLS 1.0 или TLS 1.1). Для завершения подтверждения TLS, необходимого для продолжения подключения, необходим соответствующий протокол.

Решение

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

  • Обновите SQL Server или поставщиков клиентов до версии, поддерживающей TLS 1.2. Дополнительные сведения см. в статье Поддержка TLS 1.2 для Microsoft SQL Server.
  • Попросите системных администраторов временно включить TLS 1.0 или TLS 1.1 как на клиентском, так и на серверном компьютерах, выполнив одно из следующих действий:

Сценарий 2. Сопоставление протоколов TLS на клиенте и сервере, но без соответствующих наборов шифров TLS

Этот сценарий возникает, когда вы или ваш администратор ограничили определенные алгоритмы на клиенте или сервере для дополнительной безопасности.

Клиентские и серверные версии TLS, наборы шифров можно легко изучить в клиентских Hello и server Hello пакетов в трассировке сети. Пакет клиентского Hello объявляет все наборы шифров клиента, а пакет Hello сервера указывает один из них. Если соответствующие наборы отсутствуют, сервер закрывает подключение, а не отвечает на пакет Hello сервера.

Решение

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

  1. Если трассировка сети недоступна, проверка значение функций в этом разделе реестра:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002

    Используйте следующую команду PowerShell, чтобы найти функции TLS.

    Get-ItemPropertyValue  -Path HKLM:\System\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002\ -Name Functions

  2. Используйте вкладку Наборы шифров в средстве шифрования IIS, чтобы проверка, есть ли соответствующие алгоритмы. Если соответствующие алгоритмы не найдены, обратитесь к служба поддержки Майкрософт.

Дополнительные сведения см. в разделе Рабочий процесс обновления TLS 1.2 и подключения TLS могут завершиться сбоем или истечением времени ожидания при подключении или попытке возобновления.

Сценарий 3. Могут быть включены шифры TLS_DHE

Эта проблема возникает, когда клиент или сервер размещается в Windows 2012, 2016 и более поздних версиях. Несмотря на то, что обе версии ОС имеют один и тот же шифр (TLS_DHE*), Windows 2012 и 2016+ обрабатывают ключи шифрования в TLS по-разному. Это может привести к ошибкам связи.

Решение

Чтобы устранить эту проблему, удалите из локальной политики все шифры, начиная с TLS_DHE*. Дополнительные сведения об ошибках, возникающих при попытке приложений подключиться к SQL Server в Windows, см. в статье Приложения сталкиваются с ошибками принудительно закрытого подключения TLS при подключении серверов SQL Server в Windows.

Сценарий 4. SQL Server использует сертификат, подписанный алгоритмом слабого хэша, например MD5, SHA224 или SHA512

SQL Server всегда шифрует сетевые пакеты, связанные с входом. Для этого используется вручную подготовленный сертификат или самозаверяющий сертификат. Если SQL Server находит сертификат, поддерживающий функцию проверки подлинности сервера в хранилище сертификатов, он использует сертификат. SQL Server использует этот сертификат, даже если он не был подготовлен вручную. Если эти сертификаты используют слабый хэш-алгоритм (алгоритм отпечатка), например MD5, SHA224 или SHA512, они не будут работать с TLS 1.2 и вызывают ранее указанную ошибку.

Примечание.

Эта проблема не затрагивает самозаверяемые сертификаты.

Решение

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

  1. В диспетчер конфигурации SQL Server разверните узел SQL Server Конфигурация сети в области Консоли.
  2. Выберите Протоколы в поле <Имя> экземпляра.
  3. Перейдите на вкладку Сертификат и выполните соответствующий шаг:
    • Если отображается сертификат, выберите Вид , чтобы проверить алгоритм отпечатка и убедиться, что в нем используется алгоритм слабого хэша. Затем нажмите кнопку Очистить и перейдите к шагу 4.
    • Если сертификат не отображается, просмотрите в журнале ошибок SQL Server запись, похожую на следующую, и запишите значение хэша или отпечатка:
      2017-05-30 14:59:30.89 spid15s The certificate [Cert Hash(sha1) "B3029394BB92AA8EDA0B8E37BAD09345B4992E3D"] was successfully loaded for encryption
  4. Чтобы удалить проверку подлинности сервера, выполните следующие действия.
    1. Выберите Запустить>запуск и введите MMC. (MMC также называется консолью управления Майкрософт.)
    2. В MMC откройте сертификаты и выберите Учетная запись компьютера на экране оснастки Сертификаты .
    3. Разверните узел Личные>сертификаты.
    4. Найдите сертификат, который SQL Server использует, по имени или проверив значение отпечатка различных сертификатов в хранилище сертификатов, и откройте его панель Свойства.
    5. На вкладке Общие выберите Включить только следующие цели и снимите флажок Проверка подлинности сервера.
  5. Перезапустите службу SQL Server.

Сценарий 5. Клиент и сервер используют TLS_DHE комплект шифров для подтверждения TLS, но в одной из систем не установлены начальные нулевых исправлений для TLS_DHE

Дополнительные сведения об этом сценарии см. в статье Приложения сталкиваются с ошибками принудительного закрытия подключения TLS при подключении серверов SQL Server в Windows.

Примечание.

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

Сценарий 6. Время ожидания подтверждения TCP Three-Way (сбой SYN, отклонение TCP) из-за нехватки рабочих ролей IOCP

В системах с высоким уровнем рабочих нагрузок в SQL Server 2017 г. и более ранних версий может наблюдаться периодически возникает ошибка 10054, вызванная сбоем трехстороннего подтверждения TCP, что приводит к отклонению TCP. Основная причина этой проблемы может заключаться в задержке обработки TCPAcceptEx запросов. Эта задержка может быть вызвана нехваткой рабочих ролей прослушивателя IOCP (порт ввода-вывода), отвечающих за управление приемом входящих подключений. Недостаточное количество рабочих ролей IOCP и загруженность обслуживания других запросов приводит к задержке обработки запросов на подключение, что в конечном итоге приводит к сбоям подтверждения и отклонению TCP. Вы также можете наблюдать превышение времени ожидания входа во время подтверждения SSL запуска (если таковое имеется) или обработки запросов на вход, которые связаны с проверкой подлинности.

Решение

Нехватка рабочих ролей IOCP и рабочих ресурсов SOS, выделенных для обработки операций проверки подлинности и шифрования, является main причиной истечения времени ожидания трехстороннего подтверждения TCP и дополнительных тайм-аутов входа. SQL Server 2019 году включает несколько улучшений производительности в этой области. Одним из важных улучшений является реализация выделенного пула диспетчеров входа. Это оптимизирует выделение ресурсов для задач, связанных с входом, что сокращает время ожидания и повышает общую производительность системы.

Другие сценарии, в которых tls-подключения завершаются сбоем

Если появилось сообщение об ошибке не соответствует ни одному из предыдущих сценариев, ознакомьтесь со следующими дополнительными сценариями:

См. также

Заявление об отказе от ответственности за сведения о продуктах сторонних производителей

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