다음을 통해 공유

기존 연결이 원격 호스트에 의해 강제로 닫혔습니다(OS 오류 10054)

  • 아티클

적용 대상: SQL Server

참고

문제 해결을 시작하기 전에 전제조건을 확인하고 체크리스트를 검토하는 것이 좋습니다.

이 문서에서는 다양한 시나리오에 대해 자세히 설명하며 다음 오류에 대한 해결을 제공합니다.

  • 서버와 연결이 성공적으로 설정되었지만 로그인 프로세스 중에 오류가 발생했습니다. (공급자: SSL 공급자, 오류: 0 - 기존 연결이 원격 호스트에 의해 강제로 닫혔습니다.)

  • 서버와의 연결이 성공적으로 설정되었지만 사전 로그인 핸드셰이크 중에 오류가 발생했습니다. (공급자: TCP 공급자, 오류: 0 - 기존 연결이 원격 호스트에 의해 강제로 닫혔습니다.)

운영 체제 오류 10054가 Windows 소켓 계층에서 발생합니다. 자세한 내용은 Windows 소켓 오류 코드: WSAECONNRESET 10054를 참조하세요.

오류가 언제 표시되나요?

보안 채널( Schannel이라고도 함)은 SSP( 보안 지원 공급자 )입니다. 여기에는 암호화를 통해 ID 인증 및 보안 프라이빗 통신을 제공하는 보안 프로토콜 집합이 포함되어 있습니다. Schannel SSP의 한 가지 기능은 다른 버전의 TLS(전송 계층 보안) 프로토콜을 구현하는 것입니다. 이 프로토콜은 인터넷을 통해 전달되는 정보의 개인 정보를 보호하도록 설계된 업계 표준입니다.

TLS 핸드셰이크 프로토콜은 TCP를 통해 통신하는 두 애플리케이션 간에 보안 세션을 설정하거나 다시 시작하는 데 필요한 키 교환을 담당합니다. 연결 프로세스의 사전 로그인 단계에서 SQL Server 및 클라이언트 애플리케이션은 TLS 프로토콜을 사용하여 자격 증명을 전송하기 위한 보안 채널을 설정합니다.

다음 시나리오에서는 핸드셰이크를 완료할 수 없을 때 발생하는 오류를 자세히 설명합니다.

시나리오 1: 클라이언트와 서버 간에 일치하는 TLS 프로토콜이 없음

SSL(Secure Socket Layer) 및 TLS 1.2 이전 버전의 TLS에는 몇 가지 알려진 취약성이 있습니다. 가능한 경우 TLS 1.2로 업그레이드하고 이전 버전을 사용하지 않도록 설정하는 것이 좋습니다. 따라서 시스템 관리자는 그룹 정책 또는 기타 메커니즘을 통해 업데이트를 푸시하여 환경 내의 다양한 컴퓨터에서 이러한 안전하지 않은 TLS 버전을 사용하지 않도록 설정할 수 있습니다.

애플리케이션이 이전 버전의 ODBC(Open Database Connectivity) 드라이버, OLE DB 공급자, .NET Framework 구성 요소 또는 TLS 1.2를 지원하지 않는 SQL Server 버전을 사용하는 경우 연결 오류가 발생합니다. 서버와 클라이언트가 일치하는 프로토콜(예: TLS 1.0 또는 TLS 1.1)을 찾을 수 없기 때문에 문제가 발생합니다. 연결을 진행하는 데 필요한 TLS 핸드셰이크를 완료하려면 일치하는 프로토콜이 필요합니다.

해결 방법

이 문제를 해결하려면 다음 방법 중 하나를 사용하십시오.

시나리오 2: 클라이언트 및 서버에서 TLS 프로토콜 일치하지만 일치하는 TLS 암호화 도구 모음은 없음

이 시나리오는 사용자 또는 관리자가 추가 보안을 위해 클라이언트 또는 서버에서 특정 알고리즘을 제한할 때 발생합니다.

클라이언트 및 서버 TLS 버전, 암호 제품군은 네트워크 추적의 클라이언트 Hello 및 서버 Hello 패킷에서 쉽게 검사할 수 있습니다. 클라이언트 Hello 패킷은 모든 클라이언트 암호 그룹을 보급하고 서버 Hello 패킷은 그 중 하나를 지정합니다. 일치하는 제품군이 없는 경우 서버는 서버 Hello 패킷에 응답하는 대신 연결을 닫습니다.

해결 방법

문제를 검사 다음 단계를 수행합니다.

  1. 네트워크 추적을 사용할 수 없는 경우 이 레지스트리 키 아래에 함수 값을 검사.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002

    다음 PowerShell 명령을 사용하여 TLS 함수를 찾습니다.

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

  2. IIS 암호화 도구의 암호 그룹 탭을 사용하여 일치하는 알고리즘이 있는지 여부를 검사. 일치하는 알고리즘을 찾을 수 없으면 Microsoft 지원 문의하세요.

자세한 내용은 연결하거나 다시 시작하려고 할 때 TLS 1.2 업그레이드 워크플로 및 TLS(전송 계층 보안) 연결이 실패하거나 시간 제한을 참조하세요.

시나리오 3: TLS_DHE 암호화를 사용하도록 설정할 수 있습니다.

이 문제는 클라이언트 또는 서버가 Windows 2012, 2016 이상 버전에서 호스트되는 경우에 발생합니다. 두 OS 버전 모두 동일한 암호(TLS_DHE*)를 보유하고 있음에도 불구하고 Windows 2012 및 2016+는 TLS 내에서 암호화 키를 다르게 처리합니다. 이로 인해 통신 오류가 발생할 수 있습니다.

해결 방법

이 문제를 resolve 로컬 정책에서 "TLS_DHE*"로 시작하는 모든 암호화를 제거합니다. 애플리케이션이 Windows의 SQL Server 연결하려고 할 때 발생하는 오류에 대한 자세한 내용은 Windows에서 SQL Server를 연결할 때 애플리케이션 환경이 TLS 연결 오류를 강제로 닫는 경우를 참조하세요.

시나리오 4: SQL Server MD5, SHA224 또는 SHA512와 같은 약한 해시 알고리즘으로 서명된 인증서를 사용합니다.

SQL Server 항상 로그인과 관련된 네트워크 패킷을 암호화합니다. 이를 위해 수동으로 프로비전된 인증서 또는 자체 서명된 인증서를 사용합니다. SQL Server 인증서 저장소에서 서버 인증 기능을 지원하는 인증서를 찾으면 인증서를 사용합니다. SQL Server 수동으로 프로비전되지 않은 경우에도 이 인증서를 사용합니다. 이러한 인증서가 MD5, SHA224 또는 SHA512와 같은 약한 해시 알고리즘(지문 알고리즘)을 사용하는 경우 TLS 1.2에서 작동하지 않으며 앞에서 언급한 오류가 발생합니다.

참고

자체 서명된 인증서는 이 문제의 영향을 받지 않습니다.

해결 방법

이 문제를 해결하려면 다음 단계를 따릅니다.

  1. SQL Server 구성 관리자콘솔 창에서 SQL Server 네트워크 구성을 확장합니다.
  2. instance 이름>에 대한 프로토콜을 <선택합니다.
  3. 인증서 탭을 선택하고 관련 단계를 따릅니다.
    • 인증서가 표시되는 경우 보기를 선택하여 지문 알고리즘을 검사하여 약한 해시 알고리즘을 사용하고 있는지 확인합니다. 그런 다음 지우 기를 선택하고 4단계로 이동합니다.
    • 인증서가 표시되지 않으면 다음과 유사한 항목에 대한 SQL Server 오류 로그를 검토하고 해시 또는 지문 값을 적어 둡니다.
      2017-05-30 14:59:30.89 spid15s The certificate [Cert Hash(sha1) "B3029394BB92AA8EDA0B8E37BAD09345B4992E3D"] was successfully loaded for encryption
  4. 다음 단계를 사용하여 서버 인증을 제거합니다.
    1. 실행 시작을> 선택하고 MMC를 입력합니다. (MMC는 Microsoft 관리 콘솔이라고도 합니다.)
    2. MMC에서 인증서를 열고 인증서 스냅인 화면에서 컴퓨터 계정을 선택합니다.
    3. 개인>인증서를 확장합니다.
    4. SQL Server 이름을 사용하거나 인증서 저장소에서 다른 인증서의 지문 값을 검사하여 사용하는 인증서를 찾아 속성 창을 엽니다.
    5. 일반 탭에서 다음 용도만 사용을 선택하고 서버 인증을 선택 취소합니다.
  5. SQL Server 서비스를 다시 시작합니다.

시나리오 5: 클라이언트와 서버는 TLS 핸드셰이크에 TLS_DHE 암호 그룹을 사용하지만 시스템 중 하나에 설치된 TLS_DHE 대한 주요 0 수정 사항이 없습니다.

이 시나리오에 대한 자세한 내용은 Windows에서 SQL Server를 연결할 때 애플리케이션 환경이 TLS 연결 오류를 강제로 닫힘을 참조하세요.

참고

이 문서에서 문제를 해결하지 못한 경우 일반적인 연결 문제 문서가 도움이 될 수 있는지 검사 수 있습니다.

시나리오 6: IOCP 작업자 부족으로 인한 TCP Three-Way 핸드셰이크 시간 제한(SYN 실패, TCP 거부)

SQL Server 2017 및 이전 버전의 워크로드가 많은 시스템에서는 TCP 3방향 핸드셰이크 오류로 인해 일시적인 10054 오류가 발생하여 TCP가 거부될 수 있습니다. 이 문제의 근본 원인은 요청 처리 TCPAcceptEx 가 지연될 수 있습니다. 이 지연은 들어오는 연결의 수락을 관리하는 IOCP(입력/출력 완료 포트) 수신기 작업자의 부족으로 인해 발생할 수 있습니다. IOCP 작업자 수가 부족하고 다른 요청을 처리하는 데 바쁜 경우 연결 요청 처리가 지연되어 결국 핸드셰이크 실패 및 TCP 거부가 발생합니다. SSL 핸드셰이크 시작(있는 경우) 또는 인증 검사와 관련된 로그인 요청 처리 중에 로그인 시간 제한이 관찰할 수도 있습니다.

해결 방법

인증 및 암호화 작업을 처리하는 데 할당된 IOCP 작업자 및 SOS 작업자 리소스의 부족은 TCP 3방향 핸드셰이크 시간 제한 및 추가 로그인 시간 제한의 기본 원인입니다. SQL Server 2019에는 이 영역의 몇 가지 성능 향상이 포함되어 있습니다. 한 가지 주목할 만한 향상된 기능은 전용 로그인 디스패처 풀의 구현입니다. 이렇게 하면 로그인 관련 작업에 대한 리소스 할당이 최적화되어 시간 제한 발생이 줄어들고 전체 시스템 성능이 향상됩니다.

TLS 연결이 실패하는 기타 시나리오

발생한 오류 메시지가 이전 시나리오와 일치하지 않는 경우 다음 추가 시나리오를 참조하세요.

참고 항목

타사 정보 고지 사항

이 문서에 나와 있는 다른 공급업체 제품은 Microsoft와 무관한 회사에서 제조한 것입니다. Microsoft는 이들 제품의 성능이나 안정성에 관하여 명시적이든 묵시적이든 어떠한 보증도 하지 않습니다.