TCP/IP 연결 문제 해결

아티클
11/19/2024

가상 에이전트 사용해 보기 - 일반적인 Active Directory 복제 문제를 신속하게 식별하고 해결하는 데 도움이 될 수 있습니다.

적용 대상: 지원되는 Windows 클라이언트 및 Windows Server 버전

이 문서에서는 TCP/IP 연결 오류 문제를 해결하기 위한 포괄적인 가이드를 제공합니다.

증상 및 분석

애플리케이션 수준에서 연결 문제가 발생하거나 시간 제한 오류가 발생할 수 있습니다. 다음은 몇 가지 일반적인 시나리오입니다.

데이터베이스 서버에 대한 애플리케이션 연결
SQL 시간 제한 오류
BizTalk 애플리케이션 시간 제한 오류
RDP(원격 데스크톱 프로토콜) 오류
파일 공유 액세스 실패
일반 연결

네트워크 관련 문제가 의심되는 경우 네트워크 패킷 캡처를 수집하는 것이 좋습니다. 이 캡처를 필터링하여 문제가 있는 TCP 연결을 식별하고 오류의 원인을 확인할 수 있습니다.

문제 해결 프로세스 중에 네트워크 캡처에서 TCP RESET이 발생할 수 있으며 이는 네트워크 문제를 나타낼 수 있습니다.

TCP 소개

TCP는 연결 지향적이고 신뢰할 수 있는 프로토콜로 특징지어집니다. 핸드셰이크 프로세스를 통해 안정성을 보장합니다. TCP 세션은 3방향 핸드셰이크로 시작하여 데이터 전송을 시작하고 4방향 닫기로 끝납니다.

발신자와 수신자가 모두 세션을 닫는 데 동의하는 4 방향 폐쇄는 정상적인 폐쇄로 알려져 있습니다. 1로 설정되는 TCP 헤더의 FIN 플래그로 식별됩니다.
4방향 닫기 후 컴퓨터는 포트를 해제하기 전에 4분(기본적으로) 기다립니다. 이를 TIME_WAIT 상태로 간주합니다. 이 TIME_WAIT 상태에서는 TCP 연결에 대해 보류 중인 모든 패킷을 처리할 수 있습니다. TIME_WAIT 상태가 완료되면 연결에 할당된 모든 리소스가 해제됩니다.
TCP 재설정은 갑작스러운 세션 폐쇄로 인해 할당된 리소스가 즉시 해제되고 모든 연결 정보가 삭제됩니다. 이는 1로 설정되는 TCP 헤더의 RESET 플래그로 식별됩니다. 원본 및 대상에서 동시에 수집되는 네트워크 추적을 통해 트래픽 흐름을 확인하고 실패 지점을 식별할 수 있습니다.

다음 섹션에서는 RESET이 발생할 수 있는 시나리오를 간략하게 설명합니다.

네트워크를 통해 패킷 손실

TCP 피어가 응답을 받지 않고 패킷을 보내면 피어는 데이터를 다시 전송합니다. 아직 응답이 없는 경우 세션은 ACK RESET로 끝나며, 이는 애플리케이션이 교환된 데이터를 승인하지만 패킷 손실로 인해 연결을 닫음을 나타냅니다.

원본 및 대상 모두에서 동시 네트워크 추적은 이 동작을 확인할 수 있습니다. 원본 쪽에서 다시 전송된 패킷을 볼 수 있습니다. 대상 쪽에서는 이러한 패킷이 존재하지 않습니다. 이 시나리오는 원본과 대상 간의 네트워크 디바이스가 패킷을 삭제하고 있음을 나타냅니다.

시나리오 1: 초기 TCP 핸드셰이크 중 패킷 손실

패킷 삭제로 인해 초기 TCP 핸드셰이크가 실패하는 경우 TCP SYN 패킷은 기본적으로 세 번 다시 전송됩니다.

참고 항목

TCP SYN 패킷이 다시 전송되는 횟수는 OS에 따라 다를 수 있습니다. 이는 명령을 netsh int tcp show global사용하여 볼 수 있는 TCP 전역 매개 변수의 Max SYN 재전송 값에 따라 결정됩니다.

IP 주소가 10.10.10.1인 원본 컴퓨터가 TCP 포트 445를 통해 IP 주소 10.10.10.2를 사용하여 대상에 연결되고 있다고 가정합니다. 다음은 원본 컴퓨터에서 수집된 네트워크 추적의 스크린샷으로, 대상에서 응답을 받지 않았기 때문에 TCP SYN 패킷이 전송된 후 원본에서 다시 전송되는 초기 TCP 핸드셰이크를 보여 줍니다.

네트워크 모니터의 프레임 요약 스크린샷

대상에서 수집된 네트워크 추적에서 볼 수 있는 동일한 TCP 대화는 위의 패킷이 대상에서 수신되지 않았다는 것을 보여줍니다. 이는 TCP SYN 패킷이 중간 네트워크를 통해 삭제되었음을 의미합니다.

네트워크 모니터에서 필터가 있는 프레임 요약의 스크린샷.

TCP SYN 패킷이 대상에 도달하지만 대상이 응답하지 않는 경우 연결된 TCP 포트가 대상 컴퓨터의 LISTENING 상태에 있는지 확인합니다. 명령 netstat -anob의 출력에서 확인할 수 있습니다.

포트가 수신 대기 중이고 응답이 없는 경우 WFP(Windows 필터링 플랫폼)에서 삭제될 수 있습니다.

시나리오 2: TCP 연결 설정 후 데이터 전송 중 패킷 손실

TCP 연결이 설정된 후 전송된 데이터 패킷이 네트워크를 통해 삭제되는 시나리오에서 TCP는 기본적으로 패킷을 다섯 번 다시 전송합니다.

IP 주소가 192.168.1.62인 원본 컴퓨터가 TCP 포트 445를 통해 IP 주소 192.168.1.2를 갖는 대상 컴퓨터와의 연결을 설정했다고 가정합니다. 원본 컴퓨터가 아래와 같이 5번 다시 전송되는 데이터(SMB 협상 패킷)를 보내고 있습니다. 대상에서 응답이 없으면 원본 컴퓨터가 이 TCP 연결을 닫기 위해 ACK-RST를 보냅니다.

원본 192.168.1.62 쪽 추적:

패킷 쪽 추적을 보여 주는 스크린샷

대상에 도달하는 위의 패킷이 표시되지 않습니다.

내부 네트워크 팀에 참여하여 원본과 대상 간의 서로 다른 홉을 조사하고 홉이 패킷 삭제를 유발할 수 있는지 확인해야 합니다.

TCP 헤더의 잘못된 매개 변수

이 동작은 네트워크의 중간 디바이스가 패킷을 수정하여 수신 끝의 TCP가 패킷을 거부할 때 발생합니다. 예를 들어 TCP 시퀀스 번호가 변경되거나 수정된 TCP 시퀀스 번호가 있는 중간 디바이스에서 패킷을 재생할 수 있습니다.

원본 및 대상의 동시 네트워크 추적은 TCP 헤더에 대한 수정 사항을 식별하는 데 도움이 될 수 있습니다.

먼저 원본 및 대상 추적을 비교하여 패킷의 변경 내용 또는 원본을 대신하여 대상에 도달하는 새 패킷의 존재를 검색합니다.

이러한 경우 대상에 대한 패킷을 수정하거나 재생하는 디바이스를 식별하기 위해 내부 네트워크 팀의 지원을 요청하는 것이 좋습니다. 일반적인 원인으로는 Riverbed 디바이스 또는 WAN 가속기가 있습니다.

애플리케이션 수준 재설정

다시 설정이 패킷 삭제, 잘못된 매개 변수 또는 패킷 수정(네트워크 추적을 통해 식별됨)으로 인한 것이 아니라고 판단한 경우 문제가 애플리케이션 수준 재설정이라고 결론을 내릴 수 있습니다.

애플리케이션 수준 재설정은 다시 설정(R) 플래그와 함께 ACK(승인) 플래그를 1로 설정하는 것이 특징입니다. 이는 서버가 패킷 수신을 승인하지만 어떤 이유로 인해 연결을 수락하지 않음을 나타냅니다. 이 문제는 일반적으로 패킷을 수신하는 애플리케이션이 데이터에서 허용되지 않는 항목을 발견할 때 발생합니다.

아래 스크린샷에서는 원본과 대상의 패킷이 모두 동일하며 수정하거나 삭제하지 않는 것을 확인할 수 있습니다. 그러나 명시적 재설정은 대상에서 원본으로 전송됩니다.

원본 쪽 추적:

네트워크 모니터의 원본 쪽 패킷 스크린샷

대상 쪽 추적:

네트워크 모니터의 대상 쪽 패킷 스크린샷

TCP SYN 패킷이 전송될 때 ACK+RST 플래그가 지정된 TCP 패킷도 발생할 수 있습니다. TCP SYN 패킷은 특정 포트에서 연결을 설정하기 위해 원본 컴퓨터에서 시작됩니다. 그러나 대상 서버가 어떤 이유로든 패킷을 수락하지 않으려는 경우 서버는 ACK+RST 패킷으로 응답합니다.

이러한 경우 연결이 다시 설정되는 이유를 이해하려면 다시 설정(포트 번호로 식별됨)을 발생시키는 애플리케이션을 조사해야 합니다.

참고 항목

위의 정보는 UDP가 아닌 TCP 관점에서 다시 설정과 관련이 있습니다. UDP는 연결 없는 프로토콜이며 패킷이 안정적으로 전송됩니다. 따라서 UDP를 전송 프로토콜로 사용할 때 재전송 또는 재설정이 관찰되지 않습니다. 그러나 UDP는 오류 보고 프로토콜로 ICMP를 사용합니다. UDP 패킷이 대상에 나열되지 않은 포트로 전송되면 대상은 ICMP "대상 호스트에 연결할 수 없음: 포트에 연결할 수 없음" 메시지와 함께 즉시 응답합니다.

10.10.10.1  10.10.10.2  UDP UDP:SrcPort=49875,DstPort=3343
 
10.10.10.2  10.10.10.1  ICMP    ICMP:Destination Unreachable Message, Port Unreachable,10.10.10.2:3343

TCP/IP 연결 문제를 해결하는 동안 네트워크 추적에서 컴퓨터가 패킷을 수신하지만 응답하지 않는 것을 관찰할 수 있습니다. 이는 대상 서버의 네트워크 스택에서 삭제되었음을 나타낼 수 있습니다.

로컬 Windows 방화벽이 패킷을 삭제하는지 확인하려면 다음 명령을 사용하여 컴퓨터에서 WFP(Windows Filtering Platform)에 대한 감사를 사용하도록 설정합니다.

auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable

그런 다음 보안 이벤트 로그를 검토하여 연결된 WFP 필터 ID와 함께 특정 TCP 포트 및 IP 주소의 패킷 삭제를 식별할 수 있습니다.

필터 ID가 있는 이벤트 속성의 스크린샷

다음으로, wfpstate.xml 파일을 생성하는 명령을 netsh wfp show state 실행합니다.

메모장을 사용하여 이 파일을 열고 이벤트 로그에 있는 ID(예: 샘플 이벤트의 2944008)에 대해 필터링할 수 있습니다. 결과는 연결을 차단하는 필터 ID와 연결된 방화벽 규칙 이름을 표시합니다.

연결을 차단하는 필터 ID와 연결된 방화벽 규칙 이름이 포함된 wfpstate xml 파일의 스크린샷

다음을 통해 공유