Microsoft/Windows Server 2003

About RPC

장성한군사 2008. 7. 26. 00:45

안녕하세요~ 이번 포스트는 RPC에 대해서 몇자 끄적여 보려구 합니다. RPC는 Windows 운영체제에서 매우 중요한 프로토콜입니다만, 웹 서비스다 뭐다 해서 점차로 관심을 잃어 가고 있습니다. 하지만 시스템 개발을 하다보면 이 RPC와 연관된 문제에 자주 부닥치곤 합니다. 기계적으로 암기하여 문제를 해결하는 것 보다는 원리를 알면 좋을 것 같아서 RPC에서 꼭 필요한 부분만을 설명해 봅니다. RPC 프로그래밍은 C/C++를 요구하는 만큼 좀 빡신 관계로 RPC 프로그래밍에 대한 이야기는 하지 않습니다. About RPC... (1) RPC 에 대해서 한두 번쯤은 들어보았을 것이다. 이 RPC는 한 때 인터넷을 마비시켰던 모 바이러스 덕에 더 유명해진 용어(?)이다. RPC란 Remote Procedure Call 의 약자로서 원격 컴퓨터나 프로세스에 존재하는 함수를 호출하는데 사용하는 프로토콜 이름이다. 원래 RPC는 DCE 란 회사에서 만들어낸 프로토콜로서 마이크로소프트는 Windows NT 시절부터 지금까지, 그리고 앞으로 나올 64비트 운영체제까지 RPC를 주요 프로토콜로서 사용할 것이다. 왜 뜬금 없이 RPC 냐고? 아마 이 RPC에 관련된 프로그램을 작성할 기회는 매우, 극히, 아주, 정말로, 적을 것이다. 하지만 RPC에 관심을 안가질 수 없는 이유가 있다. 이제부터 RPC에 대한 썰을 좀 풀어보도록 하겠다. 즐~ RPC는 동일 컴퓨터 상의 다른 프로세스나 다른 컴퓨터 상의 프로세스의 함수(C 수준의 함수, 프로시저나 함수나 그게 그거다... 따지지 말자...)를 호출하는데 사용하는 프로토콜이다. 달랑 소켓(socket) 만을 이용하여도 가능하지만 다양한 기능을 제공하는 RPC 덕에 손쉽게 다른 컴퓨터와의 통신을 마치 로컬 함수를 호출하듯이 할 수 있다는 것이다. RPC는 다양한 곳에서 사용되고 있다. Windows 인증, MSMQ, Exchange Server, SMS Server, DCOM, DTC (Distributed Transaction Coordinator) 등등 이루 열거하기도 힘들 많큼 많은 Windows 운영체제 서비스와 독립 서버 제품군에서 RPC를 사용하고 있다. 다른 것은 다 개 무시하고... DTC 가 RPC를 사용한다는 점에 오늘은 주목해 보자. DTC라 함은 분산 트랜잭션을 관장하는 마이크로소프트의 TM (Transaction Manager) 이자 COM+를 이용하여 SQL Server와 트랜잭션을 사용하려 치면 반드시 사용해야 하는 중요한 서비스이다. 그런데 이 녀석이 사용하는 프로토콜이 RPC 라는 것이다. 또한 DCOM 역시 원격 COM+ 객체를 호출할 때 사용되는 분산 객체 프로토콜 아닌가? 닷넷이 대세인 지금이야 찬밥신세지만 여전히 DCOM은 알게 모르게 아주 많이 사용되고 있다는 점을 간과하지 않는다면, 이 DCOM의 하부에서 작동하는 RPC에 눈길 한번 안 줄래야 안줄 수가 없는 것이다. 게다가 요즘 심심치 않게 필자에게 들어오는 질문은 COM+를 사용하는데 SQL Server와 트랜잭션이 안 된다는 것이다. Windows 2003 서버에 COM+ 컴포넌트를 작성하고(닷넷이건 아니건 상관없이) 또 다른 Windows 2003 서버에 SQL Server를 두었는데... 트랜잭션 속성을 Required 로 하면 오류가 발생한다는 것이다. 이러한 오류의 99%는 두 서버 사이의 DTC 통신상의 문제이며 이는 곧 RPC 통신이 제대로 안되기 때문인 경우인 것이다. 지금까지 필자의 썰로 RPC를 소 닭보듯이 쳐다만 볼 것이 아니라는 것임을 동의 했다면 이 글을 계속 읽어 갈 것이고... 그렇지 않다면 남는 시간에 싸이질을 하거나 다른 유용한 작업을 하기 바란다... RPC Endpoint Mapper & Dynamic Binding RPC는 원격 호출에 사용되는 프로토콜임에도 불구하고 구체적인 네트워크 전송은 다양한 하부 프로토콜 중 하나를 사용하도록 유연하게 설계되어 있다. 따라서 RPC의 전송 프로토콜(transmit protocol)로서 TCP/IP, IPX, Named Pipe 등을 사용할 수 있다. 물론 이들 중 TCP/IP가 가장 많이 사용되며 RPC의 프로토콜 우선 순위 중 가장 첫번째 설정임은 두말하면 입 아프다 (실제로 Windows NT 에서는 Named Pipe가 최 우선이였지만 Windows 2000 부터는 TCP/IP가 가장 우선되는 프로토콜이 되었다). RPC 호출을 수행하기 위해서는 RPC 서버가 존재하는 네트워크 주소(network address)와 종점(end point)을 알아야 한다. 이 네트워크 주소와 종점은 RPC의 전송 프로토콜이 뭐냐에 따라 달라짐은 당연 빤스 되겠다. 다른 프로토콜 이야기를 하면 입만 아파지므로(사실 잘 알지도 못하며 알고 싶은 욕망도 읍따...) TCP/IP 이야기만 하는 것이 좋을 듯하다. TCP/IP 에서 네트워크 주소는 당연 IP 주소일 것이고 종점이라는 것은 IP 포트가 되겠다. 소켓 프로그램을 해본 사람은 감이 팍 올 것이며, 그렇지 않은 사람이라도 웹이 80 번 포트를 쓴다는 것을 알 터이니, 그 80 번 포트를 종점으로 이해하문 되긋다. RPC의 특징은 이 end point 를 가변으로 설정할 수 있다는 것이다. HTTP가 80번 포트라는 고정 포트를 사용하는 반면 RPC는 end point을 구체적으로 명시하지 않을 수 있고, RPC 런타임이 이 end point를 선택할 수 있다는 것이다. 포트라는 것이 HTTP, FTP, TELNET 과 같이 유명한 포트가 아닌 다음에야 임의의 포트를 썼다가 다른 프로그램과 쫑날 수도 있기 때문에 RPC는 사용하지 않는 포트 중 하나를 임의로 사용할 수 있도록 해주는 것이다. 참으로 친절한 RPC 런타임이 아닐 수 없다. 한가지 문제는 클라이언트가 서버의 포트를 어떻게 알아내는 가가 문제이다. RPC 서버가 시작될 때 사용 중이지 않은 임의의 포트가 할당되기 때문에 서버가 재 시작되어 버리면 예전의 포트를 다시 사용하리라는 보장이 전혀 없기 때문이다. 이 때문에 RPC는 RPC 포트 매퍼 서비스란 것을 제공한다. << RPC 포트 매퍼 서비스 >> RPC 포트 매퍼란 녀석이 오늘의 뽀인뜨이자 하이라이트가 되겠다. RPC 클라이언트는 서버가 사용하는 종점(IP 포트)가 무엇인가 알아내기 위한 작업을 한다. 이때 클라이언트는 RPC 서버 바인딩 정보(네트워크 주소, 종점, 인터페이스 등으로 구성된 접속 정보 정도로 생각하자)에서 종점이 주어지지 않으면 서버 컴퓨터의 포트 매퍼에 접속하여 RPC 서버가 사용하는 종점정보를 물어본다. 여기서 주의할 점은 RPC 클라이언트가 종점 매퍼에 '접속'한다는 말이다. 이 말은 종점 매퍼 역시 RPC 클라이언트와 네트워크 접속을 해야 한다는 말이며 사용하는 TCP/IP 포트가 있다는 말인 것이다. RPC 종점 매퍼가 사용하는 IP 포트는 135번이다. 이는 RPC 기반의 서비스들(앞서 나열했던 DTC, DCOM, MSMQ 등)을 사용하기 위해서는 RPC 서버가 사용하는 포트 이외에 포트 매퍼가 사용하는 135번 포트 역시 사용됨을 알 수 있다. Test 말로만 하면 도무지 믿질 않으니 테스트를 수행해 보자. 내가 한 C/C++ 한다는 사람들은 MSDN 의 자료와 PlatformSDK 에 포함된 RPC 예제 코드를 컴파일 해서 수행시켜보면 한눈에 알 수 있을 것이다. 하지만 이런 귀차니즘을 모두 벗어 버리고, 관심 대상인 DTC를 가지고 간단한 테스트를 해보자. 먼저 TcpView 를 다운로드 받아라. 이 프로그램은 어떤 프로세스가 어떤 TCP 포트를 사용하며, 현재의 상태가 어떤지 보여주는 멋진 유틸리티이다. TcpView 를 수행해 보면 다음과 같은 화면을 볼 수 있다. << TCPView로 살펴본 필자의 컴퓨터 TCP/IP 상태 >> 다른 것은 무시하고 강조된 두 항목을 살펴보자. 프로세스 ID가 1220 인 svchost.exe 프로세스가 135번 포트를 LISTENING 하고 있으며 이 녀셕이 RPC 포트 매퍼 서비스임을 알 수 있다. 그리고 DTC 프로세스인 msdtc.exe 프로세스는 1026번 포트를 LISTENING 하고 있다. 간단하게 분산 트랜잭션을 수행하는 프로그램을 작성하고 이 프로그램이 필자의 SQL-Server를 액세스 하도록 하면 msdtc.exe 프로세스는 1026번 포트를 사용하여 통신하고 있음을 파악할 수 있을 것이다. 이제 MSDTC 서비스를 중단하고 다시 시작해 보자 (어떻게 하냐고? -_- 여기까지 읽어 내려온게 가상하다고 할 수 있겠다...-_-). msdtc.exe 가 사용하는 포트는 1026번이 아닌 다른 포트가 될 것이다. CheckPoint 글이 길어지는 관계로 여기서 정리 좀 하고 다음 글에 계속 써야 할 것 같다. 지금까지의 뽀인또는 많은 Windows 기반의 서비스와 제품군들이 RPC를 사용하고 있으며, 특히 프로그래머들과 관계가 많은 COM+와 MSDTC 역시 RPC에 기반한다는 것이다 (COM+가 어떻게 RPC를 사용하는가는 난중에 설명하께~~). 그리고 이 RPC의 특성 중 하나가 고정된 TCP/IP 포트를 사용하는 것이 아니라 임의의 사용 가능한 포트 중 하나를 사용한다는 점이며, 이렇게 가변 포트를 사용하기 때문에 포트 정보를 제공하는 종점 매퍼를 가지고 있다는 점이다. 대략 눈치를 챘겠지만, 방화벽으로 막혀있는 두 컴퓨터가 RPC 기반의 서비스(COM+, MSDTC 등)를 사용할 때 어떤 TCP/IP 포트를 열어야 하는지 이제 좀 감이 갔으면 한다. 상세한 내용은 다음 글에 남기도록 하겠다... 이거 블로그 맞어? 왤케 길어? -_-
경고 : 이 글을 무단으로 복제/스크랩하여 타 게시판, 블로그(개인 블로그 포함)에 게시하는 것은 허용하지 않습니다.
GO TOP

=========================================================================================

잠시 텀을 둔다는 것이... 두 번째 글이 너무 늦어져 버렸습니다. 혹 기다리신 분(행여나 있었을라고... T_T)이 계셨다면 사과 드립니다. 요번 포스트에서는 RPC 가 사용하는 TCP/IP 포트를 바꾸는 방법에 대해 몇자 끄적여 볼까 합니다. 구람 잡설은 짧게 하고...

About RPC... (2)

지난 RPC 이야기에서 RPC는 동적으로 프로토콜과 종점(endpoint)을 선택할 수 있다고 했다. 오늘날 대부분의 RPC 서비스가 TCP/IP 프로토콜을 사용하지만 HTTP 처럼 고정적인 TCP/IP 포트를 사용하지 않는다. 소위 종점 매퍼(endpoint mapper)를 이용하여 사용 가능한 포트들 중에서 임의의 한 포트를 사용하도록 동적 바인딩(dynamic binding) 기법을 사용한다. 이렇게 동적 바인딩을 하기 위해 RPC 클라이언트는 종점 매퍼에게 어떤 포트를 사용해야 하는가 찔러봐야 하는데 이때 종점 매퍼가 사용하는 포트가 135번 포트이다. 고로... RPC 서비스는 항상(반드시 그렇진 않지만 대부분) 135번 포트와 RPC 서비스가 서비스에 사용하는 가변적인 포트를 2개 이상 사용한다는 것이 지난 포스트의 요지가 되겠다.

요번 포스트에서는 RPC 서비스가 사용하는 포트를 임의가 아닌 내가 설정하는 포트들 중에서 하나를 사용하도록 설정하는 방법에 대해 알아보겠다. 왜 그렇게 해야 하냐고? 음... DB 서버에 SQL Server가 설치되어 있다고 가정해 보자. 그리고 웹 서버에서 분산 트랜잭션을 사용하여 DB 서버에 접근해야 한다고 역시 가정해 보자. 그리고 둘 사이에 방화벽이 버티고 있다고 한가지 더 가정해 보자. 방화벽에서 SQL Server에 관련된 포트를 열어 줘야겠지? SQL Server 가 사용한다는 1443 포트만 달랑 열어주면 될까? SQL Server가 분산 트랜잭션에 관여된다는 이야기는 웹 서버와 DB 서버의 DTC가 서로 통신한다는 이야기가 되고 이는 곧 RPC 프토로톨이 사용된다는 얘기이다. 따라서 RPC 가 사용하는 포트 역시 열어줘야 하는데... 1443번 포트에 추가해서 달랑 135번 포트만 열어주면 될까? 아니올시다란 말이다. 그렇담 어떻게 해야 하는가? RPC는 사용 가능한 포트들 중 거의 랜덤하게 포트를 사용할 것인데 어떤 포트를 사용할 줄 알고 방화벽 포트를 열어 줄 것인가?

해결책은 있다. 첫째로 무식하면 용감하다는 말 대로 하면 된다. msdtc.exe가 사용하는 포트를 매번 모니터링 했다(모니터링 하는 방법은 지난 RPC 이야기를 참조해라)가 방화벽 포트를 그때 그때 열어 주면 된다. 이러면 msdtc.exe 프로세스가 재시작하거나 시스템이 리부팅 될 때 마다 방화벽 포트를 바꾸어 주면 되겠다. 정말 멋지고 무식한 방법이 되겠다.

두 번째 방법은... DTC 가 사용하는 포트를 지정해 주고 그 지정한 포트를 방화벽이 열어주면 되지 않겠는가? 요것이 권장하는 방법임은 두말하면 입 아프다.

RPC 가변 포트 지정

RPC가 사용하는 임의의 포트를 지정해주는 방법은 어렵지 않다. Windows NT 시절에는 레지스트리를 직접 수정해 주어야 했지만 (그때는 정말 빡셌다... -_-) 지금은 친절한 UI가 존재 한다. 비록 이름이 엉뚱해서 햇갈리지만...

구성요소 서비스 MMC를 열고 내 컴퓨터를 찾아 등록정보를 지긋이 눌러보자. 내 컴퓨터 등록정보가 나타날 것이다. 이제 기본 프로토콜 탭을 찾아 눌어 보자. 특별히 Windows 2000 이나 Windows 2003 서버에서 이 설정을 손대지 않았다면 '연결 지향 TCP/IP'가 아마 맨 위에 위치해 있을 것이다. '연결 지향 TCP/IP'를 선택하고 '속성...' 버튼을 누른다. 그러면 'COM 인터넷 서비스 속성' 대화상자가 또 나타난다. 이 대화상자에서 포트 범위 값을 지정할 수 있다. (딴거 손대지 말고 포트 범위만 입력하자. 딴거 설명하면 입만 아프고 별 의미도 없다. 정 궁금하면 KB 자료 찾아보길 바란다.) 말로만 하면 절대로 못찾을 터... 캡처 서비스 들어간다...

<< RPC 포트 설정 UI :: 요 UI 안쓸려면 요기에서 지시하는대로 레지스트리 수정하든가... 빡실껄? >>

근데 좀 이상타... RPC 가 사용하는 포트를 지정할 수 있게 해준다면서 웬 구성 요소 서비스(COM+) MMC 에, COM 인터넷 서비스 속성? 요거이 마소의 문제가 되긋다. 분명 이 설정은 모든 RPC 서비스에 영향을 주는 변경 사항임에도 불구하고 UI는 떡하니 COM+ 관련 MMC에 포함되어 있다. 요거 조심해야 할 것이다. 이 설정을 바꾸면 모든 RPC 서비스에 영향을 준다는 것을 명심하자. 실제로 이렇게 속성 값을 바꾸면 레지스트리 키가 하나 추가되는데, 추가되는 위치가 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\Internet 이다. 바로 RPC의 속성에 기록되는 것이다. 이렇게 애매한 이름이로 애매한 위치에 RPC 포트 설정을 넣어버린 마소는 꼬추 잡고 반성해야 할 것이다.

어찌 되었건 위와 같이 설정하면 RPC 가 사용하는 포트는 40000 번 부터 40010 번 사이에서 결정된다. 이렇게 해놓고 방화벽을 40000번 부터 400010번을 열어 주면 된다. 따라서 방화벽에 열어주어야 할 포트는 1443 번 SQL Server 포트, 135번 RPC 종점 매퍼 포트 그리고 RPC 가변 포트 40000~40010 포트를 열어주면 된다. Windows XP 나 Windows 2003에 기본 포함된 방화벽은 포트의 범위를 열 수 없으므로 조뺑이 치면서 40000 부터 40010까지 반복 노가다를 해야 한다. 쯔읍...

여기서 한가지... Windows 2003 SP1 혹은 Windows XP SP2에 포함된 방화벽을 사용하는 경우의 설정은 좀 더 쉽다. 새로이 추가된 프로그램 포트 설정(해당 프로그램이 사용하는 모든 포트를 방화벽이 허용하는 옵션)과 135번 포트를 열어주면 RPC를 사용할 수 있다. DTC의 경우라면 msdtc.exe 프로그램과 135번 포트를 열어 주면 된다는 얘기이다(관련 KB 자료 링크 혹은 다른 KB 자료 링크). 이러한 설정은 앞서 RPC의 포트 영역 설정을 하지 않아도 무방하다. 하지만 별도의 방화벽 독립 제품이라면 RPC가 사용하는 포트 설정은 필수적인 것이다 (개발 서버 혹은 운영 서버라면 방화벽 서버가 존재할 것이다.)

그리고 이 설정이 끝나면 컴퓨터를 리부팅 해야 한다. 요것이 아픔이 되겠다. 이 설정은 RPC 종점 매퍼를 재시작 해야만 효과가 있는 설정이다. 그래서 RPC 종점 매퍼를 재 시작할려고(사실 재시작 옵션이 존재하지도 않는다) 치면... RPC 종점 매퍼에 의존성이 있는 모든, 십 수개의 핵심적 운영체제 서비스가 재시작 되어야 한다. 이건 거의 재부팅 수준이고... 서비스 들이 성공적으로 재시작한다는 보장도 없으므로... 리부팅을 해야 한다. 운영 중인 서버라면 재부팅이 상당히 부담되겠지만... 심야 작업을 통해서라도 재부팅을 해야 설정이 유효해 짐을 명심하자.

재부팅이 되면 TcpView 유틸리티로 msdtc.exe 프로세스가 어떤 포트를 사용하고 있는지 눈으로 확인하자. 우리가 지정한 포트를 사용하고 있음이 확실할 것이다.

<< 40000~ 40010 번 포트를 RPC에서 사용하도록 설정한 후의 TcpView 상황 >>

위 그림에서 msdtc.exe 프로세스가 40001 번 포트를 사용하고 있음을 확인할 수 있을 것이다. 그리고 lass.exe 프로세스는 Windows 의 보안 관련 서비스 프로세스로서 인증, 권한에 관련된 다양한 서비스를 제공하는 프로세스다. 그리고 이 녀석도 역시 RPC를 사용한다 (보면 몰라? 40000 번 포트 쓰잖아).

왜 포트를 여러 개 지정해야 하는가?

다 좋다... 그런데 왜 포트를 여러 개 설정하고 열어야 할까? 40000번 포트 한 개만 사용하도록 하면 안되나? 보안상의 문제도 있고... 음냐뤼... 지금까지 글을 제대로 읽지 않았다고 볼 수 밖에 없는 질문이다. 이 설정은 모든 RPC 서비스들에 영향을 준다고 했다. 그렇다면 DTC 뿐만 아니라 Windows 기본 인증 서비스, 기타 등등 모든 서비스는 설정된 포트들을 쓸 것 아닌가? DTC가 수행되기 전에 다른 RPC 서비스가 구동되서 달랑 한 개 사용가능한 포트를 써 뿌리면 어떻게 해야 하나? 조지는 것이다. 이 때문에 RPC 서비스를 사용하는 다른 서비스들을 위해 최소 5개 정도의 포트를 열어 두는 것이 좋다. 만약 방화벽을 사이에 두고 DCOM 호출을 한다면 더더욱 설정할 포트의 개수는 늘어난다고 보면 된다. DCOM 역시 하부 프로토콜로 ORPC라는 것을 쓰는데, ORPC도 역시 RPC의 일종이기 때문이다.

DCOM은 언제 쓰느냐고? DCOM은 부지 불식 간에 많이 사용된다. MMC를 열어 다른 컴퓨터를 '관리' 해 본적이 있을 것이다. 이 때 MMC는 원격 컴퓨터의 COM객체를 DCOM에 의해 호출한다. 또, COM+ 의 어플리케이션 설정이 '서버' 이고 이 어플리케이션을 원격 컴퓨터에서 프록시 내보내기를 통해 액세스 한다면 당근 사용되는 것이 DCOM 이기도 하다.

앞서의 화면 캡처에서 inetinfo.exe 프로세스도 40002번 포트를 사용하고 있음을 주의 깊게 살펴보자. 필자가 다른 컴퓨터에서 인터넷 정보 서비스 관리 MMC를 띄워서 이 컴퓨터에 '연결'한 경우이다. 이렇게 IIS 관리자 MMC에서 원격 컴퓨터를 액세스 할 때 DCOM (RPC)을 사용하여 원격 액세스를 수행하며 이 때에 RPC에서 사용한 포트를 하나 사용한다. COM+의 서버 타입의 어플리케이션을 작성하고 '내보내기'를 수행하여 원격에서 호출을 수행해 보자. 역시 설정된 RPC 포트를 사용할 것이다.

그렇다면 몇 개정도의 RPC 포트를 설정해 주는 것이 좋을까? 항상 그렇듯이 정답은 읍다. '그때 그때 달라요'가 되겠다. 테스트 기간에 넉넉하게 많은 포트를 설정해 놓고 사용되는 포트의 개수를 확인하여, 운영 시스템에서 적절한 포트 수를 적용하는 얍삽한 방법을 추천하는 바이다.

DTC가 제대로 작동할까?

자... 이제 RPC의 포트 설정도 했고 방화벽도 적절히 열어 줬으니 DTC를 통해 분산 트랜잭션이 되어야지... DB 서버가 Windows 2000 이라면, 그리고 웹 서버가 Windows 2000이거나 Windows XP SP1 이라면 잘 될 것이다. 하지만 DB 서버가 Windows 2003 이거나 혹은 DB 서버건 웹 서버건 Windows XP SP2를 사용 중이라면 여전히 DTC를 통한 분산 트랜잭션은 제대로 수행되지 않을 가능성이 높다. Windows 2003과 Windows XP SP2 의 강력한 보안은 DTC에 추가적인 RPC 보안 설정을 넣어 놓았으니... 요거이 제대로 설정되지 않으면 DTC는 작동하지 않을 것이다.

DTC의 보안 설정을 수행하는 방법은 다음 포스트(가급적 최대한 빨리)에 ...... 메렁~

이번 RPC 이야기는 RPC 작동을 테스트하기 위한 다양한 도구들을 소개하고자 합니다. Rpcdump, rpcping, dtcping, dtctester 등의 도구를 통해 RPC 가 실제로 작동하는지 여부를 테스트할 수 있습니다. 특히 dtcping 이나 dtctester는 DTC를 위한 전용 테스트 도구로서 COM+ 컴포넌트가 수행되는 어플리케이션 서버와 SQL Server가 수행되는 DB 서버 사이에 분산 트랜잭션이 수행되는가를 테스트하는 중요한 도구 입니다.

About RPC... (3)

지난 RPC 이야기 두 번째에서는 RPC가 사용하는 TCP/IP 포트를 설정하는 방법을 살펴보았다. 덤으로 방화벽을 통과하여 RPC가 수행될 수 있도록 방화벽을 설정하는 방법도 살펴보았다. 이번에는 RPC 포트 설정이나 방화벽 설정이 정말 잘 되었는가를 확인하는 방법들에 대해 살펴보도록 하겠다. 대표적인 도구가 rpcping.exe 이라는 유틸리티이다. 이외에도 잘 알려지지 않은 rpcdump.exe 유틸리티가 있는데 이것에 대해서도 살펴보도록 하겠다. 그리고 각 RPC 서비스 별로 RPC 통신을 테스트 할 수 있는 도구들이 있는데, 그것들이 rpings.exe, rpingc.exe, dtcping.exe, dtctester.exe 등이 그것이다. 요것들에 대해서도 잠시 살펴보도록 하겠다.

Rpcping.exe 와 Rpcdump.exe

Rpcping.exe는 RPC 통신이 수행되는지를 검사해주는 다양한 기능을 갖고 있는 유틸리티이다. TCP/IP에서 사용하는 ping.exe 와 동일하게 RPC 프토로콜을 이용하여 해당 서버와 접속이 가능한가를 테스트 해준다. 이 녀석을 다운로드 받기 위해서는 Windows Resource Kit을 다운로드 받아야 한다(다운로드 페이지에는 마치 2003 전용인 것처럼 보이는데 Windows XP에서도 사용할 수 있다). 리소스 킷 내에는 다양한 도구들이 존재하므로 쫄지 말고 rpcping.exe를 찾아 사용하면 된다. (도움말도 있다 !!)

Rpcping.exe의 옵션은 대단히 많다. 거의 질릴 정도이다. 대부분 RPC에 대해 상세히 알고 있어야 하는 옵션들이 대부분이므로 정말 RPC를 좀 파볼 사람이 아니면 -s 옵션(대소문자를 구분 하니 조심할 것)만 알고 있으면 된다. -s 옵션으로 테스트 하고자 하는 서버의 이름이나 IP를 주면 된다. 가급적 서버 이름으로 테스트 하자.

Rpcdump.exe는 서버의 RPC 종점 매퍼가 어떤 종점들을 등록하고 있는지 조회하는 유틸리티이다. 이 녀석 역시 Windows Resource Kit에 포함되어 있으며, 사용법도 매우 쉽다. -s 옵션으로 서버 이름을 주면 서버의 종점 매퍼가 등록하고 있는 종점들의 목록이 표시된다.

일반적으로 Rpcping.exe와 rpcdump.exe는 서버의 종점 매퍼와만 통신한다. 따라서 rpcping.exe 테스트와 rpcdump.exe 테스트가 성공하기 위해서는 135번 포트가 사용될 수 있으면 된다. 즉, 방화벽에 135번 포트가 열려 있다면 rpcping.exe와 rpcdump.exe 테스트는 성공할 것이다. 여기서 뽀인뜨는 rpcping 이 성공하더라도 실제 RPC 서비스를 성공적으로 사용할 수 있는지는 알 수 없다는 것이다. 그 이유는 rpcping이 특정 RPC 서비스를 테스트하는 것이 아니라 RPC 종점 매퍼와만 통신하여 RPC 접속이 가능한가 만을 테스트 하기 때문이라는 것이다. 이것은 ping 이 성공한다고 해서 항상 FTP 서비스를 받을 수 있지 않다는 것과 동일한 이치인 것이다.

Rpings.exe 와 Rpingc.exe

Rpings.exe와 Rpingc.exe 유틸리티는 RPC 서버(rpings.exe)와 RPC 클라이언트(rpingc.exe) 역할을 하는 완전히 독립된 RPC 클라이언트/서버 세트이다. 따라서 테스트 하고자 하는 서버에서는 rpings.exe를, 클라이언트에서는 rpingc.exe를 수행시켜 이 두 프로그램이 서로 통신을 수행하는지 검사하는 유틸리티가 되겠다. 상세한 사용법은 Windows Resource Kit과 함께 설치되는 유틸리티 도움말을 살펴보기 바란다 (그래도 스스로 조금의 노력은 들어가야... -_-).

Rpcping이 단순한 ping 테스트라는 점, 즉 135번 포트를 통해 RPC 종점 매퍼와 통신할 수 있는지 만을 확인해 주는 반면, rpings.exe는 실제 가상의 RPC 서비스(아주 간단하며 rpingc.exe 만이 이해하는)를 실제로 제공하므로 135번 포트 외에 추가적인(그리고 가변적으로 바뀌는) RPC TCP/IP 포트를 사용하므로 보다 명확한 테스트를 할 수 있다. RPC에서 사용하는 포트를 지정해 놓고(구체적인 방법은 지난 포스트에서 다루었다) 실제로 RPC 서비스가 이 포트를 사용하는지 테스트할 수 있다고 하겠다(물론 TcpView로 확인하는 방법도 있겠다).

Rpingc.exe의 또 한가지 특징은 rpings.exe 뿐만 아니라 Exchange 의 RPC 서비스를 테스트하는 능력을 가졌다는 것이다. 지금은 잘 기억나지도 않고 테스트 환경도 갖추어지지 않아 정확히 테스트 해볼 수는 없지만 rpingc.exe 의 UI 에서 endpoint를 Exchange의 Storage나 Admin으로 설정하여 Exchange 서버에 RPC를 통해 접속이 가능한가 테스트가 가능하다.

비록 rpingc.exe가 Exchange 서버에 대해 RPC 테스트를 할 수 있다고는 하지만 rpings.exe와 rpingc.exe 로 테스트를 했다고 해서 모든 RPC 서비스가 잘 작동할 것이라고 가정할 수 없다. 하지만 rpcping, rpings, rpingc 유틸리티들을 통해 기본적인 RPC 통신을 테스트할 수 있고, 이 테스트가 성공했다면 RPC 프로토콜 통신 자체에는 문제가 없다고 보면 된다. 이 테스트가 성공적임에도 불구하고 정상적인 RPC 서비스를 받을 수 없다면 그것은 RPC 프로토콜 문제가 아닌 해당 서비스의 문제로 압축할 수 있기 때문에 문제 해결의 범위를 축소할 수는 있겠다.

Dtcping.exe와 Dtctester.exe

앞서 언급한 대로 rpcping, rpings, rpingc 등의 유틸리티는 일반적인 RPC 프로토콜에 대한 검증이다. 특별한 서비스를 테스트 하기 위해서는 해당 서비스를 사용하는 간단한 유틸리티를 작성해야 한다. 필자의 관심이자 많은 개발자의 관심 대상인 DTC의 경우는 친절(?)하게도 MS에서 유틸리티를 제공하고 있다. Dtcping과 Dtctester가 그것이다. 이 두 유틸리티는 RPC를 사용하여 서버 상의 DTC 서비스와 실제 통신을 한다. 이 두 유틸리티로 테스트가 성공한다면 DTC 를 통한 분산 트랜잭션 역시 성공할 것이다.

필자가 맘에 들어 하는 유틸리티는 dtcping 이다. 이 녀석은 DTC가 문제없이 작동하기 위해 필요한 사항들을 모두 점검해 주며, 문제가 발생했을 때 문제 해결을 위한 다양한 정보를 제공해 주기 때문이다. 예를 들어, DTC는 상호 호출을 수행하며(분산 트랜잭션의 특성상 그렇다) 이 때문에 DTC 끼리 통신하는 두 컴퓨터(웹 서버와 데이터베이스 서버가 전형적인 예)가 서로 컴퓨터 이름(도메인이 붙지 않는)으로만 서로의 IP를 알아낼 수 있어야 한다. Dtcping은 테스트에 참여한 두 컴퓨터의 이름으로 IP를 알아내어 RPC 통신이 가능한가를 검사하며, 그 과정을 로그파일에 남겨준다.

<< Dtcping.exe 수행 시 화면 : 서버와 클라이언트에서 모두 수행 시켜야 한다. >>

Dtcping도 단점이 있다. Dtcping의 단점은 실제 DTC를 사용하는 것이 아니라 DTC의 행동을 애뮬레이션 한다는 점이다. 이 때문에 테스트 하고자 하는 두 컴퓨터에서 모두 dtcping을 수행시켜야 한다. 또한 dtcping 테스트를 통과했더라도 실제 DTC 통신, 즉 분산 트랜잭션이 작동하지 않을 수도 있다. 웹 서버와 데이터베이스 서버가 모두 Windows 2000 이라면 dtcping 테스트가 성공하면 DTC는 제대로 작동한다고 보면된다. 하지만 Windows 2003과 Windows XP SP2의 강화된 보안 설정 중에 DTC의 보안강화도 포함되어 있으며 이 보안 설정을 Dtcping이 똑같이 애뮬레이션 하지 않기 때문에 dtcping 테스트가 성공하더라도 분산 트랜잭션에 문제가 발생하곤 한다. 따라서 dtcping 을 보완할 유틸리티가 있어야 하는 것이다.

Dtctester가 바로 보완적인 유틸리티로 볼 수 있다. Dtctester는 실제 DTC를 사용하여 분산 트랜잭션을 수행한다. 이 테스트가 성공한다면 DTC 통신에 문제가 없는 것이며 이 테스트가 성공하지 않는다면 DTC 설정이 잘못되어 있는 것이다. Dtctester는 실제 DTC 서비스를 이용하므로 Dtcping이 갖는 문제는 없다. 하지만 Dtctester는 문제 해결을 위한 정보를 거의 제공하지 않는다. 단순히 DTC 테스트가 성공했는지 실패했는지만을 간략하게 알 수 있을 뿐이다. 따라서 Dtcping을 통해 일반적인 문제를 해결하고 최종적으로 dtctester로 테스트를 한번 더 하는 것이 좋다.

마치며...

지금까지 3회에 걸쳐 RPC에 대한 썰을 풀어봤다. 도움이 되었을 수도 있고 그렇지 않을 수도 있지만 꼭 한번 정리하여 알리고 싶었던 내용이므로 갠적으로 만족하는 바이다. Windows 2003 및 Windows XP SP2의 DTC 보안 설정에 대해서 대략 간단히 언급만 하고 넘어가서 아쉽지만 스크롤의 압박이 있는지라...

다음에 기회를 내서 (언제? 못 미더워... -_-) DTC를 설정하는 완벽(?) 가이드를 작성해 볼까 한다. 말로만~~~~~

경고 : 이 글을 무단으로 복제/스크랩하여 타 게시판, 블로그(개인 블로그 포함)에 게시하는 것은 허용하지 않습니다.