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


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

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

Примечание.

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

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

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

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

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

Когда отображается ошибка?

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

Протокол подтверждения TLS отвечает за обмен ключами, необходимый для установления или возобновления безопасных сеансов между двумя приложениями, взаимодействующими через TCP. На этапе перед входом в процессе подключения SQL Server и клиентские приложения с помощью протокола TLS создают безопасный канал для обмена учетными данными.

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

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

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

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

Решение

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

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

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

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

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

Решение

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

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

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

    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_DHE

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

Примечание.

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

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

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

Решение

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

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

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

См. также

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

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