Une connexion existante a été fermée de force par l’hôte distant (erreur de système d’exploitation 10054)

  • Article

S’applique à : SQL Server

Remarque

Avant de commencer à résoudre un problème, nous vous recommandons de consulter les prérequis et de parcourir la liste de vérification.

Cet article détaille différents scénarios et fournit des solutions pour les erreurs suivantes :

  • Une connexion a été établie avec le serveur, mais une erreur s’est ensuite produite pendant le processus d’ouverture de session. (fournisseur : fournisseur SSL, erreur : 0 - Une connexion existante a été fermée de force par l’hôte distant.)

  • Une connexion a été établie avec le serveur, mais une erreur s’est produite lors de l’établissement d’une liaison préalable à la connexion. (fournisseur : fournisseur TCP, erreur : 0 - Une connexion existante a été fermée de force par l’hôte distant.)

L’erreur du système d’exploitation 10054 est générée dans la couche de sockets Windows. Pour plus d’informations, consultez Codes d’erreur Windows Sockets : WSAECONNRESET 10054.

Quand voyez-vous l’erreur ?

Le canal sécurisé, également appelé Schannel, est un fournisseur de support de sécurité (SSP). Il contient un ensemble de protocoles de sécurité qui fournissent une authentification d’identité et une communication privée sécurisée via le chiffrement. L’une des fonctions de SSP Schannel est d’implémenter différentes versions du protocole TLS (Transport Layer Security). Ce protocole est une norme de l’industrie conçue pour protéger la confidentialité des informations communiquées sur Internet.

Le protocole TLS Handshake est responsable de l’échange de clés nécessaire pour établir ou reprendre des sessions sécurisées entre deux applications communiquant via TCP. Pendant la phase de pré-connexion du processus de connexion, les applications clientes et SQL Server utilisent le protocole TLS pour établir un canal sécurisé pour la transmission des informations d’identification.

Les scénarios suivants détaillent les erreurs qui se produisent lorsque l’établissement d’une liaison ne peut pas être terminé :

Scénario 1 : Il n’existe aucun protocole TLS correspondant entre le client et le serveur

Ssl (Secure Socket Layer) et les versions de TLS antérieures à TLS 1.2 présentent plusieurs vulnérabilités connues. Nous vous encourageons à effectuer une mise à niveau vers TLS 1.2 et à désactiver les versions antérieures dans la mesure du possible. En conséquence, les administrateurs système peuvent envoyer des mises à jour via une stratégie de groupe ou d’autres mécanismes pour désactiver ces versions TLS non sécurisées sur différents ordinateurs de votre environnement.

Des erreurs de connectivité se produisent lorsque votre application utilise une version antérieure du pilote ODBC (Open Database Connectivity), du fournisseur OLE DB, des composants .NET Framework ou une version SQL Server qui ne prend pas en charge TLS 1.2. Le problème se produit parce que le serveur et le client ne peuvent pas trouver de protocole correspondant (par exemple, TLS 1.0 ou TLS 1.1). Un protocole correspondant est nécessaire pour terminer l’établissement d’une liaison TLS requise pour poursuivre la connexion.

Résolution

Pour résoudre ce problème, appliquez l’une des méthodes suivantes :

  • Mettez à niveau votre SQL Server ou vos fournisseurs clients vers une version prenant en charge TLS 1.2. Pour plus d’informations, consultez Prise en charge de TLS 1.2 pour Microsoft SQL Server.
  • Demandez aux administrateurs système d’activer temporairement TLS 1.0 ou TLS 1.1 sur les ordinateurs client et serveur en effectuant l’une des actions suivantes :

Scénario 2 : Correspondance des protocoles TLS sur le client et le serveur, mais pas de suites de chiffrement TLS correspondantes

Ce scénario se produit lorsque vous ou votre administrateur avez restreint certains algorithmes sur le client ou le serveur pour une sécurité supplémentaire.

Les versions tls client et serveur, les suites de chiffrement peuvent être facilement examinées dans les paquets Hello Hello client et serveur dans une trace réseau. Le paquet Hello client publie toutes les suites de chiffrement client, tandis que le paquet Hello serveur en spécifie l’une. S’il n’existe aucune suite correspondante, le serveur ferme la connexion au lieu de répondre au paquet server Hello.

Résolution

Pour case activée le problème, procédez comme suit :

  1. Si aucune trace réseau n’est disponible, case activée la valeur des fonctions sous cette clé de Registre :HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002

    Utilisez la commande PowerShell suivante pour rechercher les fonctions TLS.

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

  2. Utilisez l’onglet Suites de chiffrement dans l’outil IIS Crypto pour case activée s’il existe des algorithmes correspondants. Si aucun algorithme correspondant n’est trouvé, contactez Support Microsoft.

Pour plus d’informations, consultez Flux de travail de mise à niveau TLS 1.2 et les connexions TLS (Transport Layer Security) peuvent échouer ou expirer lors de la connexion ou de la tentative de reprise.

Scénario 3 : SQL Server utilise un certificat signé par un algorithme de hachage faible, tel que MD5, SHA224 ou SHA512

SQL Server chiffre toujours les paquets réseau liés à la connexion. À cet effet, il utilise un certificat provisionné manuellement ou un certificat auto-signé. Si SQL Server trouve un certificat qui prend en charge la fonction d’authentification du serveur dans le magasin de certificats, il utilise le certificat. SQL Server utilise ce certificat même s’il n’a pas été provisionné manuellement. Si ces certificats utilisent un algorithme de hachage faible (algorithme d’empreinte numérique) tel que MD5, SHA224 ou SHA512, ils ne fonctionnent pas avec TLS 1.2 et provoquent l’erreur mentionnée précédemment.

Remarque

Les certificats auto-signés ne sont pas affectés par ce problème.

Résolution

Pour résoudre ce problème, procédez comme suit :

  1. Dans Gestionnaire de configuration SQL Server, développez SQL Server Configuration réseau dans le volet Console.
  2. Sélectionnez Protocoles pour <instance nom>.
  3. Sélectionnez l’onglet Certificat et suivez l’étape appropriée :
    • Si un certificat est affiché, sélectionnez Affichage pour examiner l’algorithme d’empreinte numérique afin de vérifier s’il utilise un algorithme de hachage faible. Ensuite, sélectionnez Effacer et passez à l’étape 4.
    • Si aucun certificat n’est affiché, passez en revue le journal des erreurs SQL Server pour rechercher une entrée qui ressemble à ce qui suit et notez la valeur de hachage ou d’empreinte numérique :
      2017-05-30 14:59:30.89 spid15s The certificate [Cert Hash(sha1) "B3029394BB92AA8EDA0B8E37BAD09345B4992E3D"] was successfully loaded for encryption
  4. Pour supprimer l’authentification du serveur, procédez comme suit :
    1. Sélectionnez Démarrerl’exécution>, puis tapez MMC. (MMC également appelée Console de gestion Microsoft.)
    2. Dans MMC, ouvrez les certificats et sélectionnez Compte d’ordinateur dans l’écran du composant logiciel enfichable Certificats .
    3. Développez Certificats personnels>.
    4. Recherchez le certificat que SQL Server utilise par son nom ou en examinant la valeur Empreinte numérique des différents certificats dans le magasin de certificats et ouvrez son volet Propriétés.
    5. Sous l’onglet Général , sélectionnez Activer uniquement les objectifs suivants et désélectionnez Authentification du serveur.
  5. Redémarrez le service SQL Server.

Scénario 4 : Le client et le serveur utilisent TLS_DHE suite de chiffrement pour l’établissement d’une liaison TLS, mais l’un des systèmes n’a pas de correctifs non significatifs pour le TLS_DHE installé

Pour plus d’informations sur ce scénario, consultez Les applications rencontrent des erreurs de connexion TLS fermées de force lors de la connexion de serveurs SQL Server dans Windows.

Remarque

Si cet article n’a pas résolu votre problème, vous pouvez case activée si les articles sur les problèmes de connectivité courants peuvent vous aider.

Scénario 5 : Délai d’expiration de liaison tcp Three-Way (échec SYN, rejet TCP) en raison d’une pénurie de workers IOCP

Dans les systèmes avec des charges de travail élevées sur SQL Server 2017 et versions antérieures, vous pouvez observer une erreur intermittente 10054 causée par des échecs d’établissement d’une liaison TCP triple, ce qui entraîne des rejets TCP. La cause racine de ce problème peut être le délai de traitement des demandes TCPAcceptEx. Ce retard peut être dû à une pénurie d’écouteurs IOCP (Input/Output Completion Port) chargés de gérer l’acceptation des connexions entrantes. Le nombre insuffisant de workers IOCP et de personnes occupées à traiter d’autres demandes entraînent un retard dans le traitement des demandes de connexion, ce qui entraîne des échecs d’établissement de la liaison et des rejets TCP. Vous pouvez également observer des délais d’expiration de connexion pendant l’établissement d’une liaison SSL de démarrage (le cas échéant) ou le traitement des demandes de connexion, qui impliquent des vérifications d’authentification.

Résolution

Une pénurie de workers IOCP et de ressources SOS Worker allouées à la gestion des opérations d’authentification et de chiffrement est la cause la main des délais d’expiration de la négociation tcp triple et des délais d’expiration de connexion supplémentaires. SQL Server 2019 comprend plusieurs améliorations des performances dans ce domaine. Une amélioration notable est l’implémentation d’un pool de répartiteurs de connexion dédié. Cela optimise l’allocation des ressources pour les tâches liées à la connexion, ce qui réduit les délais d’expiration et améliore les performances globales du système.

Voir aussi

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.