Dela via

En befintlig anslutning stängdes med två skäl av fjärrvärden (OS-fel 10054)

  • Artikel

Gäller för: SQL Server

Kommentar

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 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å skäl av fjärrvärden.)

Operativsystemfelet 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 kommuniceras 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 inloggning i anslutningsprocessen använder SQL Server och klientprogram TLS-protokollet för att upprätta en säker kanal för överföring av autentiseringsuppgifter.

Följande scenarier beskriver 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årbarheter. 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 grupprincip eller andra mekanismer för att inaktivera dessa osäkra TLS-versioner på olika datorer i din miljö.

Anslutningsfel uppstår när ditt program använder en tidigare version av ODBC-drivrutinen (Open Database Connectivity), OLE DB-providern, .NET Framework-komponenter 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 den TLS-handskakning som krävs för att fortsätta med anslutningen.

Åtgärd

Använd någon av följande metoder för att lösa problemet:

  • Uppgradera DIN SQL Server eller dina klientleverantörer till en version som stöder TLS 1.2. Mer information finns i TLS 1.2-stöd för Microsoft SQL Server.
  • Be systemadministratörerna att tillfälligt aktivera TLS 1.0 eller TLS 1.1 på både klienten och serverdatorerna genom att utföra någon av följande åtgärder:

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-versionerna, chiffersviter kan enkelt granskas i Paketen Client Hello och Server Hello 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 anvisningar 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 matchande algoritmer. Kontakta Microsoft Support om inga matchande algoritmer hittas.

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

Scenario 3: TLS_DHE chiffer kan vara aktiverade

Det här problemet uppstår när klienten eller servern finns i Windows 2012, 2016 och senare versioner. Trots att båda operativsystemversionerna har samma chiffer (TLS_DHE*), hanterar Windows 2012 och 2016+ kryptografinycklar inom TLS på olika sätt. Detta kan leda till kommunikationsfel.

Åtgärd

Lös problemet genom att ta bort alla chiffer 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 Programupplevelse med två tvångsslutna TLS-anslutningsfel vid anslutning av SQL-servrar i Windows.

Scenario 4: SQL Server använder ett certifikat som signerats av en svag hash-algoritm, 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 den 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.

Kommentar

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

Åtgärd

Följ dessa anvisningar för att lösa problemet:

  1. I Konfigurationshanteraren för SQL Server expanderar du SQL Server Network Configuration 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 svag hashalgoritm. 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 Start>Kör och skriv MMC. (MMC kallas även Microsoft Management Console.)
    2. Öppna certifikaten i MMC och välj Datorkonto på snapin-skärmen Certifikat .
    3. Expandera Personligt>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 fönstret Egenskaper .
    5. På fliken Allmänt väljer du Aktivera endast följande syften och avmarkerar Serverautentisering.
  5. Starta om SQL Server-tjänsten.

Scenario 5: 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 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 har löst problemet kan du kontrollera om de vanliga artiklarna om anslutningsproblem kan hjälpa dig.

Scenario 6: TCP-timeout för trevägshandskakning (SYN Fail, TCP Rejection) på grund av brist på IOCP-arbetare

I system med höga arbetsbelastningar på SQL Server 2017 och tidigare kan du observera tillfälliga 10054-fel som orsakas av TCP-trevägshandskakningsfel, vilket leder till TCP-avslag. Rotorsaken till det här problemet kan bero på fördröjningen i bearbetningen TCPAcceptEx av begäranden. Den här fördröjningen kan bero på brist på lyssnare för IOCP (Input/Output Completion Port) 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 någon) eller bearbetningen av inloggningsbegäranden, som omfattar 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änsen 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 distributionspool för inloggning. Detta optimerar allokeringen av resurser för inloggningsrelaterade uppgifter, vilket minskar förekomsten av timeouter och förbättrar den övergripande systemprestandan.

Andra scenarier där TLS-anslutningar misslyckas

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

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.