Share via

Una connessione esistente è stata chiusa forzatamente dall'host remoto (errore del sistema operativo 10054)

  • Articolo

Si applica a: SQL Server

Nota

Prima di iniziare la risoluzione dei problemi, è consigliabile controllare i prerequisiti e verificare l'elenco di controllo.

Questo articolo illustra in dettaglio diversi scenari e fornisce soluzioni per gli errori seguenti:

  • È stata stabilita una connessione con il server, ma si è verificato un errore durante il processo di accesso. (provider: Provider SSL, errore: 0 - Una connessione esistente è stata chiusa forzatamente dall'host remoto.

  • È stata stabilita una connessione con il server, ma si è verificato un errore durante l'handshake di pre-accesso. (provider: Provider TCP, errore: 0 - Una connessione esistente è stata chiusa forzatamente dall'host remoto.

L'errore del sistema operativo 10054 viene generato nel livello Windows Sockets. Per altre informazioni, vedere Codici di errore di Windows Sockets: WSAECONNRESET 10054.

Quando viene visualizzato l'errore?

Il canale sicuro, noto anche come Schannel, è un provider di supporto di sicurezza (SSP). Contiene un set di protocolli di sicurezza che forniscono l'autenticazione delle identità e garantiscono la comunicazione privata tramite la crittografia. Una funzione del provider di servizi condivisi Schannel consiste nell'implementare versioni diverse del protocollo Transport Layer Security (TLS). Questo protocollo è uno standard del settore progettato per proteggere la privacy delle informazioni comunicate tramite Internet.

Il protocollo Handshake TLS è responsabile dello scambio di chiavi necessario per stabilire o riprendere sessioni sicure tra due applicazioni che comunicano tramite TCP. Durante la fase di pre-accesso del processo di connessione, SQL Server e le applicazioni client usano il protocollo TLS per stabilire un canale sicuro per la trasmissione delle credenziali.

Gli scenari seguenti illustrano in dettaglio gli errori che si verificano quando non è possibile completare l'handshake:

Scenario 1: Non esistono protocolli TLS corrispondenti tra il client e il server

Secure Socket Layer (SSL) e le versioni di TLS precedenti a TLS 1.2 presentano diverse vulnerabilità note. È consigliabile eseguire l'aggiornamento a TLS 1.2 e disabilitare le versioni precedenti laddove possibile. Di conseguenza, gli amministratori di sistema potrebbero eseguire il push degli aggiornamenti tramite criteri di gruppo o altri meccanismi per disabilitare queste versioni TLS non sicure in vari computer all'interno dell'ambiente.

Gli errori di connettività si verificano quando l'applicazione usa una versione precedente del driver ODBC (Open Database Connectivity), del provider OLE DB, dei componenti .NET Framework o di una versione SQL Server che non supporta TLS 1.2. Il problema si verifica perché il server e il client non riescono a trovare un protocollo corrispondente, ad esempio TLS 1.0 o TLS 1.1. È necessario un protocollo corrispondente per completare l'handshake TLS necessario per procedere con la connessione.

Risoluzione

Per risolvere il problema, utilizzare uno dei seguenti metodi:

  • Aggiornare il SQL Server o i provider client a una versione che supporta TLS 1.2. Per altre informazioni, vedere Supporto di TLS 1.2 per Microsoft SQL Server.
  • Chiedere agli amministratori di sistema di abilitare temporaneamente TLS 1.0 o TLS 1.1 sia nel client che nei computer server eseguendo una delle azioni seguenti:

Scenario 2: Corrispondenza dei protocolli TLS nel client e nel server, ma senza pacchetti di crittografia TLS corrispondenti

Questo scenario si verifica quando l'utente o l'amministratore ha limitato determinati algoritmi nel client o nel server per una maggiore sicurezza.

Le versioni TLS client e server, i pacchetti di crittografia possono essere facilmente esaminati nei pacchetti Client Hello e Server Hello in una traccia di rete. Il pacchetto Client Hello annuncia tutti i pacchetti di crittografia client, mentre il pacchetto Server Hello ne specifica uno. Se non sono presenti gruppi corrispondenti, il server chiude la connessione anziché rispondere al pacchetto Server Hello.

Risoluzione

Per verificare il problema, seguire questa procedura:

  1. Se non è disponibile una traccia di rete, controllare il valore delle funzioni in questa chiave del Registro di sistema: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002

    Usare il comando di PowerShell seguente per trovare le funzioni TLS.

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

  2. Usare la scheda Pacchetti di crittografia nello strumento crittografia IIS per verificare se sono presenti algoritmi corrispondenti. Se non vengono trovati algoritmi corrispondenti, contattare supporto tecnico Microsoft.

Per altre informazioni, vedere Connessioni TLS 1.2 Upgrade Workflow e Transport Layer Security (TLS) che potrebbero non riuscire o timeout durante la connessione o il tentativo di ripresa.

Scenario 3: SQL Server usa un certificato firmato da un algoritmo di hash debole, ad esempio MD5, SHA224 o SHA512

SQL Server crittografa sempre i pacchetti di rete correlati all'accesso. A questo scopo, usa un certificato con provisioning manuale o un certificato autofirmato. Se SQL Server trova un certificato che supporta la funzione di autenticazione server nell'archivio certificati, usa il certificato. SQL Server usa questo certificato anche se non è stato effettuato il provisioning manuale. Se questi certificati usano un algoritmo hash debole (algoritmo di identificazione personale), ad esempio MD5, SHA224 o SHA512, non funzioneranno con TLS 1.2 e causeranno l'errore indicato in precedenza.

Nota

I certificati autofirmati non sono interessati da questo problema.

Risoluzione

Per risolvere il problema, attenersi alla seguente procedura:

  1. In Gestione configurazione SQL Server espandere SQL Server Configurazione di rete nel riquadro Console.
  2. Selezionare Protocolli come <nome> dell'istanza.
  3. Selezionare la scheda Certificato e seguire il passaggio pertinente:
    • Se viene visualizzato un certificato, selezionare Visualizza per esaminare l'algoritmo Identificazione personale per verificare se usa un algoritmo hash debole. Selezionare quindi Cancella e andare al passaggio 4.
    • Se non viene visualizzato un certificato, esaminare il log degli errori di SQL Server per una voce simile alla seguente e prendere nota del valore hash o dell'identificazione personale:
      2017-05-30 14:59:30.89 spid15s The certificate [Cert Hash(sha1) "B3029394BB92AA8EDA0B8E37BAD09345B4992E3D"] was successfully loaded for encryption
  4. Per rimuovere l'autenticazione del server, seguire questa procedura:
    1. Selezionare Avvia>esecuzione e digitare MMC. (MMC noto anche come Microsoft Management Console).
    2. In MMC aprire i certificati e selezionare Account computer nella schermata snap-in Certificati .
    3. Espandere Certificati personali>.
    4. Individuare il certificato che SQL Server utilizza in base al nome o esaminando il valore identificazione personale di certificati diversi nell'archivio certificati e aprire il relativo riquadro Proprietà.
    5. Nella scheda Generale selezionare Abilita solo gli scopi seguenti e deselezionare Autenticazione server.
  5. Riavviare il servizio SQL Server.

Scenario 4: il client e il server usano TLS_DHE suite di crittografia per l'handshake TLS, ma uno dei sistemi non dispone di correzioni zero iniziali per il TLS_DHE installato

Per altre informazioni su questo scenario, vedere L'esperienza delle applicazioni ha chiuso forzatamente gli errori di connessione TLS durante la connessione di SQL Server in Windows.

Nota

Se questo articolo non ha risolto il problema, è possibile verificare se gli articoli sui problemi di connettività comuni possono essere utili.

Scenario 5: TCP Three-Way Timeout handshake (errore SYN, rifiuto TCP) a causa della carenza di ruoli di lavoro IOCP

Nei sistemi con carichi di lavoro elevati in SQL Server 2017 e versioni precedenti, è possibile che si verifichi un errore intermittente 10054 causato da errori di handshake tcp a tre vie, causando rifiuti TCP. La causa radice di questo problema potrebbe essere il ritardo nell'elaborazione delle richieste TCPAcceptEx. Questo ritardo può essere dovuto a una carenza di operatori del listener IOCP (Input/Output Completion Port) responsabili della gestione dell'accettazione delle connessioni in ingresso. Il numero insufficiente di ruoli di lavoro IOCP e la disponibilità di altre richieste comportano un'elaborazione ritardata delle richieste di connessione, con conseguente errori di handshake e rifiuti TCP. È anche possibile osservare i timeout di accesso durante l'handshake SSL di avvio (se presente) o l'elaborazione delle richieste di accesso, che implicano controlli di autenticazione.

Risoluzione

Una carenza di ruoli di lavoro IOCP e risorse del ruolo di lavoro SOS allocati per gestire le operazioni di autenticazione e crittografia è la causa principale dei timeout dell'handshake a tre vie TCP e dei timeout di accesso aggiuntivi. SQL Server 2019 include diversi miglioramenti delle prestazioni in questo settore. Un notevole miglioramento è l'implementazione di un pool di dispatcher di account di accesso dedicato. In questo modo viene ottimizzata l'allocazione delle risorse per le attività correlate all'accesso, riducendo l'occorrenza di timeout e migliorando le prestazioni complessive del sistema.

Vedere anche

Dichiarazione di non responsabilità sulle informazioni di terze parti

I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti