En befintlig anslutning stängdes tvångsmässigt av fjärrvärden (OS-fel 10054)

Gäller för: SQL Server

Sammanfattning

I den här artikeln beskrivs scenarier i vilka SQL Server-anslutningsfelet "En befintlig anslutning stängdes tvångsmässigt av fjärrvärden" inträffar, och den innehåller lösningar. Felet är kopplat till ett misslyckat TLS-handskakning mellan klienten och SQL Server, ofta på grund av att klienten och servern inte kan komma överens om en TLS-protokollversion (till exempel TLS 1.2 eller TLS 1.3) eller en chiffersvit.

Artikeln beskriver följande felmeddelanden:

En anslutning upprättades med servern, men sedan uppstod ett fel under inloggningsprocessen. (provider: SSL-leverantör, fel: 0 - En befintlig anslutning stängdes med tvång av fjärrvärden.)

Det gick att upprätta anslutningen till servern, men det inträffade ett fel under handskakningen innan inloggningen. (provider: TCP-provider, fel: 0 - En befintlig anslutning stängdes med tvång av fjärrvärden.)

Operativsystemfelet 10054 utlöses i Windows sockets-lagret. Mer information finns i Felkoder för Windows Sockets: WSAECONNRESET 10054.

Innan du börjar felsöka kontrollerar du kraven och går igenom checklistan.

När det här felet inträffar

Secure Channel, även kallat Schannel, är en SSP (Security Support Provider ). Den innehåller en uppsättning säkerhetsprotokoll som tillhandahåller identitetsautentisering och säker privat kommunikation via kryptering. En funktion i Schannel SSP är att implementera olika versioner av TLS-protokollet (Transport Layer Security). TLS är en branschstandard som är utformad för att skydda sekretessen för information som kommuniceras via Internet.

TLS-handskakningsprotokollet ansvarar för det nyckelutbyte som behövs för att upprätta eller återuppta säkra sessioner mellan två program som kommunicerar via TCP. Under förinloggningsfasen av anslutningsprocessen använder SQL Server- och klientprogram TLS-protokollet för att konfigurera en säker kanal för överföring av autentiseringsuppgifter.

Snabb överblick över TLS-versioner

I följande tabell jämförs de TLS-versioner som du kan stöta på när du felsöker det här felet:

Version Aktuell status för Windows Rekommendation för SQL Server
TLS 1.0 / 1.1 Inaktiverad som standard på Windows 11, Windows Server 2022 och senare. Anses osäkert. Använd inte. Uppgradera klienter och servrar till TLS 1.2 eller senare.
TLS 1.2 Aktiverad som standard på alla Windows versioner som stöds. Stöds brett av SQL Server och moderna klientdrivrutiner. Rekommenderad baslinje.
TLS 1.3 Stöds på Windows 11 och Windows Server 2022 och senare. Stöds av SQL Server 2022 och senare med aktuella klientdrivrutiner (till exempel Microsoft ODBC Driver 18 och Microsoft. Data.SqlClient 5.x). Använd där både klient och server stöder det.

Det aktuella stödtillståndet för TLS-protokoll på Windows finns i Protocols i TLS/SSL (Schannel SSP).

Identifiera vilket scenario som gäller i din miljö

I följande avsnitt beskrivs olika scenarier som kan orsaka att handskakningen misslyckas. Om du inte är säker på vilken som matchar din miljö använder du dessa startpunkter för att begränsa den:

  • Samla in en nätverksspårning på klienten och servern under en misslyckad anslutning. Granska sedan Paketen Client Hello och Server Hello för att bekräfta den förhandlade TLS-versionen och chiffersviten.
  • Kontrollera SQL Server felloggen för posten successfully loaded for encryption för att bekräfta vilket certifikat som används. Kontrollera tumavtrycksalgoritmen.
  • Jämför de aktiverade TLS-versionerna och chiffersviterna på klienten och servern med hjälp av Get-TlsCipherSuite och registernycklarna under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols.
  • Bekräfta att klientdrivrutinen stöder TLS 1.2 eller senare. Äldre drivrutiner, till exempel SQL Server interna klienten, är inaktuella och rekommenderas inte.

Inget matchande TLS-protokoll mellan klient och server

Secure Sockets Layer (SSL) och versioner av TLS tidigare än TLS 1.2 har flera kända sårbarheter. I moderna Windows versioner (Windows 11, Windows Server 2022 och senare) inaktiveras TLS 1.0 och TLS 1.1 som standard. Administratörer skickar ofta även ut grupprincip- eller registerinställningar för att inaktivera dessa äldre protokoll i äldre miljöer.

Anslutningsfel uppstår när programmet använder en äldre ODBC-drivrutin (Open Database Connectivity), OLE DB-provider, .NET Framework-komponent eller SQL Server version som inte stöder TLS 1.2 eller senare. Problemet beror på att servern och klienten inte kan hitta något matchande protokoll. Ett matchande protokoll krävs för att slutföra TLS-handskakningen.

Åtgärda protokollmatchningsfel mellan klient och server

Använd en av följande metoder för att lösa problemet:

Exempel: lägsta klientdrivrutinsversioner för TLS 1.2

Använd klientkomponenter som har inbyggt stöd för TLS 1.2 eller senare. Följande komponenter är vanliga säkra baslinjer:

  • Microsoft ODBC-drivrutin 17 eller 18 för SQL Server.
  • Microsoft OLE DB Driver 18 eller 19 för SQL Server.
  • .NET Framework 4.6.2 eller senare, eller någon version av .NET som stöds (.NET 6 och senare).
  • Microsoft JDBC Driver 9.4 eller senare.

Den äldre SQL Server interna klienten (SNAC) och SQL Server OLE DB-providern som levererades med Windows (SQLOLEDB) är inaktuella. Ersätt dem med komponenterna i föregående lista.

Matchande TLS-protokoll men inga matchande chiffersviter

Det här scenariot inträffar när du eller en administratör begränsar vissa algoritmer på klienten eller servern för extra säkerhet.

Du kan undersöka klient- och server-TLS-versioner och chiffersviter i Paketen Client Hello och Server Hello i en nätverksspårning. Client Hello-paketet annonserar alla klient chiffersviter och Server Hello-paketet returnerar det som servern valde. Om det inte finns några matchande sviter stänger servern anslutningen i stället för att skicka ett Server Hello-paket .

Åtgärda felmatchning av chiffersvit

Följ dessa anvisningar för att kontrollera problemet:

  1. Om en nätverksspårning inte är tillgänglig kontrollerar du Functions värdet under den här registernyckeln: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002.

    Använd följande PowerShell-kommando för att lista de konfigurerade TLS-chiffersviterna:

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

    På Windows 10, Windows 11, Windows Server 2016 och senare kan du också köra Get-TlsCipherSuite för att visa de aktiverade sviterna i ett mer läsbart format.

  2. Använd fliken Chiffersviter i IIS Crypto-verktyget för att kontrollera om det finns några matchande algoritmer. Kontakta Microsoft Support om inga matchande algoritmer hittas.

Mer information finns i Arbetsflöde för uppgradering till TLS 1.2 och Anslutningar med Transport Layer Security (TLS) kan misslyckas eller få timeout vid anslutning eller försök till återupptagning.

TLS_DHE chiffersviter aktiverade i olika Windows versioner

Det här problemet kan inträffa när klienten och servern körs på olika Windows versioner (till exempel Windows Server 2012 och Windows Server 2016 eller senare) och båda annonserar TLS_DHE_* chiffersviter. Dessa Windows versioner hanterar Diffie-Hellman nyckelutbyte i TLS på olika sätt, vilket kan leda till att handskakningen misslyckas.

Ta bort TLS_DHE-krypteringssviter

Åtgärda problemet genom att ta bort alla chiffersviter som börjar med TLS_DHE_ från den lokala principen. Mer information om fel som uppstår när program försöker ansluta till SQL Server i Windows finns i Program får fel om att TLS-anslutningen stängs med tvång när de ansluter till SQL Server i Windows.

SQL Server certifikat använder en svag hashalgoritm

SQL Server krypterar alltid nätverkspaket som är relaterade till inloggning. För detta ändamål använder den ett manuellt etablerat certifikat eller ett självsignerat certifikat. Om SQL Server hittar ett certifikat som stöder serverautentiseringsfunktionen i certifikatarkivet använder det certifikatet även om det inte har etablerats manuellt. Om certifikatet använder en svag hashalgoritm (tumavtryck) som MD5, SHA224 eller SHA512 fungerar det inte med TLS 1.2 och orsakar felet.

Kommentar

Självsignerade certifikat påverkas inte av det här problemet.

Ersätt eller konfigurera om certifikat med svaga hash-algoritmer

Följ dessa steg för att åtgärda problemet:

  1. I Konfigurationshanteraren för SQL Server expanderar du SQL Server Network Configuration i konsolfönstret.

  2. Välj Protokoll för <instansnamn>.

  3. Välj fliken Certifikat och utför sedan någon av följande åtgärder:

    • Om ett certifikat visas väljer du Visa för att kontrollera tumavtrycksalgoritmen och bekräfta om den använder en svag hashalgoritm. Välj sedan Rensa och gå till steg 4.

    • Om inget certifikat visas, granskar du SQL Server-felloggen efter en post som liknar följande och notera hash- eller tumavtrycksvärdet:

      2017-05-30 14:59:30.89 spid15s The certificate [Cert Hash(sha1) "AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00"] was successfully loaded for encryption

  4. Ta bort serverautentisering från certifikatet:

    1. Välj Start>Run och ange MMC (Microsoft Management Console).
    2. I MMC lägger du till snapin-modulen Certifikat och väljer Datorkonto.
    3. Expandera Personliga>certifikat.
    4. Leta upp certifikatet som SQL Server använder efter namn eller tumavtryck och öppna fönstret Egenskaper.
    5. På fliken Allmänt väljer du Aktivera endast följande syften och avmarkerarServerautentisering.

  5. Starta om SQL Server-tjänsten.

TLS_DHE inledande nollkorrigeringen är inte installerad

Det här scenariot inträffar när klienten och servern förhandlar om en TLS_DHE_* chiffersvit vid TLS-handskakningen, men den ena sidan saknar den Windows-uppdatering som innehåller korrigeringen för inledande nollor i Diffie-Hellman-nyckelutbytet. Mer information om det här scenariot finns i Program får fel där TLS-anslutningar stängs med tvång vid anslutning till SQL Server i Windows.

Kommentar

Om den här artikeln inte åtgärdar problemet kontrollerar du om artiklarna om vanliga anslutningsproblem kan hjälpa dig.

TCP-timeout för trevägshandskakning från IOCP-arbetsbrist

På system med höga arbetsbelastningar som körs SQL Server 2017 eller tidigare kan det uppstå tillfälliga 10054-fel som orsakas av TCP-trevägshandskakningsfel, vilket leder till TCP-avslag. Grundorsaken är ofta en fördröjning vid bearbetning av TCPAcceptEx begäranden. Fördröjningen kan orsakas av brist på IOCP-lyssnare (Input/Output Completion Port), som hanterar godkännandet av inkommande anslutningar. När IOCP-arbetare är för få eller är upptagna med att underhålla andra begäranden bearbetas anslutningsbegäranden sent, vilket resulterar i handskakningsfel och TCP-avslag. Du kan också se tidsgränser för inloggning under SSL-handskakningen eller under bearbetningen av inloggningsbegäranden, som omfattar autentiseringskontroller.

Minska IOCP-arbetsbrist och timeouter för handskakning

Brist på IOCP-arbetare och SOS Worker-resurser som allokerats till autentiserings- och krypteringsåtgärder är den främsta orsaken till dessa TCP-tidsgränser för trevägshandskakning och tidsgränser för inloggning. SQL Server 2019 och senare innehåller flera prestandaförbättringar på det här området. En viktig förbättring är en dedikerad distributionspool för inloggning, som optimerar resursallokering för inloggningsuppgifter. Den här ändringen minskar tidsgränserna och förbättrar systemets övergripande prestanda. Om du påverkas av det här problemet planerar du en uppgradering till en SQL Server version som stöds för närvarande.

Andra scenarier med TLS-anslutningsfel

Om felmeddelandet du stöter på inte motsvarar något av de tidigare scenarierna kan du läsa följande ytterligare scenarier:

Relaterat innehåll

Ansvarsfriskrivning för information från tredje part

De produkter från andra tillverkare som diskuteras i denna artikel tillverkas oberoende av Microsoft. Produkternas funktion eller tillförlitlighet kan därför inte garanteras.

  • Last updated on