Share via

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

  • Artikel

Gäller för: SQL Server

Obs!

Innan du börjar felsöka rekommenderar vi att du kontrollerar förutsättningarna och går igenom checklistan.

Den här artikeln beskriver olika scenarier och innehåller lösningar på följande fel:

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

  • En anslutning upprättades med servern, men sedan uppstod ett fel under handskakningen före inloggningen. (provider: TCP-provider, fel: 0 – En befintlig anslutning stängdes med två skäl av fjärrvärden.)

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

När visas felet?

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). Det här protokollet är en branschstandard som är utformad för att skydda sekretessen för information som förmedlas via Internet.

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

I följande scenarier beskrivs fel som uppstår när handskakningen inte kan slutföras:

Scenario 1: Det finns inga matchande TLS-protokoll mellan klienten och servern

Secure Socket Layer (SSL) och versioner av TLS tidigare än TLS 1.2 har flera kända säkerhetsrisker. Du uppmanas att uppgradera till TLS 1.2 och inaktivera tidigare versioner där det är möjligt. Därför kan systemadministratörer skicka ut uppdateringar via grupprinciper eller andra mekanismer för att inaktivera dessa osäkra TLS-versioner på olika datorer i din miljö.

Anslutningsfel uppstår när programmet använder en tidigare version av ODBC-drivrutinen (Open Database Connectivity), OLE DB-providern, .NET-ramverkskomponenter eller en SQL Server version som inte stöder TLS 1.2. Problemet beror på att servern och klienten inte kan hitta ett matchande protokoll (till exempel TLS 1.0 eller TLS 1.1). Ett matchande protokoll krävs för att slutföra TLS-handskakningen som krävs för att fortsätta med anslutningen.

Åtgärd

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

Scenario 2: Matchande TLS-protokoll på klienten och servern, men inga matchande TLS-chiffersviter

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

Klient- och server-TLS-versioner, chiffersviter kan enkelt undersökas i klient-Hello- och server-Hello paket i en nätverksspårning. Client Hello-paketet annonserar alla klient chiffersviter, medan Server Hello-paketet anger en av dem. Om det inte finns några matchande sviter stänger servern anslutningen i stället för att svara på Server Hello-paketet.

Åtgärd

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

  1. Om en nätverksspårning inte är tillgänglig kontrollerar du funktionsvä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 hitta TLS-funktionerna.

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

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

Mer information finns i TLS 1.2 Upgrade Workflow and Transport Layer Security (TLS) connections might fail or timeout when connecting or attempting asumtion (TLS 1.2 Upgrade Workflow and Transport Layer Security(TLS) connections might fail or timeout when connecting or attempting asumtion .

Scenario 3: SQL Server använder ett certifikat som signerats av en svag hashalgoritm, till exempel MD5, SHA224 eller SHA512

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. SQL Server använder det här certifikatet även om det inte har etablerats manuellt. Om dessa certifikat använder en svag hash-algoritm (tumavtrycksalgoritm) som MD5, SHA224 eller SHA512 fungerar de inte med TLS 1.2 och orsakar det tidigare nämnda felet.

Obs!

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

Lösning

Du löser problemet genom att följa dessa steg:

  1. I Konfigurationshanteraren för SQL Server expanderar du SQL Server Nätverkskonfiguration i konsolfönstret.
  2. Välj Protokoll som <instansnamn>.
  3. Välj fliken Certifikat och följ det relevanta steget:
    • Om ett certifikat visas väljer du Visa för att undersöka tumavtrycksalgoritmen för att bekräfta om den använder en algoritm för svag hash. Välj sedan Rensa och gå till steg 4.
    • Om ett certifikat inte visas granskar du SQL Server felloggen för en post som liknar följande och noterar hash- eller tumavtrycksvärdet:
      2017-05-30 14:59:30.89 spid15s The certificate [Cert Hash(sha1) "B3029394BB92AA8EDA0B8E37BAD09345B4992E3D"] was successfully loaded for encryption
  4. Använd följande steg för att ta bort serverautentisering:
    1. Välj Starta>körning och skriv MMC. (MMC kallas även Microsoft Management Console.)
    2. Öppna certifikaten i MMC och välj Datorkonto på snapin-modulen Certifikat .
    3. Expandera Personliga>certifikat.
    4. Leta upp certifikatet som SQL Server använder med dess namn eller genom att undersöka tumavtrycksvärdet för olika certifikat i certifikatarkivet och öppna dess egenskapsfönster.
    5. På fliken Allmänt väljer du Aktivera endast följande syften och avmarkerarServerautentisering.
  5. Starta om SQL Server-tjänsten.

Scenario 4: Klienten och servern använder TLS_DHE chiffersvit för TLS-handskakning, men ett av systemen har inga inledande nollkorrigeringar för TLS_DHE installerat

Mer information om det här scenariot finns i Programupplevelse med tvångsslutna TLS-anslutningsfel vid anslutning av SQL-servrar i Windows.

Obs!

Om den här artikeln inte har löst problemet kan du kontrollera om de vanliga artiklarna om anslutningsproblem kan vara till hjälp.

Scenario 5: TCP Three-Way Timeout för handskakning (SYN-fel, TCP-avvisning) på grund av brist på IOCP-arbetare

I system med höga arbetsbelastningar SQL Server 2017 och tidigare kan du se tillfälliga 10054-fel som orsakas av trevägshandskakningsfel i TCP, vilket leder till TCP-avslag. Rotorsaken till det här problemet kan bero på fördröjningen i bearbetningen av TCPAcceptEx-begäranden. Den här fördröjningen kan bero på brist på IOCP-lyssnare (in-/utdataslutsport) som ansvarar för att hantera godkännandet av inkommande anslutningar. Det otillräckliga antalet IOCP-arbetare och upptagen service av andra begäranden leder till fördröjd bearbetning av anslutningsbegäranden, vilket i slutändan resulterar i handskakningsfel och TCP-avslag. Du kan också se tidsgränser för inloggning under start-SSL-handskakningen (om det finns några) eller bearbetningen av inloggningsbegäranden, vilket inbegriper autentiseringskontroller.

Åtgärd

Brist på IOCP-arbetare och SOS Worker-resurser som allokerats för hantering av autentiserings- och krypteringsåtgärder är den främsta orsaken till TCP-tidsgränser för trevägshandskakning och ytterligare tidsgränser för inloggning. SQL Server 2019 innehåller flera prestandaförbättringar på det här området. En viktig förbättring är implementeringen av en dedikerad pool för inloggningsutskick. Detta optimerar allokeringen av resurser för inloggningsrelaterade uppgifter, vilket minskar förekomsten av timeouter och förbättrar övergripande systemprestanda.

Se även

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.