• 아티클

Networking

원인을 파악하기 힘든 네트워크 문제 추적

Christopher Stoneff

 

한 눈에 보기:

  • 네트워크 문제의 일반적인 원인
  • 밖으로 드러나는 요인 그 이상에 대한 검토
  • 문제 해결 도구가 도움이 되지 않을 때
  • 연결 제한을 구성해야 하는 이유

여러분은 시스템이 다른 시스템과 통신이 되지 않는데 그 이유는 알기 어려운 상황을 여러 번 경험했을 것입니다. 관리 시스템은 라우트된 네트워크의 한 세그먼트에 상주하며 Microsoft Internet Security and Acceleration(ISA) Server

또는 다른 하드웨어 장치 같은 라우터를 통해 다른 네트워크 세그먼트에 연결됩니다. 이 경우 10대나 20대 또는 100대의 시스템을 관리할 때는 아무런 문제가 발생하지 않습니다. 하지만 500대의 시스템을 관리하려고 하면 연결이 이미 열려 있는 컴퓨터를 제외한 네트워크의 다른 컴퓨터와 통신할 수 없게 됩니다. 여러분 자신은 다른 시스템과 통신하거나 인터넷에 연결할 수 없지만 여러분의 시스템이 속한 세그먼트의 다른 사용자를 포함하여 네트워크의 다른 사용자에게는 이러한 문제가 발생하지 않습니다. 이 경우 가장 먼저 어느 부분을 검토해야 할까요?

문제 진단

이러한 상황에서는 대개 관리 소프트웨어에 문제가 있다고 가정합니다. 대부분의 사전 대응적인 관리 도구는 관리자의 시스템에 연결하여 이를 관리하지만 때로는 추적하려고 하는 문제가 이러한 도구 자체로 인해 발생한 것일 수 있습니다. 이는 사전 대응적인 관리 도구가 더 나은 관리를 위해 사용자 장치에 대해 수천 개의 연결을 만들 수 있기 때문입니다. Windows®에서는 연결이 유휴 상태인 경우를 포함하여 연결을 기본적으로 2분 동안 열어 둡니다. 단, 도구, 응용 프로그램 또는 서비스에서 연결을 이보다 길게 유지하는 경우는 예외입니다. 따라서 관리 시스템에서 2분 동안 다른 시스템과 통신하지 않더라도 1,000개 이상의 연결이 열려 있을 수 있습니다. 명령 프롬프트에서 NETSTAT를 실행하면 열려 있는 연결을 볼 수 있습니다. NETSTAT 명령은 시스템의 열려 있거나, 보류 중이거나, 닫히고 있는 모든 연결과 연결의 상태를 보여 줍니다. 상태 메시지에 대한 설명은 RFC 793(tools.ietf.org/html/rfc793)을 참조하십시오.

오작동하는 관리 소프트웨어를 찾아내기 위해 원격 시스템에 연결하는 배치 파일을 만들 수 있습니다. 이 배치 파일을 실행하는 동안 같은 문제가 발생하면 관리 소프트웨어와 해당 스레드에는 문제가 없음을 알 수 있습니다. 다음은 배치 파일에 포함해야 할 내용에 대한 예제입니다.

Net use \\system01\ipc$ Net use \\system02\ipc$ Net use ...

문제의 관리 프로그램이 고유의 네트워킹 및 인증 스택을 구현하는 경우 이것이 원인일 수 있습니다. 하지만 대부분의 관리 패키지와 같이 에이전트가 없는 솔루션에서는 관리 도구가 운영 체제의 네트워킹 및 인증 스택을 사용하여 네트워크 작업을 수행합니다. 배치 파일도 운영 체제의 네트워킹 및 인증 스택을 사용합니다. 따라서 많은 네트워크 연결을 시작하는 배치 파일을 사용했을 때 오류가 발생하지 않는다면 프로그램에서 운영 체제의 네트워킹 및 인증 스택을 사용한 것 때문에 문제가 발생한 것이 아님을 알 수 있습니다.

로그 및 오류 메시지가 도움이 되지 않는 경우

연결이 실패하기 시작할 때 오류 53(네트워크 경로를 찾을 수 없습니다.), 오류 64(네트워크 이름이 삭제되었습니다.), 오류 1203(주어진 네트워크 경로를 사용할 수 있는 네트워크 공급자가 없습니다.) 등의 많은 오류 정보 메시지가 표시되었을 것입니다. 일반적으로 이러한 메시지는 모두 이름 확인 문제를 나타냅니다. 문제는 모든 시스템에서는 이름을 확인하고 동일한 시스템에 연결하는 데 아무런 문제가 없다는 것입니다. 시스템 설정에 문제가 없는지 확인하려는 경우 ipconfig를 실행하여 설정이 올바른지 확인할 수 있습니다.

이 문제가 관리 시스템에 국한된 문제로 보이므로 그 다음으로는 이벤트 로그를 검토해야 합니다. 응용 프로그램 로그는 검색해도 별 소득이 없습니다. 하지만 시스템 로그를 검색하면 최대 연결 수에 도달했음을 알려 주는 이벤트 원본 TCP/IP에서 발생한 경고 이벤트 4226을 찾을 수 있습니다(그림 1 참조).

그림 1 최대 한계에 도달한 TCP 연결

그림 1** 최대 한계에 도달한 TCP 연결 **

Microsoft® Knowledge Base에서 연결 제한에 대해 검색해 보면 완료되지 않은 연결에 대해 적용되는 연결 제한은 있지만 완료된 연결에 대해 적용되는 연결 제한은 없다는 사실을 알 수 있습니다. HKLM\System\CurrentControlSet\Services\TCPIP\Parameters 아래에 있는 다음 레지스트리 항목을 조정하여 앞서 언급한 최대 연결 수 등의 요소를 제어할 수 있습니다. TcpNumConnections는 TCP에서 동시에 열 수 있는 최대 연결 수(기본값은 10)를 설정하는 데 사용됩니다. TCPTimedWaitDelay는 연결이 닫힐 때 연결이 TIME_WAIT 상태에 있는 시간을 설정합니다. 기본 반감기(half-life)는 120초이며 이는 연결이 기본적으로 4분 동안 사용됨을 나타냅니다. 마지막으로, MaxFreeTcbs도 최대 연결 수를 제어하는 데 사용됩니다. 모든 TCP 제어 블록이 사용 중이면 TCPTimedWaitDelay가 아직 만료되지 않았더라도 TCP가 TIME_WAIT 상태인 것으로 표시된 연결을 해제하여 추가 연결을 만들어야 합니다. TCPTimedWaitDelay 값의 범위는 30-300초(0x1E–0x12C)입니다.

이러한 레지스트리를 변경하면 시나리오에 따라 전반적인 성능이 약간 향상될 수도 있습니다. 이러한 제한을 없애도록 TCPIP.sys 파일을 패치하는 방법도 시도해 볼 수 있지만 이 방법을 사용하는 경우 P2P 응용 프로그램에서만 성능이 개선됩니다.

네트워크 캡처

연결 문제를 해결하기 위한 다른 시도가 모두 실패할 경우 관련된 시스템에서 네트워크를 캡처하면 도움이 될 수 있습니다. 필자의 경우 Microsoft 네트워크 모니터(Netmon)를 실행한 결과 관리 도구 및 테스트 스크립트를 통해 얻은 것과 정확히 같은 결과를 보여 주는 캡처가 생성되었습니다. 즉, 모든 것이 순조롭게 작동하다가 오류가 발생했다는 어떠한 징후도 없이 작동하지 않게 되었습니다.

그림 2에서는 처음 n개 시스템 간의 성공적인 통신을 나타내는 Netmon 실행 결과를 보여 줍니다. 이 그림에서는 RPC 요청에 대한 승인을 받고 있습니다. 성공적인 양방향 통신을 나타내는 이러한 결과가 나타나야 합니다.

그림 2 Netmon에 나타난 성공적인 통신

그림 2** Netmon에 나타난 성공적인 통신 **(더 크게 보려면 이미지를 클릭하십시오.)

이제 관리 시스템 및 원격 시스템의 캡처를 검토해야 합니다. 이 캡처에서는 오류 53/1203을 보여 줍니다. 시스템에서 통신이 이루어지지 않으므로 검토할 수 있는 내용이 없습니다. 그림 3의 네트워크 캡처를 보면 관리 시스템에서 IP 주소를 확인하고 포트 445(Microsoft SMB 포트)를 통해 시스템에 연결하려고 시도하지만 응답을 받지 못합니다.

그림 3 응답을 받지 못한, 포트 445를 통해 시스템에 연결하려는 시도

그림 3** 응답을 받지 못한, 포트 445를 통해 시스템에 연결하려는 시도 **(더 크게 보려면 이미지를 클릭하십시오.)

시스템에서 동시에 연결할 수 있는 것보다 많은 스레드가 실행 중일 때 표시되는 오류 메시지는 경우에 따라 다를 수 있습니다. 일부 경우, 이름은 확인되었지만 IP 주소를 찾을 수 없음을 나타내는 오류 53이 원본 시스템에서 표시될 수 있습니다. 이 오류는 DNS가 연결할 수 없는 주소를 제공하고 있음을 나타냅니다. 요청한 이름이나 IP 주소에 대해 응답한 시스템이 없음을 나타내는 오류 1203이 표시될 수도 있습니다. 이 경우 오류 1203은 DNS를 사용할 수 없음을 나타냅니다. nslookup을 실행하면 이 경우에 해당하는지 확인할 수 있습니다.

이때쯤이면 문제를 해결할 수 없다는 절망감이 들 수도 있습니다. 하지만 아직 시도해 볼 만한 옵션이 더 남아 있습니다. 대부분의 사용자는 밖으로 드러나는 문제만 보고 연결 인프라를 검토할 생각은 하지도 않습니다. 사용자 시스템이 네트워크의 나머지 부분에 연결할 수 없는 유일한 시스템이고 이벤트 로그에서는 사용자 시스템에서 허용되는 최대 연결 수에 도달했음을 보여 주므로 이 문제가 본질적으로 아키텍처와는 관련이 없어 보일 수도 있습니다.

관리 솔루션에서 생성한 수천 개의 연결이 동시에 시작되지는 않았더라도 전송 지속 시간과 연결 시간 제한으로 인해 특정 시점에 생각했던 것보다 많은 수의 연결이 열려 있을 수 있습니다. 따라서 네트워크의 다른 곳에 연결되는 시스템도 검토해야 합니다.

설명하면 이렇습니다. 앞에서도 언급했듯이 네트워크 트래픽은 네트워크를 경유할 때 스위치, 라우터 및 방화벽을 통과합니다. 이러한 지점 중 하나(일반적으로 라우터나 방화벽)에서 침입 검색 시스템을 만날 수 있습니다. 관리되는 스위치와 라우터의 경우 트래픽 필터링을 수행할 수도 있습니다. 이러한 장치를 관리하는 사람은 로그에서 오류 메시지나 경고 메시지를 확인해야 합니다. 바로 이러한 시스템 내부에 통신 문제의 원인이 있을 수도 있습니다.

현재는 내부 시스템에서 내부의 다른 시스템으로 연결하는 경우이므로, 해당 장치에 대해 경고가 구성되지 않았거나 문제가 침입 또는 DoS(서비스 거부) 공격으로 분류되지 않아서 경고가 생성되지 않았을 수 있습니다. 다시 한번 강조하지만 로그를 먼저 검토해야 합니다. 예를 들어 ISA Server의 경우 ISA Server 관리 콘솔의 Arrays\<ArrayName>\Monitoring\Logging에서 로그를 찾을 수 있습니다.

사용자를 차단하는 것이 정책이면 ISA Server의 경우 다음 결과 코드를 찾습니다. 여기서 원본 IP는 사용자의 관리 컴퓨터입니다.

  • 0xc0040037 FWX_E_TCP_RATE_QUOTA_EXCEEDED_DROPPED
  • 0xc004000d FWX_E_POLICY_RULES_DENIED
  • 0xc0040017 FWX_E_TXP_SYN_PACKET_DROPPED

이러한 결과 코드가 있으면 연결 문제의 근본 원인을 찾았다고 할 수 있습니다.

해결 방법 구현

문제가 무엇인지 찾아냈으므로 해결 방법은 간단합니다. 하지만 부서 정책에 가로막혀 구현이 어려울 수도 있습니다. 방화벽, 라우터 및/또는 침입 검색 시스템의 보안 구성에 예외를 두는 작업은 누구에게나 허용되는 작업이 아니므로 구성을 변경하려면 먼저 자신에게 적절한 권한이 있는지 확인해야 합니다.

다시 ISA Server의 예를 들면 다음 단계는 지정한 호스트 또는 네트워크의 모든 시스템에 대한 최대 연결 수를 늘리는 방법을 보여 줍니다(그림 4 참조). ISA Server 관리 콘솔을 열고 Arrays\<ArrayName>\Configuration\General\Configure Flood Mitigation Settings로 이동합니다.

그림 4 ISA Server를 사용하여 하나의 호스트 또는 모든 시스템에 대한 최대 연결 수 늘리기

그림 4** ISA Server를 사용하여 하나의 호스트 또는 모든 시스템에 대한 최대 연결 수 늘리기 **

여기서 주목해야 할 두 가지 설정은 IP 주소당 최대 TCP 동시 연결 수, 그리고 각 IP 주소에 대한 분당 최대 TCP 연결 요청 수입니다. IP 주소당 최대 TCP 동시 연결 수는 일반적으로 능동적인 관리 작업이 수행되지 않는 경우 충분하도록 설정됩니다. 즉, 단일 컴퓨터가 짧은 시간에 수천 대의 컴퓨터에 능동적으로 연결하는 상황을 감안하지는 않습니다. ISA Server의 경우 최대 TCP 동시 연결 수에 대한 기본 제한이 160입니다. 각 IP 주소에 대한 분당 최대 TCP 연결 요청 수는 네트워크 손상을 방지하고 네트워크 검사 내용의 표시를 제한하기 위한 것입니다. 기본 제한은 각 IP 주소에 대해 분당 600개의 연결 요청입니다.

앞에서 설명했듯이 다른 서비스나 응용 프로그램에서 연결을 지속하려고 시도하지 않는 한 Windows에서는 연결이 유휴 상태인 경우를 포함하여 기본적으로 2분 동안 연결을 지속합니다. 즉, 컴퓨터에 대한 관리 작업이 성공적으로 완료되었고 더 이상 컴퓨터와 통신할 필요가 없더라도 연결이 활성 상태로 남아 있을 수 있습니다. 이러한 열려 있는 연결 수는 허용되는 총 연결 수에 포함됩니다. 연결을 제거하지 않고 이 프로세스를 160회 이상 반복하면 라우터에서 모든 연결 시도를 거부하는 것을 확인할 수 있습니다. 관리 프로그램에서 적극적으로 세션을 종료하더라도 Windows에서는 대상 시스템이 세션 연결을 끊는 데 동의할 때까지 연결을 time_wait 상태로 둘 수도 있습니다.

문제의 원인일 확률이 가장 높은 IP 주소당 최대 TCP 동시 연결 수부터 조정하십시오. 이 값은 관리 시스템에서 다른 시스템을 관리하는 데 필요한 모든 연결을 설정하더라도 액세스 거부가 발생하지 않는 수준으로 설정해야 합니다. 이 설정 옆의 Edit(편집) 단추를 클릭하고 값을 변경합니다.

다음 메시지(그림 5 참조)에는 모든 클라이언트에 적용되는 기본 제한을 나타내는 Limit(제한) 상자가 있습니다. Custom limit(사용자 지정 제한)은 Flood Mitigation(서비스 장애 완화) 대화 상자의 IP Exceptions(IP 예외) 탭에 정의된 모든 시스템과 네트워크 등에 적용됩니다. 모든 시스템이 추가 연결을 만들 수 있도록 허용하려면 Limit(제한) 값을 변경합니다. 관리 시스템에 대해서만 예외를 설정하려면 Custom limit(사용자 지정 제한) 값을 조정하고 관리자의 시스템을 IP Exceptions(IP 예외) 탭에 추가합니다. 대개는 관리자의 시스템에 대해서만 예외를 허용하는 것이 좋습니다.

그림 5 기본 연결 제한 및 사용자 지정 연결 제한

그림 5** 기본 연결 제한 및 사용자 지정 연결 제한 **

사용자 지정 제한 값을 특정 시스템에 대해서만 변경하려면 Custom limit(사용자 지정 제한) 필드의 값을 변경한 다음 OK(확인)를 클릭합니다. 그런 다음 관리자의 시스템을 Flood Mitigation(서비스 장애 완화) 대화 상자의 IP Exceptions(IP 예외) 탭에 추가합니다. 단일 컴퓨터를 예외 목록에 추가하려면 IP Exceptions(IP 예외) 탭에서 Add(추가)를 클릭하여 Computer Sets(컴퓨터 집합) 대화 상자를 표시합니다. New(새로 만들기)를 클릭하여 관리자 시스템이 포함될 새 네트워크 집합을 만듭니다(없는 경우). 이 네트워크 집합을 선택하고 Add(추가)를 클릭하여 Internal Networks(내부 네트워크) 네트워크 집합에 추가한 다음 Close(닫기)를 클릭합니다. 다시 Internal Networks(내부 네트워크) 네트워크 집합을 선택하고 Edit(편집)을 클릭합니다. 그러면 Internal Networks properties(내부 네트워크 속성)(그림 6 참조) 대화 상자가 열립니다. 이 대화 상자에서 Add(추가)를 클릭하여 컴퓨터, 주소 범위, 서브넷을 추가할 수 있는 하위 메뉴를 표시하고 컴퓨터를 선택합니다. 나중에 이 항목을 검토하는 사람이 관리자의 시스템을 제거하지 않도록 해당 항목을 나타내는 이름, 시스템의 IP 주소 및 설명을 입력합니다(그림 7 참조). OK(확인)를 클릭하여 시스템을 추가하고 다시 OK(확인)를 클릭하여 예외를 추가합니다. 이러한 변경을 모두 수행했으므로 이제 설정을 적용해야 합니다.

그림 6 내부 네트워크 속성 설정

그림 6** 내부 네트워크 속성 설정 **

그림 7 시스템이 제거되지 않도록 컴퓨터 이름, IP 주소, 설명 입력

그림 7** 시스템이 제거되지 않도록 컴퓨터 이름, IP 주소, 설명 입력 **

사전 대응적 관리 도구를 다시 실행해 보십시오. 그러면 성능이 향상되고 연결이 실패하지 않을 것입니다. 적어도 네트워크 트래픽으로 인해 연결이 실패하지는 않을 것입니다. 결국 소프트웨어에서 시작한 연결 수가 아니라 연결 수를 적절히 계획하지 않아서 연결 중단 문제가 발생했음을 알 수 있습니다.

교훈

IT 부서가 겪는 가장 골치 아픈 문제 중 하나가 바로 원인을 파악하기 어려운 문제가 발생할 경우 이를 해결하는 것입니다. 이러한 것들은 최종 사용자가 발생시키거나 서버 팀에서 원인을 제공하거나 지원 부서에서 인식하고 있는 유형의 문제가 아니므로 안타깝게도 관리자가 직접 문제를 해결해야 합니다. 문제를 파악하여 해결하는 데 사용할 수 있는 많은 도구가 있지만 도구만으로는 충분하지 않을 때가 있습니다. 도구로 문제를 올바르게 해결할 수 없을 때도 있고 도구보다 나은 방법이 필요한 경우도 있습니다.

향후에 네트워크의 수많은 시스템 중에서 뚜렷한 이유 없이 자신의 시스템만 연결되지 않는 문제가 발생하면 이 문서에 설명된 단계를 수행해 보십시오. 이러한 단계를 따르면 관리 소프트웨어를 주의 깊게 검토하고 허용되는 연결 수를 적절히 설정하여 문제를 성공적으로 해결할 수 있을 것입니다.

Christopher Stoneff는 Lieberman Software(liebsoft.com)의 제품 관리자이자 보안 및 시스템 관리 소프트웨어 개발자입니다. Chris는 많은 IT 자격증을 소지하고 있으며, 그의 이러한 추진력을 뒷받침하는 가장 큰 힘은 어떤 일이 특정한 방향으로 일어나는 방식뿐만 아니라 그 이유에 대해서까지 알아내고자 하는 열정입니다.

© 2008 Microsoft Corporation 및 CMP Media, LLC. All rights reserved. 이 문서의 전부 또는 일부를 무단으로 복제하는 행위는 금지됩니다..