TCP/IP 통신 문제 해결 지침

이 문서는 TCP/IP 통신 문제를 해결하는 데 도움이 되도록 설계되었습니다.

문제 해결 도구

ping 명령은 기본 연결을 테스트하는 데 유용합니다. 그러나 전반적인 연결을 증명하기 위해 의존해서는 안 됩니다. 텔넷 및 PsPing 은 다음과 같은 이유로 더 유용합니다.

• 이러한 도구는 TCP 또는 UDP(PsPing만 해당)를 전송 프로토콜로 사용하여 애플리케이션 계층에 대한 연결을 테스트할 수 있습니다.
• 사용할 포트를 지정할 수 있습니다. 따라서 방화벽에서 열린 포트를 탐색할 수 있습니다.
• 대상 노드의 "수신 대기" 포트에 연결하여 특정 애플리케이션의 포트에 대한 액세스를 확인할 수 있습니다.

문제 해결 검사 목록

1단계: 네트워크 다이어그램 캡처

영향을 받는 영역의 경로에 있는 디바이스를 자세히 표시하는 네트워크 다이어그램을 캡처합니다. 특히 다음 디바이스에 유의하세요.

• 방화벽
• IPS(침입 방지/방지 시스템)
• DPI(심층 패킷 검사)
• WAN 가속기

이 다이어그램은 문제의 원인을 찾을 위치를 시각화하고 식별하는 데 도움이 될 수 있습니다.

2단계: 네트워킹 추적

네트워킹 추적은 문제가 발생할 때 네트워크 수준에서 발생하는 작업을 확인하는 데 유용합니다.

3단계: 컴퓨터의 로컬 IP 주소 Ping

컴퓨터의 로컬 IP 주소를 ping해 봅니다.

노드가 로컬 IP를 ping할 수 없는 경우 로컬 스택이 작동하지 않습니다. 표시되는 오류 메시지를 확인합니다.

일반 오류 오류가 발생하면 이 오류는 요청을 처리할 유효한 인터페이스가 없음을 의미합니다. 이 문제는 하드웨어 문제 또는 스택 문제로 인해 발생할 수 있습니다.

시스템 트레이의 네트워크 연결 아이콘에 빨간색 "X" 문자 또는 노란색 느낌표가 표시되는지 확인합니다. 빨간색 X는 Windows가 네트워크 연결을 감지하지 못했음을 나타냅니다. 노란색 느낌표는 NSCI(네트워크 연결 상태 표시기)가 프로브 검사 실패했음을 나타냅니다.

이 문제를 해결하려면 네트워크 어댑터가 연결을 보고했는지 확인합니다. 네트워크 어댑터가 연결되어 있고 노드가 연결된 스위치 포트가 오류 상태가 아닌지 확인합니다. 케이블, 스위치 포트 및 네트워크 어댑터를 변경하여 이 문제가 발생하는 위치를 좁힐 수 있습니다. 그러나 궁극적으로 문제는 OS 외부에 있습니다. 자세히 조사하려면 하드웨어 공급업체에 문의하세요.

네트워크 드라이버와 Windows 간에도 문제가 발생할 수 있습니다. 이 문제는 일반적으로 스택의 손상으로 인해 발생합니다. 다음 문제 해결 단계를 사용합니다.

1. 노드의 최신 비트(TCP/IP, NDIS, AFD, Winsock 등)가 있는지 확인합니다.

2. 다음 명령을 실행하여 IP 및 Winsock을 다시 설정합니다. 모든 네트워크 구성을 백업합니다.

   netsh -c interface dump > C:\netConfig.txt
   netsh int ip reset
   netsh winsock reset
   

3. 노드를 다시 시작합니다.

4. 다시 시작한 후 네트워크 설정을 복원합니다. 이 작업은 인터페이스 이름이 변경되지 않았거나 스크립트가 새 이름을 사용하도록 업데이트된 경우에만 작동합니다.

   netsh -f C:\netConfig.txt
   

5. 네트워크 어댑터 드라이버를 적절하게 제거하거나 다시 설치합니다.

6. 타사 필터 드라이버(예: 바이러스 백신)를 확인하고 제거합니다.

7. 네트워킹을 사용하여 안전 모드에서 컴퓨터를 시작합니다. 네트워킹을 사용하는 안전 모드가 작동하는 경우 MSConfig 내의 모든 타사 앱 및 서비스를 사용하지 않도록 설정하여 "클린 부팅" 프로세스를 실행한 다음 문제가 반환될 때까지 하나씩 다시 사용하도록 설정합니다. 그런 다음 공급업체에 지원을 문의할 수 있습니다.

   1. 이러한 항목 중 어느 것도 성공하지 못하면 레지스트리 손상일 수 있습니다.
   2. 레지스트리의 백업 복사본(예: 물리적 백업 또는 시스템 복원 지점)이 있는 경우 노드를 이전에 작업한 구성으로 복원할 수 있습니다. 손상의 근본 원인을 포착하는 것은 어렵고 시간이 많이 걸릴 수 있습니다. 부패가 발견되더라도 그 원인을 아는 것은 훨씬 더 어렵습니다. 손상된 레지스트리 키를 수동으로 수정하면 노드가 지원되지 않는 상태로 전환됩니다. 따라서 고객이 손상을 수정하기 위해 노드를 복원하거나 다시 로드하는 것이 좋습니다.

NSCI가 프로브 검사(노란색 느낌표)에 실패하는 경우 반드시 연결 문제가 있는 것은 아닙니다. 일반적인 통신이 예상대로 발생하는지 확인합니다.

• 그렇다면 조사는 NCSI가 프로브 검사에 실패한 이유에 특히 초점을 맞추어야 합니다. 이에 대한 세부 정보는 별도의 항목에서 다룹니다.
• 그렇지 않은 경우 연결이 복원된 후 수정될 가능성이 높기 때문에 먼저 연결 문제를 조사합니다.

4단계: ping 또는 텔넷 테스트 중에 발생하는 오류 메시지 문제 해결

노드가 동일한 서브넷 또는 네트워크 세그먼트의 노드에 ping 또는 텔넷을 사용할 수 있는 경우 외부 연결이 작동하는지 확인합니다. 기본 연결 문제가 있는지 여부를 이해하려면 추가 테스트가 여전히 필요합니다.

노드가 동일한 서브넷/네트워크 세그먼트의 노드에 ping/telnet을 사용할 수 없는 경우 표시되는 오류 메시지를 확인합니다.

1. 대상 호스트에 연결할 수 없는 오류는 노드에서 보낸 ARP 요청이 응답을 받지 못한다는 것을 의미합니다.

2. 테스트하는 노드에서 양면 추적을 수집합니다. 원본 노드에서 보낸 ARP 요청이 대상 노드에 도달하고 대상 노드가 그에 따라 회신하는지 확인합니다. 이 회신은 원본 추적에서 다시 표시되어야 합니다. 이 프로세스가 실패하면 문제가 잘못 구성되거나 인프라에 영향을 주는 기타 문제일 수 있습니다.

   가능한 원인은 다음과 같습니다.

   1. 잘못되었거나 일치하지 않는 VLAN입니다.
   2. 잘못된 스위치 포트 구성(트렁크 및 액세스 포트).
   3. 기타 하드웨어 문제.

3. 요청 시간 초과 오류는 ARP 요청에 응답이 있지만 노드에서 보낸 ICMP Echo 요청이 ICMP 에코 응답을 받지 못함을 의미합니다. 이것만으로 문제가 표시되지는 않습니다. ICMP 트래픽은 노드의 네트워크 또는 방화벽 소프트웨어에 의해 차단될 수 있습니다. 방화벽 프로필(Windows)을 끄거나 ICMP를 테스트하기 위해 방화벽 공급업체의 지원되는 방법을 통해 사용하지 않도록 설정하는 것이 유용할 수 있습니다.

   1. 텔넷 및 PsPing은 테스트에 더 적합합니다. 원본 노드에서 수신 대기 포트의 대상 노드(예: 445)로 텔넷 또는 PsPing을 실행합니다.
   2. 1단계가 성공하면 외부 연결이 작동합니다. 기본 연결을 계속 테스트합니다.
   3. 1단계가 성공하지 못하고 방화벽 프로필이 비활성화된 경우 양면 netsh netconnection 시나리오 추적을 수집하여 추가 문제를 해결합니다.

5단계: 기본 게이트웨이에 대한 Ping 또는 텔넷

노드가 기본 게이트웨이를 ping할 수 있는 경우 원본 노드에서 외부 연결(예: 오프박스 연결)이 가능합니다. 기본 연결 문제가 있는지 여부를 이해하려면 추가 테스트가 여전히 필요합니다. 노드가 기본 게이트웨이에 ping 또는 Telnet을 사용할 수 없는 경우 이는 라우터에서 ICMP 회신을 사용하지 않도록 설정됨을 의미합니다.

6단계: 특정 대상 노드에 영향을 주는 문제 확인

원본 노드가 대상 서브넷의 다른 노드에 ping, Telnet 또는 PsPing을 수행할 수 있는 경우 인프라 내의 기본 연결 및 라우팅이 작동합니다. 이 결과는 특정 대상 노드에 영향을 주는 문제를 가리킵니다.

1. 애플리케이션이 수신 대기 중인 특정 포트(예: SMB용 TCP 포트 445)로 텔넷 또는 PsPing을 시도합니다. 연결에 성공하면 기본 애플리케이션 수준 연결을 확인할 수 있습니다. 이 경우 애플리케이션이 연결되지 않는 이유를 조사하기 위해 애플리케이션 공급업체에 문의해야 합니다.

   참고

   예를 들어 공유에 연결하지 못하는 경우 애플리케이션 공급업체는 Microsoft일 수 있습니다. 이러한 상황에서는 양면 netsh netconnection 시나리오 추적을 수행하여 추가 정보를 수집하고 네트워킹 스택에 문제가 없는지 확인하는 데 도움이 됩니다.

2. 특정 포트에 대한 연결이 성공하지 못한 경우:

   1. 포트가 '수신 대기' 상태인지 확인합니다.
      Cmd: netstat -nato | findstr :<port>
      Powershell: Get-NetTcpConnection -LocalPort <port>
   2. 모든 방화벽 프로필을 일시적으로 사용하지 않도록 설정합니다. (참고: 프로필만 사용하지 않도록 설정합니다. 서비스를 사용하지 않도록 설정하지 마세요.)
      성공하면 특정 포트에서 애플리케이션 트래픽을 허용하도록 방화벽을 다시 구성해야 합니다.
   3. 타사 애플리케이션을 한 번에 하나씩 제거하고 각 제거 간에 테스트합니다.
      성공하면 문제가 있는 소프트웨어 공급업체에 문의하세요.
   4. 네트워킹을 사용하여 안전 모드를 사용해 보세요.
      이 작업이 성공하면 MSConfig를 사용하여 노드의 "클린 부팅"을 실행한 다음 문제가 다시 발생할 때까지 타사 애플리케이션 및 서비스를 하나씩 사용하도록 설정하여 원인을 격리합니다.
   5. 연결 시도를 재현할 때 원본에서 영향을 받는 대상 노드로 netsh netconnection 시나리오 추적을 실행해야 합니다. 네트워킹 SDP도 유용합니다.

3. 노드가 대상 서브넷의 다른 노드에 ping, Telnet 또는 PsPing을 수행할 수 없는 경우 인프라 관련 문제일 수 있습니다. 다시 말하지만, 환경 내에서 ICMP를 차단할 수 있습니다. 따라서 텔넷 또는 PsPing을 사용하여 알려진 수신 대기 포트에 연결하여 연결을 확인합니다. 이 시점에서 네트워크에서 패킷 손실이 발생하는 위치를 표시하려면 양면 네트워크 추적이 필요합니다. 문제가 캡처되도록 연결 테스트를 시도하기 전에 두 추적이 모두 실행되고 있는지 확인합니다.

일반적인 문제 및 해결 방법

호스트에 대한 TCP/IP 연결이 중지된 것으로 보입니다.

이 문제는 TCP 및 UDP 큐에서 데이터가 차단되거나 네트워크 또는 사용자 수준 소프트웨어 지연 문제가 있기 때문에 발생합니다.

이 문제를 해결하려면 명령을 사용하여 netstat -a 로컬 컴퓨터의 TCP 및 UDP 포트에서 모든 작업의 상태 표시합니다.
송신 및 수신 큐에 0바이트가 있는 동안 양호한 TCP 연결 상태가 설정됩니다. 큐에서 데이터가 차단되거나 상태가 불규칙한 경우 연결에 오류가 발생할 수 있습니다. 그렇지 않은 경우 네트워크 또는 사용자 수준 소프트웨어 지연이 발생할 수 있습니다.

이름 확인을 위해 Lmhosts를 사용하는 경우 긴 연결 시간

이 문제는 Lmhosts 파일이 순차적으로 구문 분석되어 #PRE 옵션 없이 항목을 찾기 때문에 발생합니다.

이 문제를 해결하려면 자주 사용하는 항목을 파일 맨 위에 배치하고 아래쪽에 #PRE 항목을 배치합니다. 항목이 큰 Lmhosts 파일의 끝에 추가된 경우 #PRE 옵션을 사용하여 Lmhosts의 항목을 미리 로드된 항목으로 표시합니다. 그런 다음 명령을 실행 nbtstat -R 하여 로컬 이름 캐시를 즉시 업데이트합니다.

시스템 오류 53이 발생했습니다.

명령을 사용할 때 특정 컴퓨터 이름에 대한 이름 확인이 실패하면 시스템 오류 53이 net use 반환됩니다.

컴퓨터가 로컬 서브넷에 있는 경우 이름이 올바르게 철자되었는지, 대상 컴퓨터도 TCP/IP를 실행하고 있는지 확인합니다. 컴퓨터가 로컬 서브넷에 없는 경우 Lmhosts 파일 또는 WINS 데이터베이스에서 해당 이름 및 IP 주소 매핑을 사용할 수 있는지 확인합니다. 모든 TCP/IP 요소가 제대로 설치되어 있는 것처럼 보이는 경우 원격 컴퓨터와 함께 명령을 사용하여 ping TCP/IP 소프트웨어가 작동하는지 확인합니다.

특정 서버에 연결할 수 없음

이 문제는 NetBIOS 이름 확인이 이름을 확인하지 않거나 잘못된 IP 주소가 해결되고 있기 때문에 발생합니다.

이 문제를 해결하려면 서버의 nbtstat -n 명령을 사용하여 네트워크에 등록된 서버 이름을 확인합니다. 연결하려는 컴퓨터의 컴퓨터 이름은 표시된 목록에 있어야 합니다. 이름이 나열되지 않은 경우 에 표시되는 nbtstat다른 고유한 컴퓨터 이름 중 하나를 사용해 보세요. 원격 컴퓨터에서 사용하는 이름이 명령에 표시되는 nbtstat -n 이름과 동일한 경우 원격 컴퓨터에 WINS 서버 또는 해당 Lmhosts 파일에 있는 서버 이름에 대한 항목이 있는지 확인합니다.

기본 게이트웨이를 추가할 수 없음

이 문제는 기본 게이트웨이의 IP 주소가 IP 주소와 동일한 IP 네트워크 ID에 있지 않기 때문에 발생합니다.

이 문제를 해결하려면 기본 게이트웨이의 IP 주소를 컴퓨터의 네트워크 어댑터의 네트워크 ID와 비교하여 기본 게이트웨이가 컴퓨터의 네트워크 어댑터와 동일한 논리 네트워크에 있는지 확인합니다.

예를 들어 컴퓨터에는 IP 주소가 192.168.0.33이고 서브넷 마스크가 255.255.0.0인 단일 네트워크 어댑터가 있습니다. 이렇게 하려면 기본 게이트웨이가 "192.168" 형식이어야 합니다.<y>.<ip 인터페이스의 네트워크 ID 부분이 192.168.0.0이기 때문에 z>"

데이터 수집

Microsoft 지원에 문의하기 전에 문제에 대한 정보를 수집할 수 있습니다.

필수 구성 요소

1. TSS는 로컬 시스템에 대한 관리자 권한이 있는 계정에서 실행해야 하며 EULA를 수락해야 합니다(EULA가 수락되면 TSS는 다시 메시지를 표시하지 않음).
2. 로컬 컴퓨터 RemoteSigned PowerShell 실행 정책을 사용하는 것이 좋습니다.

Microsoft 지원에 문의하기 전에 주요 정보 수집

1. 모든 노드에서 TSS 를 다운로드하고 C:\tss 폴더에서 압축을 풉니다.

2. 관리자 권한 PowerShell 명령 프롬프트에서 C:\tss 폴더를 엽니다.

3. 다음 cmdlet을 사용하여 원본 및 대상 서버에서 추적을 시작합니다.

   TSS.ps1 -Scenario NET_General
   

4. 원본 또는 대상 서버에서 추적이 처음으로 실행되는 경우 EULA를 수락합니다.

5. 녹화 허용(PSR 또는 비디오).

6. Y를 입력하기 전에 문제를 재현 합니다.

   참고

   클라이언트와 서버 모두에서 로그를 수집하는 경우 문제를 재현하기 전에 두 노드에서 이 메시지를 기다립니다.

7. 문제가 재현된 후 로그 수집을 완료하려면 Y 를 입력합니다.

추적은 분석을 위해 작업 영역에 업로드할 수 있는 C:\MS_DATA 폴더의 zip 파일에 저장됩니다.

참조

• TCP/IP 연결 문제 해결
• 포트 소모 문제 해결
• RPC(원격 프로시저 호출) 오류 문제 해결
• 네트워크 모니터를 사용하여 데이터 수집
• 네트워크 어댑터의 TCP/IP 속성을 열지 못했습니다.
• TCP/IP를 통해 직접 호스트 SMB
• NetBIOS가 꺼져 있는 동안 TCP/IP 네트워킹 구성
• TCP 트래픽 중지
• TCP/IP에 대한 기본 동적 포트 범위가 변경되었습니다.
• 기본 설정으로 되돌리기 TCP/IP 속성