특정한 사용자들이나 부서단위로 회사의 RAS서버에 접속하도록 허용하거나 제한하는 것 등의 결정은 RAS 정책이 어떻게 만들어져 있는지에 달려있다. 단순하게 RAS를 사용하는 것은 특별한 정책이 필요한 것은 아니지만 이러한 정책이 802.1x무선인증, 디렉토리와 연동한 네트워크 디바이스 등에도 적용가능하여 그 활용도가 증가하고 있기 때문에 정리해 두면 도움이 될 것이다.

7-3-1. RAS정책 생성하기

간단하게 정책을 생성하는 방법을 예제를 통해 알아 보도록 하자.

<그림7-60. RAS정책 추가하기1>	‘라우팅 및 원격액세스’관리도구를 열면 왼쪽 패널에서 ‘원격 액세스 정책’을 찾을 수 있다. 오른쪽 패널에서 기본정책이 2가지 있는 것을 볼 수 있다.
<그림7-61. RAS정책 추가하기2>	새로운 정책을 추가해 보도록 하자. 예제에서는 SalesTeam 그룹에 속한 사용자들에게 VPN접속 권한을 할당하는 정책을 생성한다.   왼쪽패널의 ‘원격 액세스 정책’을 마우스 오른쪽 클릭하여 ‘새 원격 액세스 정책’을 선택한다.<그림7-61>
<그림7-62. RAS정책 추가하기3>	마법사 화면이 나온다.<그림7-62>
<그림7-63. RAS정책 추가하기4>	정책을 설정하는 방법은 2가지이다. 마법사를 이용하는 것과 사용자가 정책을 직접 만드는 방법이 있다. 마법사를 이용하여 만들어보도록 하자. 정책이름 항목에는 나중에 정책을 알아보기 쉽도록 직관적인 이름을 사용하자. ‘SalesTeamRAS정책’이라고 입력했다.
<그림7-64. RAS정책 추가하기5>	이 정책에 해당하는 연결을 선택한다. 예제에서는 ‘VPN’을 선택했다.
<그림7-65. RAS정책 추가하기6>	접근을 허용하고자 하는 사용자나 그룹을 선택할 수 있다. <그림7-65> 그룹을 선택한 후 [추가]버튼을 클릭하여 SalesTeams 그룹을 추가했다. [다음]으로 진행한다.
<그림7-66. RAS정책 추가하기7>	인증방법을 결정한다. 기본값은 MS-CHAPv2이다. 클라이언트가 Windows 2000 이상이라면 기본설정을 하고 진행하면 된다. <그림7-66>
<그림7-67. RAS정책 추가하기8>	암호화 수준을 선택하고 [다음]으로 진행한다.
<그림7-68. RAS정책 추가하기9>	새 원격 액세스 정책 마법사가 완료되었다. 요약 내용을 확인한 후 [다음]을 눌러 정책생성을 완료한다.<그림7-68>
<그림7-69. RAS정책 추가하기10>	<그림7-69>를 보면 ‘SalesTeamRAS정책’이 추가된 것이 보인다. 정책이름옆의 숫자에 주목하라. 순서를 나타내는데 최근에 추가한 항목이 기본적으로 맨 위에 올라가 있고, 순서로는 1에 해당한다.

이제 SalesTeams 그룹에 속한 사용자가 위의 RAS서버에 VPN을 통해 접속하면 접속이 허용된다.

7-3-2. RAS정책의 이해

이러한 RAS 정책이 구체적으로 어떻게 이루어져 있는지 알아보자. 차근차근 이해해서 꼭 알아두도록 하자. 다양하게 사용할 기회가 있을 것이다.

RAS정책중의 하나를 더블클릭하여 열어보면 <그림7-70>과 같은 화면을 볼 수 있다. RAS정책은 조건(Condition), 접근권한(Permission), 프로필(Profile)의 세가지 요소로 구성되어 있다. RAS클라이언트가 전화접속이나 VPN접속을 통해서 서버에 접근하면 RAS서버는 정책을 보고 클라이언트의 접근에 대한 판단을 내린다. 맨 처음에 정책의 조건에 사용자가 접근한 상황이 만족하는지를 살펴본다. 조건에 부합하면 이번에는 접근권한을 살펴서 접근이 허용되었는지 거부되었는지를 확인한다. 정책은 접근을 허용하기 위한 것만은 분명히 아니다. ‘특별한 조건에 만족하면 접근거부’라는 배타적인 접근권한도 있을 수 있다. 접근이 허용된다면 마지막의 요건인 프로필에서는 추가적인 제한, 연결지속시간 제한 등의 추가설정을 확인한다.

예제를 통하여 정책을 이해해 보도록 하자. 예제를 위해 다음의 상황을 가정한다. RAS서버는 다음의 정책1, 정책2의 2가지 RAS정책을 가지고 있다. RAS 클라이언트가 접근할 때 RAS서버는 어떻게 판단하는지 설명한다.

l  정책1 : Sales그룹에 소속된 멤버가 RAS서버에 접근하면 접근을 허용하는데, 허용시간은 10분으로 제한된다.

l  정책2 : 오전9시부터 오후6시 사이에 접근하면 접근을 거부한다. (이 경우 프로필의 설정은 의미없는 설정이다)

<그림7-71>에서는 이해를 돕기 위해 정책의 흐름을 도식화하였다. Sales그룹에 속한 RAS클라이언트가 이 RAS서버에 접근했다고 가정하자. 이 때 RAS서버는 2개의 정책중 순서상으로 위에 있는 ‘정책1’을 먼저 판단한다. 그림에서 첫번째 질문은 ‘현재 사용자의 연결이 정책1의 조건에 만족하는가?’이다. 정책1의 조건은 ‘sales그룹의 멤버’이다. 조건에 만족하므로 다음의 판단항목인 ‘사용자 계정에 대한 전화접속 권한 설정은 무엇인가?’로 진행한다. 여기서 주의해야 한다. 정책1의 접근권한이 ‘접근허용’으로 되어 있다고 해서 무조건 서버에 접근이 허용되는 것이 아니다. 그것은 사용자 개개인의 ‘전화 접속 로그인’ 권한에 달려 있다. <그림7-72>의 사용자 계정에 대한 ‘전화 접속 로그인’탭을 보면 ‘원격 액세스 권한’항목이 있고, 세가지의 옵션이 있는 것을 확인할 수 있다.

이 설정이 어떻게 되어 있는지가 접근권한이 결정되는데 중요한 요소가 된다. <그림7-71>의 흐름을 따라가 보도록 하자. <그림7-72>에서 만일 현재 접근하는 사용자 계정에 대한 원격 액세스 권한이 ‘액세스 거부’로 되어 있으면 RAS서버는 사용자의 연결을 거부한다. ‘액세스 허용’으로 되어 있으면 RAS서버는 정책1의 권한설정값과는 무관하게 사용자의 연결을 허용한다. 사용자 계정에 대한 원격 액세스 권한이 ‘원격 액세스 정책을 통해 액세스 제어’로 되어 있을때만 RAS정책의 ‘접근권한’의 설정값이 유효하다는 것이다.

여기서 생각해 볼 것이 있다. 사용자 개개인의 계정에 대해서 ‘원격 액세스 권한’설정을 한다면 관리적인 측면에서 쉽지 않을 것이다. 누구는 허용하고, 누구는 거부하고.. 사용자가 많아질수록 일관성이 결여되는 정책이 될 수 밖에 없다. 필자가 생각하는 가장 좋은 설정은 ‘원격 액세스 정책을 통해 액세스 제어’이다. 사용자 계정에 대한 권한설정은 이대로 두고, RAS정책을 통해서 접근권한을 제어하는 것이 관리의 오버헤드를 줄여주고 관리자 실수에 의해 불필요하게 RAS서버로의 접근을 허용하는 실수를 막을 수 있는 좋은 방법이다.

어떻게든 ‘접근허용’이라는 결과가 나왔다면 그 다음에 RAS서버는 프로필에 만족하는지를 판단한다. 프로필에 결격사유(?)가 없으면 최종적으로 접근허가라는 판정이 내려지고 클라이언트 접속은 허용된다.

만일 현재 접근하고자 하는 클라이언트가 Sales그룹의 멤버가 아니라면 어떻게 될까? RAS서버는 클라이언트가 정책1의 조건에 만족하지 못하고 있음을 알 것이고, 다음의 정책인 정책2의 조건에 만족하는지를 판단한다. 현재 클라이언트가 접속하고 있는 시간이 오전11시라면 조건에 만족한다. 그 다음 판단요소인 ‘접근권한’검토를 시작한다. 이 클라이언트의 원격 액세스 권한 설정이 <그림7-72>와 같이  ‘원격 액세스 정책을 통해 액세스 제어’로 되어있다면 정책2의 접근권한 설정값인 ‘접근거부’가 반영되어 클라이언트의 연결은 거절되겠지만 ‘액세스 허용’으로 설정되어 있다면 RAS정책에서는 ‘접근거부’라고 되어 있지만 사용자는 접근이 허용되고 말 것이다. 정책이 반영되지 않는 의도하지 않은 상황이 발생할 수도 있다는 것이다. 주의를 기울여야 할 부분이다.

만일 정책의 순서가 아래와 같이 바뀌어 있다면 어떻게 될 것인지도 검토해 보자.

이 경우 오후3시경에 Sales그룹의 멤버가 이 RAS서버에 접근했다면? 결과는 접근거부이다. 앞에서는 정책1이 적용되어 접근이 허용된 반면에 이번에는 정책2가 먼저 적용되어 접근이 거부된 것이다. 이처럼 2가지의 정책이 있을 때 첫 번째 정책에서 접근거부 판단이 내려졌다고 해서 두 번째 정책을 적용받는 것이 아니다. 첫 번째 정책의 ‘조건’에 만족되지 않을 때는 두 번째 정책을 판단하게 되지만 일단 ‘조건’에 만족되면 더 이상 그 다음 정책으로 넘어가지는 않는다는 것을 알 수 있다.

* Active Directory 환경에서 사용자 계정에 대해 ‘원격 액세스 정책을 통한 액세스 제어’ 활성화하기   사용자 계정에 대한 ‘원격 액세스 권한’을 설정하기 위해 계정의 등록정보를 열어 보면 원격 액세스 권한중 ‘원격 액세스 정책을 통한 액세스 제어’옵션이 비활성화 되어 있는 경우가 있다. <그림7-73. 사용자 계정의 원격 액세스 권한 옵션> 그것은 해당 도메인이 Windows Server 2003 이전버전인 Windows NT4.0, Windows 2000 Server 등의 도메인 컨트롤러와의 호환성을 유지하는 "mixed mode(혼합모드)"로 도메인 기능수준 (Domain Functional Level)설정이 되어 있기 때문이다. Active Directory를 셋업했을 때 기본설정이 '혼합모드'이므로 특별히 설정을 바꾸지 않았다면 '혼합모드'로 되어 있을 것이다. 도메인 기능 수준을 올려주어야 한다. 이 작업을 하기 전에 도메인에는 Windows Server 2003 서버만이 도메인 컨트롤러 역할을 수행하고 있어야 한다. <그림7-74. 도메인 기능 수준 올리기1> ‘시작’à’프로그램’à‘관리도구’à’Active Directory사용자 및 컴퓨터’를 선택한 후 왼쪽 패널에서 도메인 이름을 마우스 오른쪽 클릭한 후 ‘도메인 기능 수준 올리기’를 클릭한다. <그림7-75. 도메인 기능 수준 올리기2> 사용 가능한 도메인 기능수준 선택에서 ‘Windows Server 2003’을 선택하고 [수준 올리기]를 클릭한다. <그림7-76. 도메인 기능 수준 올리기3> <그림7-77. 도메인 기능 수준 올리기4>

7-2-1. VPN의 필요성

먼저 한가지 개념을 정리해 보자. 회사와 회사간의 연결하는 방법을 놓고 사설 네트워크와 공용네트워크로 나눠볼 수 있다. <그림7-32>의 예제에서 서울에 본사가 있고, 여수와 부산에 지사가 있고, 재택근무를 하는 클라이언트가 있는 회사가 있다고 가정하자. 서울에서는 ISP를 통해서 인터넷에 접근하도록 구성되어 있다. 서울과 여수, 서울과 부산을 각각 연결하는 방법으로는 2가지를 이용할 수 있는데, 첫번째 방법은 전용회선을 사용하는 것이다. 서울과 여수간에 전용회선을 사용하도록 네트워크가 구성되었다면 이 전용회선은 다른 회사와는 무관해진다. 두 지점간에만 전용으로(Dedicated, Leased) 할당된 회선을 사용하기 때문에 보다 안전하고 빠르다는 장점이 있다. 하지만 단점이라면 상대적으로 비싼 고정비용을 부담해야 한다는 것이다. 이러한 네트워크를 가리켜서 사설네트워크, 혹은 전용 네트워크라고 부른다.

본사와 지사를 연결할 수 있는 두번째 방법은 인터넷을 사용하는 것이다. 부산에 있는 지사의 환경이 부산에 있는 로컬 ISP를 통해서 인터넷으로의 연결이 가능한 상태라면, 인터넷을 통해서 서울의 본사로 연결이 가능하다. 이러한 네트워크는 ‘공용 네트워크’라고 부른다. 또한 재택근무를 하는 클라이언트 역시 인터넷을 사용할 수 있다. 데이콤, KT등의 사업자에게 전화접속을 통해서 인터넷에 접근할 수도 있을 것이고, ADSL, 케이블모뎀 등의 초고속인터넷망을 통해서 인터넷에 접근할 수도 있을 것이다. 클라이언트는 이 연결을 통해서 인터넷을 통한 서울본사와의 연결이 가능하다.

이렇듯 인터넷을 통해서 본지점간, 그리고 클라이언트들까지 회사의 모든 사용자들이 서로간에 데이터를 주고 받을 수 있도록 구성되었는데, 문제는 ‘보안’이다. 서울본사와 부산지사 그리고 재택근무 클라이언트들간의 통신은 인터넷을 통해서 이루어지기 때문에 회사의 중요한 데이터가 인터넷의 수 많은 위험요소에 노출된다는 것이다. 이 부분이 해결되지 못한다면 정보보안을 고려하는 회사에서는 부담이 되더라도 전체조직간에 개인네트워크를 구현할 수 밖에 없다.

회사의 조직들간에서만 데이터를 들여다 볼 수 있고, 인터넷의 제3자는 들여다 보지 못하게 하기 위한 방법이라면 그것은 ‘암호화’기능을 떠 올릴 수 있는데, VPN(Virtual Private Network)은 이름 그대로 ‘가상 개인(사설) 네트워크’를 지원한다. 실제로는 인터넷이라는 공용네트워크를 사용하고 있지만 이 공용네트워크에 가상의 사설 네트워크를 가지는것과 같은 네트워크 환경을 제공하겠다는 것이다. 그것은 바로 VPN연결을 통해 암호화된 터널을 제공함으로써 가능해진다.

<그림7-33>에서 보면 서울본사와 부산지사간에는 VPN디바이스들이 배치되어 있어서 이들 네트워크간의 트래픽을 VPN터널을 통해서 전송할 수 있도록 지원한다. 재택근무 클라이언트는 별도의 VPN디바이스를 가진 것이 아니라 다만 VPN클라이언트 소프트웨어를 통해서 VPN서버에 접속함으로써 인터넷에서 안전한 트래픽을 사용할 수 있도록 지원하고 있다.

실제로 많은 기업들이 도입하고 있고 구현이 되고 있는 방법들이다.

마이크로소프트는 Windows운영체제에서 VPN서버, 클라이언트 기능을 소프트웨어적으로 지원하고 있다. 이것은 VPN전용 하드웨어 장비들과도 호환성이 유지되는 만큼, 응용을 해 볼 만한 기능이다. Windows Server 2003과 Windows XP Professional을 이용해서 VPN서버와 클라이언트를 구현해 보도록 하자.

7-2-2. VPN서버, VPN클라이언트 구현

이미 우리는 VPN서버 구축에 대해서는 다루었다. 언제? 앞에서 전화접속서버를 구현하였다면 이미 VPN서버 구축도 완료되었다. 기본적으로 전화접속서버는 PPTP, L2TP 각각 5개씩의 포트를 활성화시켜서 클라이언트의 VPN접속을 허용하고 있다. VPN서버 전용으로 구현하고자 했다면 앞의 <그림7-4> 라우팅 및 원격액세스 서버 설치 마법사를 수행할 때 ‘일반구성’화면에서 ‘가상 사설망 액세스 및 NAT’를 선택하여 진행하면 된다. 그것은 전화접속 서버를 구성하는 것과 동일한 과정이지만 과정을 마치면 PPTP, L2TP 각각 128개씩의 VPN포트를 구성하게 된다.

VPN클라이언트 구성을 해보도록 하자. 예제의 환경은 Windows XP Professional에서 클라이언트를 구성한 화면이다.

<그림7-34. VPN 클라이언트 구성 1>	‘제어판’à'네트워크 연결’을 클릭했다. 바탕화면의 네트워크환경의 등록정보를 통해서 접근할 수도 있다. 새 연결 마법사를 실행한다.
<그림7-35. VPN 클라이언트 구성 2>	새 연결 마법사가 시작되었다.
<그림7-36. VPN 클라이언트 구성 3>	네트워크 연결형식 선택화면에서 ‘회사 네트워크에 연결’을 선택하고 [다음]으로 진행한다.
<그림7-37. VPN 클라이언트 구성 4>	이번에는 전화접속이 아니라 VPN접속을 하고자 하는 것이니 ‘가상 사설망 연결’을 선택하고 [다음]으로 진행한다.
<그림7-38. VPN 클라이언트 구성 5>	연결의 이름을 지정해 준다. 여러 개의 연결이 있을 때 구분할 수 있는 이름을 사용한다.
<그림7-39. VPN 클라이언트 구성 6>	현재 생성하고 있는 연결을 사용하기 전에 미리 필요한 연결이 있으면 지정한다. 예를 들어서 현재 클라이언트가 데이콤에 전화접속을 하고 나서 그 연결을 통해서 회사의 네트워크에 VPN을 이용한 접속을 하고자 하는 상황이라면 초기연결이 데이콤 접속이어야 한다.   ADSL, 케이블모뎀, 전용선 등의 연결이 이미 맺어져 있다면 필요없는 설정이다. ‘초기 연결을 사용 안함’을 선택했다.
<그림7-40. VPN 클라이언트 구성 7>	VPN서버의 IP address나 hostname을 입력해 준다. 예제에서는 VPN서버의 IP Address를 입력하였다. VPN서버가 유동적이라거나 여러대의 VPN서버가 구성되어 있다면 hostname을 입력하는 것이 좋다. 예를 들면 vpn.mscs.co.kr과 같은 형태를 의미한다.
<그림7-41. VPN 클라이언트 구성 8>	새 연결 마법사가 완료되었다.
<그림7-42. VPN 클라이언트 구성 9>	[마침]버튼을 누르면 <그림7-42>의 창이 열린다. 바로 vpn서버에 접속을 해 보자. VPN서버에 미리 만들어둔 wonsuk 계정을 사용하여 접근을 하였다. [속성]메뉴를 이용하여 클라이언트의 설정을 수정할 수도 있다. [연결]을 누르면 VPN서버에 접속할 수 있다.   이 과정은 앞에서 전화접속 서버에 연결했던 것과 별 차이가 없다.
한가지 고려할 사항이 있다. VPN클라이언트는 일단 VPN서버에 접속이 되고 나면 자신의 기존 TCP/IP설정의 기본 게이트웨이 경로 대신에 VPN서버로의 연결을 기본 게이트웨이로 설정하게 된다. 그 결과 자신의 로컬 네트워크를 제외한 모든 네트워크 트래픽을 VPN서버를 통해서 시도하게 된다.   VPN클라이언트가 VPN서버로 연결을 맺은 것은 특별한 이유가 있어서이다. 예를 들어 재택근무하는 클라이언트가 회사로 중요한 데이터를 전송하고 있다거나, 지사와 본사간에 안전한 데이터 전송을 위함이었는데, 사용자들의 웹서핑과 같은 일상적인 트래픽이 VPN서버로 보내질 필요는 없을 것이다. 이것을 해결하기 위해서는 한가지 설정을 바꿔줘야 한다.
<그림7-43. VPN 클라이언트 구성 10>	네트워크 연결을 열고 VPN접속을 위해서 만든 연결의 등록정보(속성)를 연다.
<그림7-44. VPN 클라이언트 구성 11>	[속성]의 네트워킹 탭의 TCP/IP등록정보를 열고, 고급옵션의 ‘일반’탭에서 ‘원격 네트워크에 기본 게이트웨이 사용’옵션을 해제한다.   이것은 VPN클라이언트가 VPN서버에 접속을 맺고 나서 인터넷 서핑과 같은 일상적인 트래픽은 자신의 네트워크를 사용하고, VPN서버가 있는 네트워크로 가는 트래픽만 VPN을 사용할 수 있도록 해 준다.

7-2-3. 네트워크간 VPN터널 구현 (Demand dial VPN Routing)

시나리오를 하나 생각해 보자. <그림7-45>에서 본사와 지사간의 네트워크는 인터넷을 통한 공용네트워크로 연결되어 있다. 지사에서는 중요한 데이터를 본사의 SQL Server에 업데이트하여야 한다. 인터넷상에서의 도청의 위험에서 벗어나 안전한 데이터 전송을 필요로 한다면 어떠한 솔루션을 제공할 수 있을까? 윈도우 서버에서 제공하는 VPN솔루션으로 해결책을 제시할 수 있다. 인터넷이라는 공용망에 VPN (Virtual Private Network)을 통하여 암호화된 트래픽을 전달할 수 있도록 구성하면 본사와 지사간에는 안전한 통신을 할 수가 있게 된다. 그렇다고 지사의 클라이언트가 본사와만 통신하는 것은 아니다. 사용자들의 인터넷 서핑같은 일반적인 트래픽의 경우는 그냥 통과시키고 본사로 전송되는 트래픽은 VPN을 통해서 전송하고자 한다.

이러한 경우에 Demand-dial 은 최상의 솔루션을 제공할 수 있다. 물론 대용량의 트래픽과 보다 안정적인 VPN솔루션을 원한다면 VPN전용장비를 이용하는 것이 바람직하겠으나 회사에서 추가로 비용을 들이지 않고 이미 존재하는 Windows기반의 파일서버나 기타 서비스를 하는 서버에 추가로 네트워크 어댑터 카드 하나만 추가해서 간단히 구현할 수 있는 방법이기에 가장 저렴하게 원하는 결과를 얻을 수 있다.

본사에서의 서버 설정과 지사에서의 서버설정을 차근차근 알아보도록 하자. 본, 지점 공히 Multi-homed (멀티홈드; 네트워크 어댑터 카드를 여러 개 가진 컴퓨터)로 구현된 Windows 서버 시스템을 필요로 한다.

7-2-3 –1. 본사의 VPN서버 설정

앞에서의 VPN서버 설정과 동일하다. 다만 VPN서버 구성의 마지막 작업으로 2가지 옵션을 체크한다. 먼저 라우팅 및 원격 액세스 관리콘솔의 왼쪽패널에서 서버이름을 마우스 오른쪽 클릭하여 등록정보로 접근한 다음, ‘LAN및 필요시 전화접속라우팅’이 선택되어야 한다.

포트의 등록정보를 확인하여 장치에서 [구성]을 선택하여 ‘필요시 전화접속 라우팅 연결(인바운드 및 아웃바운드)’가 선택되도록 설정한다.

본사의 VPN서버는 간단히 설정을 할 수 있다. 지사의 라우터를 구성하기에 앞서 본사의 서버가 설정이 제대로 되었는지, 지사에서 본사의 VPN라우터로 접근하는데 문제는 없는지 검증해 볼 필요가 있다. 이러한 작업이 번거로워 보이지만, 무턱대고 지사의 VPN서버를 구성했을 때 생길 수 있는 문제를 보다 손쉽게 해결할 수 있을 것이다. 항상 트러블슈팅을 할 때는 문제의 원인을 분석한후 문제의 원인이 될 수 있는 부분을 격리시키든지, 문제의 출발점이 되는 부분을 찾아나가는 것이 제대로 문제해결을 할 수 있는 방법이 된다.

앞에서 VPN클라이언트 설정을 하는 방법을 사용하여 본사의 VPN서버에 잘 접속되는지를 확인하고 이상이 없다면 이번에 지사의 RAS서버를 구현해 보자.

7-2-3-2. 지사의 RAS서버 설정

지사의 RAS서버를 구성해 보자. 기본설정은 본사의 VPN서버와 유사하다.

개념은 간단하다. 지사의 RAS서버에서 VPN연결을 하나 만들고, 지사의 클라이언트가 본사로 가야하는 네트워크 트래픽을 발생시킬 때 이 VPN연결을 통해서 본사의 라우터까지 패킷을 전송할 수 있도록 구성하면 될 것이다. 라우팅 및 원격액세스 서비스는 수동 라우팅 테이블을 만들 수 있도록 지원하고 있다.

<그림7-48. Demand dial VPN Routing구현 3>	먼저 라우팅 및 원격액세스 관리콘솔의 왼쪽패널의 서버이름을 확장해서 보면 아래쪽에 '라우팅 인터페이스'를 찾을 수 있다. 마우스 오른쪽 클릭하여 '새 필요시 전화 접속 인터페이스'를 클릭한다.
<그림7-49. Demand dial VPN Routing구현 4>	마법사가 시작된다.
<그림7-50. Demand dial VPN Routing구현 5>	구성을 해 보자. 인터페이스 이름에는 구별하기 쉽도록 '본사VPN서버'라고 입력한 후 [다음]으로 진행한다.<그림7-50>
<그림7-51. Demand dial VPN Routing구현 6>	연결방법은 VPN을 선택했다. 왜?냐고 물어본다면 맨앞의 시나리오를 참고하라고 얘기해 줄 것이다.<그림7-51>
<그림7-52. Demand dial VPN Routing구현 7>	VPN에서 사용할 프로토콜을 선택한다. 자동 선택을 이용해도 좋다. 기본적으로 PPTP를 사용한다. IPSec을 통한 보안의 강화를 지원하고자 한다면 L2TP를 선택해야 할 것이다.<그림7-52>
<그림7-53. Demand dial VPN Routing구현 8>	VPN서버의 호스트이름 또는 IP주소를 입력한다. <그림7-53>
<그림7-54. Demand dial VPN Routing구현 9>	프로토콜 설정을 한다. 예제에서는 IP패킷만 라우트 하도록 구성을 하였다.<그림7-54>
<그림7-55. Demand dial VPN Routing구현 10>	지사의 라우터에서 본사의 라우터로 연결을 할 때 사용할 계정정보를 입력한다. 물론 이 계정에는 다이얼인 권한이 부여되어 있어야 한다.
<그림7-56. Demand dial VPN Routing구현 11>	인터페이스 설치가 완료되었다. [마침]을 눌러서 마법사를 마친다.
<그림7-57. Demand dial VPN Routing구현 12>	관리콘솔의 오른쪽 패널에 '본사VPN서버'가 추가된 것을 볼 수 있다. 연결상태를 확인해 보라. '연결끊김'으로 표시된 것을 확인할 수 있다. 필요할 때 연결이 만들어지는 Demana-dial 연결이다.
<그림7-58. Demand dial VPN Routing구현 13>	지사에서 본사로 가는 트래픽이 이 인터페이스를 이용하도록 구성을 해야 할 것이다. IP라우팅을 확장하고 '고정경로'를 선택한 수 마우스 오른쪽 클릭하면 '새 고정경로'를 추가할 수 있다.
<그림7-59. Demand dial VPN Routing구현 14>	인터페이스가 위에서 추가한 '본사VPN서버'가 됨을 상기하라. 대상에는 목적지 네트워크를 입력한다. <그림7-45>에서 지사에서 본사의 SQL서버에 데이터를 업데이트하고자 했다. SQL서버는 192.168.7.11을 사용하고 있고, 192.168.7.0 네트워크에 위치해 있다.

이제 작업이 완료되었다. 지사에서 본사로 가는 트래픽이 발생하면 이 지사의 VPN라우터는 본사의 VPN서버로 VPN접속을 한 다음 트래픽을 전달해 주게 된다.

7-1-2-1. 원격 액세스 권한

RAS 서비스를 하는 서버가 네트워크에서 어떤 역할을 하는지, 어떤 OS로 구성이 되어 있는지에 따라 구성메뉴가 다르다. 만일, 도메인컨트롤러나 도메인의 멤버서버에서 서비스를 한다면 '관리도구àActive Directory 사용자 및 컴퓨터'를 통해서 접근하고, 독립실행형 서버에서 RAS서비스를 구현한다면 '관리도구à컴퓨터관리'도구를 이용한다. 어떤 환경이든지 사용자 계정의 등록정보를 연 다음 '전화 접속 로그인'탭을 열면 아래의 <그림7-16>와 같은 화면을 볼 수 있다. '액세스 허용'으로 구성하면 된다. 이것은 가장 간단하게 사용자에게 권한설정을 하는 방법이지만 실제로는 RAS정책을 통하여 구현하는 것이 바람직하다. 이 장의 후반부에서 RAS정책에 대해 다루도록 한다.

원격 액세스 권한을 허용하는 것만으로도 사용자는 RAS 서버로부터 인증을 얻을 수 있게 된다. 하지만 추가로 설정할 수 있는 보안옵션들을 기억할 필요가 있다. 경우에 따라서 유용하게 사용할 수 있는 옵션이다.

7-1-2-2. 콜백 옵션

기본설정은 '콜백안함'으로 되어 있다. 콜백은 2가지 경우에 사용된다. 첫 번째는 전화요금 부담의 주체가 누구인지, 두 번째는 보안이 중요한 경우에 사용될 수 있다. 콜백옵션을 '호출자가 설정'을 셋팅하면 RAS 클라이언트가 서버에 전화를 걸어서 인증을 얻고 나면 서버는 사용자의 화면에 전화받을 위치를 입력할 것을 요구하게 된다. 이때 사용자가 현재 자신의 전화번호를 입력해 주면 서버가 클라이언트에게 전화 되걸기를 해 준다. 당연히 전화를 거는 쪽이 요금 부담을 하므로 클라이언트는 전화비용의 부담이 없이 RAS 서버에 연결해서 회사의 서버에 접속이 가능해 지는 것이다. RAS 클라이언트가 회사의 업무를 위하여 재택근무시 혹은 출장지에서 접속을 하게 되므로 전화비 부담을 회사에서 하는 것이 형평성에 맞을 것이다. 우리나라의 훌륭한 인터넷 인프라를 고려한다면 현실성이 떨어지긴 하지만.

콜백옵션을 '항상 콜백'으로 셋팅하는 것은 상황이 조금 다르다. 디렉토리 데이터베이스의 사용자 등록정보에 미리 전화번호를 입력해 두어야 한다. 그리고, RAS 클라이언트가 서버로 전화를 걸었을 때, 연결이 되고 나면 서버는 클라이언트에게 반드시 전화 되걸기를 해야만 연결이 되게 된다. 클라이언트쪽에서 별도로 전화번호를 지정할 수가 없기 때문에 RAS 사용자의 계정, 패스워드, RAS 서버의 전화번호 등이 외부에 유출이 되었다고 할지라도 상대방이 전화번호까지 도용하지 않는 이상 연결을 허용하지 않게 되는 것이다. 이것은 콜백옵션이 주는 보안중에서 가장 강력한 보안기능을 제공한다. 실제 동작하는 과정은 클라이언트쪽에서 연결을 하면서 체크해 보도록 하겠다. 이제 서버 구성은 마쳤고, 이 RAS 서버에 접속할 클라이언트를 구성하도록 한다.

7-1-3. 전화접속 클라이언트 구성

전화접속 서버에 접속하기 위해서는 클라이언트 역시 설정이 필요하다. Windows 9x 계열이나, Windows NT 4.0의 경우라면 "전화접속 네트워킹"을 통해서 설정하고, Windows 2000, XP등을 사용한다면 "네트워크 연결"을 통해서 설정할 수 있다. 예제의 화면은 Windows XP Professional에서 전화접속 서버로 연결하기 위해 구성하는 화면이다. 당연히 전화접속 서버에 연결하고자 하는 클라이언트는 역시 전화회선이 연결된 아날로그 모뎀이 필요하다.

<그림7-17. 네트워크 및 전화 접속 연결 화면 >	‘제어판’à’네트워크 연결’로 접근했다. ‘새 연결 마법사’를 클릭한다.
<그림7-18. 위치정보 입력화면 >	처음 접근할 때 위치정보를 물어보는 화면이 팝업된다. 클라이언트가 있는 위치에 대한 정보를 입력해 준다.   이 정보는 나중에 ‘제어판’à’전화 및 모뎀옵션’을 통해서 수정할 수 있다.
<그림7-19. 전화 및 모뎀 옵션 >	전화 및 모뎀 옵션을 설정하고 [확인]을 누른다.
<그림7-20. 네트워크 연결 마법사 시작 >	이제 네트워크 연결 마법사가 시작된다.
<그림7-21. 네트워크 연결 형식 선택 화면 >	네트워크 연결 형식에서 '회사 네트워크에 연결'을 선택한다. <그림7-21>
<그림7-22. RAS 서버의 전화번호 지정 >	전화접속 연결인지 가상사설망(VPN)연결인지를 선택해야 한다. 예제에서 모뎀을 가진 전화접속 서버에 연결하고자 함으로 '전화 접속 연결'을 선택했다.
<그림7-23. RAS 서버의 전화번호 지정 >	연결의 이름을 입력한다. 알기 쉬운 이름을 사용하면 된다. 예제에서는 ‘회사서버’라고 입력했다.
<그림7-24. RAS 서버의 전화번호 지정 >	'전화 걸 번호'창에서 전화접속 서버의 전화번호를 입력한다. 컴퓨터대 컴퓨터가 아니라 사람대 사람의 전화통화를 하는 것이라고 생각하면 쉽다.
<그림7-25. 네트워크 연결 마법사 완료 >	이제 설정을 마쳤다. [마침]을 눌러서 마법사를 마친다.
<그림7-26. RAS 서버로의 전화 접속 연결이 추가된 화면 >	마법사를 완료하고 나면 '네트워크 연결'화면의 전화접속 항목아래에 ‘회사서버’라는 새로운 연결이 추가된 것이 보인다. <그림7-26>
자 이제 제대로 접속이 될 것인지 테스트를 해 보자. <그림7-26>에서 ‘회사서버’ 아이콘을 더블클릭했다.
<그림7-27. RAS 서버 연결 테스트 >	사용자 이름과 암호를 입력하고 [전화걸기]를 클릭했다.
<그림7-28. RAS 서버에 전화 거는 중 >	해당 전화번호로 전화를 걸고 있다.
<그림7-29. RAS 서버에 전화 거는 중 >	연결이 되었다. 사용자 이름과 암호를 확인하는 ‘인증’과정을 거치고 있다. 이 때 해당 사용자가 전화접속서버에 ‘다이얼인’권한을 가지고 있지 않다면 권한이 없다는 메시지가 나온다.
<그림7-30. 컴퓨터를 네트워크에 등록하는 과정 >	인증이 되었다. 클라이언트 컴퓨터를 RAS서버가 속해있는 네트워크에 등록하는 과정이 나온다.
<그림7-31. 서버에 연결이 완료된 상태 >	등록이 성공적으로 되었다면 등록이 되었음을 보여주는 메시지가 나오고 작업표시줄에서 '네트워크'아이콘을 볼 수 있다.

재택근무를 하는 직원이 회사의 서버에 접속을 원한다면? 출장지에서 근무를 하는 직원이 회사의 파일서버에 접근해서 데이터에 액세스해야 할 필요가 있다면? 또, IIS 웹서버에 데이터베이스서버로 구성된 SQL Server가 사설네트워크로 구성되어 네트워크를 통해서는 접속을 할 수 없는 상황일 때 서버의 관리를 위해서는? 이러한 경우에 제공될 수 있는 솔루션이 원격 접속 서비스 (RAS)의 전화접속 서버 기능이다.

용어가 조금 낯설게 느껴질 수도 있겠지만 쉽게 생각하면 된다. 요즘은 ‘초고속 인터넷’이라는 이름으로 KT, 하나로통신 등의 사업자들이 ADSL, Cable 과 같은 인터넷 접속 서비스를 제공하고 있지만 불과 몇 년전만 하더라도 인터넷을 사용하기 위해서는 전화전속(dial-up)을 이용했다. 아날로그 모뎀을 가지고 천리안, 하이텔 등 PC통신회사의 통신서버로 전화를 걸어서 접속을 하고 인증을 얻은 다음 IP Address를 할당받고 PC통신회사의 통신서버 및 인터넷에 접속이 가능해 진다. 이때 통신서버는 사용자들의 전화접속 연결을 처리해 주는 ‘전화 접속 서버’역할을 한다.

Windows Server 2003의 RAS가 제공하는 기능중 하나인 전화접속서버도 이것과 동일하다. 사용자들이 외부의 전화접속서버를 이용하는 것이 아니라 회사에서 설치한 전화접속서버로 접속하는 것일 뿐이다. 그렇게 하기 위해서는 먼저 회사의 네트워크에 전화접속서버를 설치해야 한다.

7-1-1. 전화접속 서버 구성

예제에서는 Windows Server 2003을 통해서 구현하였다.

<그림7-1. 장치관리자 화면 >	먼저 RAS서버로 구현하고자 하는 시스템에 전화회선이 연결된 모뎀이 있어야 한다. 모뎀을 추가하고 나면 제대로 동작하는지 "장치관리자"를 통해서 확인한다.<그림7-1>
<그림7-2. 라우팅 및 원격액세스 관리콘솔 >	모뎀을 제대로 설치했다면 RAS서비스를 설정해야 한다. '관리도구à라우팅 및 원격액세스'를 통해서 관리콘솔로 접근한 다음, 서버이름을 더블클릭해 본다. <그림7-2>처럼 빨간색 화살표가 아래로 향해 있는 것이 보인다. 서비스가 멈춰 있다는 뜻이다. 서버 이름을 클릭하고 마우스 오른쪽 단추를 눌러서 '라우팅 및 원격액세스 사용 및 구성’을 클릭한다.
<그림7-3. 라우팅 및 원격액세스 서버 설치 마법사 >	라우팅 및 원격 액세스 서버 설치 마법사가 시작되었다.
<그림7-4. 라우팅 및 원격액세스 서버 설치 마법사 - 일반구성>	일반구성 창에서 "원격 액세스(전화 접속 또는 VPN)"를 클릭하고 [다음]을 누른다. 5가지 메뉴 중 하나를 선택할 수 있다. 각각 용도가 다르며, 지금 설정할 수도 있고 나중에 각각 추가로 구현할 수도 있다.   첫번째 항목인 ‘원격 액세스’를 선택하였다.
<그림7-5. 라우팅 및 원격액세스 서버 설치 마법사 –원격액세스 >	VPN서비스를 할 것인지, 전화접속 서버로 동작할 것인지를 선택한다. <그림7-5>
<그림7-6. 라우팅 및 원격액세스 서버 설치 마법사 – 네트워크 선택>	네트워크를 선택하라는 화면이 나온다. 클라이언트가 전화접속을 통해 접근했을 때 내부의 어떠한 네트워크에 연결하도록 허용할 것인지가 결정된다.
<그림7-7. 라우팅 및 원격액세스 서버 설치 마법사 - IP주소할당>	TCP/IP를 사용하기 때문에 당연히 IP Address 구성이 있어야 한다. 방법은 두 가지가 제공된다. DHCP Server를 사용하거나 RAS서버에서 직접 IP 범위를 셋팅할 수 있다. DHCP Server를 사용하겠다고 구성하면 별도의 DHCP 서비스를 구현해야 할 것이다. 예제에서는 직접 이 서버에 IP범위를 구성하도록 한다.<그림7-7>
<그림7-8. 라우팅 및 원격액세스 서버 설치 마법사 - 주소 범위 할당>	예제에서 RAS서버의 IP는 192.168.0.15이다. 클라이언트를 위해 설정하는 주소범위는 RAS서버의 IP와 같은 네트워크ID를 사용하는 IP Address범위를 지정한다. 예제에서는 192.168.0.56 ~ 192.168.0.60까지 5개의 IP Address를 범위로 지정하였다.
<그림7-9. 라우팅 및 원격액세스 서버 설치 마법사 - 다중 원격 액세스 서버관리 >	RADIUS를 사용할 것인가를 묻는 화면이 나온다. 기본설정은 '아니오'이다. RADIUS에 대한 설명은 이 장의 마지막에서 다룬다. 기본설정을 그대로 두고 [다음]으로 진행한다.
<그림7-10. 라우팅 및 원격액세스 서버 설치 마법사 - 완료 >	'라우팅 및 원격액세스 서버 설치마법사'완료 화면이 나오면 요약정보를 확인하고 [마침]을 눌러서 마법사를 마친다.
<그림7-11. 라우팅 및 원격액세스 서버 설치 마법사 - DHCP Relay Agent 구성 메시지 >	DHCP릴레이 관련한 메시지가 팝업된다. <그림7-8>의 경우처럼 RAS서버에서 IP범위를 만들 경우에는 필요없는 옵션이다. 무시해도 좋다. 하지만, DHCP Server로부터 IP Address를 받도록 설정을 했다면 DHCP Relay agent를 구성해 주어야 한다.
<그림7-12. 라우팅 및 원격액세스 서버 설치 마법사 - 일반구성>	라우팅 및 원격 액세스 서비스를 시작하고 있다.
<그림7-13. 서버 등록정보 >	설정에 문제가 없었다면 서비스는 시작되고, 서버이름을 확인해 보면 녹색의 화살표가 up되어 있는 것을 확인할 수 있다. 서버이름을 마우스 오른쪽 클릭하여 ‘속성’을 선택한다.
<그림7-14. RRAS - 포트 등록정보 >	서버의 등록정보를 확인하면 <그림7-14>와 같다. 원격액세스 서버 항목에 체크되어 있는 것을 확인할 수 있다. 이 서버를 추가로 라우터로도 사용하기를 원한다면? 라우터 항목에 체크를 하고 구성을 할 수 있다. 된다. 처음 서비스를 구성할 때는 마법사를 통해서 접근하지만, 이미 서비스가 시작되어 있을 때는 마법사를 이용한 설정은 할 수 없다. 등록정보를 이용해서 추가를 해 주어야 한다.
이제 RAS클라이언트가 서버로 전화를 걸면 서버는 전화연결을 받을 수 있도록 구성이 되었다. 여기까지 셋업을 하면 서버구성은 끝났지만, 추가로 생각해 봐야 할 옵션이 있다. 만일 특별한 RAS사용자에 대해서 서버측에서 "콜백(call back)"옵션을 지정했다면 그때는 클라이언트로부터 전화를 받은 서버가 전화를 클라이언트 컴퓨터로 되걸어 주어야 할 필요가 생긴다.
<그림7-15. RRAS - 포트 등록정보 >	그럴 경우를 고려한다면 추가로 <그림7-15>의 옵션을 체크해 주어야 한다. 관리콘솔의 왼쪽 패널의 서버이름 아래에 '포트'를 클릭하고, 등록정보를 연 다음 모뎀의 [구성]을 클릭하면 접근할 수 있다. 기본설정은 '원격 액세스 연결(인 바운드만)'으로 되어 있다. '필요시 전화접속 라우팅 연결(인 바운드 및 아웃바운드)'옵션도 체크를 해 주면 된다.

이것으로 RAS서버의 구성은 완료되었다. RAS서버는 구성하였지만 RAS서버에 접근할 사용자가 있어야 할 것이다. 당연하지만, 설정을 빠트리면 어떤 사용자도 RAS서버에 접근을 할 수 없게 된다.

윈도우 서버는 전화접속, VPN접속, 인터넷 연결공유, 라우터 등 다양한 기능의 연결서비스를 제공한다. 이번 장에서는 접속서버 기능과 정책, 인증서비스를 살펴보도록 한다. Windows Server 2003을 기준으로 설명하였지만Windows 2000 Server의 서비스와 기능이나 인터페이스 측면에서 큰 차이는 없다.

WINS서버를 사용하지 않고 라우트된 도메인 환경에서 서로간에 자원공유가 가능하도록 할 수 있을까? RFC 표준만 그대로 지원한다면 방법은 없다. 하지만 마이크로소프트는 추가로 Lmhosts 파일을 통해서 NetBIOS 이름풀이를 지원하고 있다.

<그림6-16>을 예제로 설명하도록 한다. 회사의 도메인 이름은 Color 이다. 이 회사는 서울과 대전으로 지역이 나뉘어 있고 서울에는 Red 라는 이름의 도메인 컨트롤러가 위치해 있다. 서울과 대전에는 각각 Blue와 White 라는 파일서버가 있고, 서울과 대전의 클라이언트들은 도메인으로 로그온을 하고 Blue와 White 2대의 자원을 공유해서 사용하고 있다. 지역별로 구분을 한 예제이지만 서울과 대전이라는 WAN 구간의 경우에 한정된 것은 아니다. 한 지역에서도 라우터로써 네트워크가 나뉘어 있는 상황이라면 <그림6-16>의 예제와 같은 형태로 볼 수 있다. 서울과 대전이라는 지역적인 측면보다는 2개의 서로 다른 네트워크라고 이해하도록 하겠다. WINS서버가 없더라도 같은 네트워크 안에서 클라이언트들은 서버를 찾는데 어려움이 없다. 브로드캐스트라는 차선의 방법이 제공되기 때문이다. 하지만, 문제는 자신과 다른 네트워크 즉 라우터 건너편에 존재하는 서버에게 접근하려면 그때는 문제가 생긴다. 브로드캐스트가 라우터를 넘지 못하므로 서버를 찾을 방법이 없는 것이다.

이것을 해결하기 위해서 클라이언트 컴퓨터에서 lmhosts 파일을 이용할 수 있다. lmhosts 파일은 %systemroot%\system32\drivers\etc 폴더에 위치해 있다. (%systemroot%는 NT기반의 컴퓨터에서는 winnt 폴더를 의미한다.) <그림6-17> 해당폴더에는 몇가지 파일이 더 보인다. 다른 파일들 역시 TCP/IP 환경에서 각각 필요에 따라 사용된다. lmhosts 파일을 자세히 보면 다른 파일과 다른 것을 알 수 있다. hosts, protocol 등의 파일과 비교해서 '종류'를 살펴보면 'SAM 파일'로 되어 있는 것을 알 수 있다. 다른 파일들은 확장자가 없지만 lmhosts 파일은 실제로는 lmhosts.sam 이라는 파일명을 가지고 있다. 윈도우탐색기에서 도구à폴더옵션à보기 메뉴에서 '알려진 파일 형식의 파일 확장명 숨김'옵션을 지워주면 확장자까지를 확인할 수 있다.

lmhosts 파일을 사용하기 위해서는 확장자를 지워줘야 한다. <그림6-17>을 보면 예제의 PC에서는 기본적으로 lmhosts 파일을 사용하지 않고 있음을 알 수 있다. 메모장을 사용해서 lmhosts.sam파일을 열어본다. 이 파일은 텍스트 파일이므로 텍스트를 읽을 수 있는 프로그램이면 뭐든 상관없다. 아래의 <그림6-18>은 메모장을 사용해서 열어본 파일을 보여준다.

파일에 대한 설명이 있고, 텍스트의 맨 앞에는 한결같이 '#'이 붙어 있다. 이것은 주석처리됨을 의미한다. 끝까지 읽어봐도 #이 붙어 있음을 알 수 있다. 기본적으로는 아무런 내용이 존재하지 않는 빈 파일과 같다. <그림6-11>의 파란박스부분을 보면 #PRE, #DOM 등의 문자들이 보인다. 여기서의 #은 의미를 가진다. 이러한 것들은 특별한 의미가 있는 '태그(tag)'들이다. 사용법은 파일에 기록된 설명을 참고하겠다. 그렇다면 이 파일을 어떻게 사용할까? 예제를 들어서 작성을 해 보자.

<그림6-16>의 예제에서 Green 이라는 컴퓨터의 사용자는 color 도메인으로 로그온 하기 위해서 도메인 컨트롤러인 Red를 찾아야 하고, Blue 라는 서버에 연결하여 자원에 접근도 해야 한다. 이것을 가능하게 하기 위한 방법은 Green 컴퓨터의 lmhosts 파일을 편집함으로써 해결할 수 있다. lmhosts 파일을 열고 <그림6-19>와 같이 기록을 하면 된다.

<그림6-19>화면에서는 blue 서버가 192.168.10.200 IP Address를 사용하고 있음을 기록했고, #PRE #DOM 태그를 이용하여 Color 도메인의 도메인 컨트롤러가 Red 이고 Red는 192.168.10.2 IP Address를 사용하고 있음을 나타내고 있다. 여기서 #DOM 은 도메인명을 지정해 주는 것이고, #PRE는 시스템 시작과 동시에 PreLoad 시키는 것을 의미한다. #PRE 태그를 이용하면 시스템이 시작될 때 #PRE 태그가 붙어 있는 라인의 내용을 메모리에 로딩을 하게 되고 이것은 시스템을 끌 때까지는 계속 메모리에 올라와 있게 된다. 또는 명령프롬프트에서 'nbtstat -R'을 이용해서 로딩 시킬 수도 있다. Green 컴퓨터에서 nbtstat 유틸리티를 이용해서 잠시 들여다 보자.

Lmhosts파일에 원하는 정보를 입력했다면 파일을 저장한다. 저장할 때 ‘다른 이름으로 저장’을 선택하여 lmhosts파일을 큰 따옴표로 묶어서 확장자 없이 저장한다. 그렇지 않으면 lmhosts.txt 파일로 저장되어 이 파일은 동작하지 않는다. Lmhosts.sam 파일에서 확장자만 제거해도 무방하다.

예제에서 서울에 있는 Black 컴퓨터가 대전의 White를 찾을 수 있도록 하기 위해서는 역시 Black 컴퓨터의 lmhosts 파일에 White 의 정보를 추가해 주어야 한다. WINS 서버를 사용하지 못할 때 해결할 수 있는 차선책이긴 하지만, 어디까지나 차선책일 뿐이다. 사실상 번거롭다. 수많은 클라이언트들을 관리해야 하는 관리자라면 이러한 작업들이 보통 귀찮은 작업이 아니다. lmhosts를 WINS 서버의 오류시 사용하게 될 백업 측면에서 접근을 하는 것 정도라면 고려해 볼만 하지만, lmhosts 파일보다는 WINS서버의 오류시 그것을 대체하게 될 WINS서버를 추가로 구현하는 방법으로 접근하는 것이 바람직한다고 생각한다. 

이러한 WINS서버 역시 장기적으로는 사용되지 않을 서비스이다. 현재 시점에서 만일 회사의 네트워크 환경이 Windows2000이상의 환경으로 완전히 전환되고(이것은 서버뿐이 아니라 클라이언트 시스템까지 Windows 2000, Windows XP등으로 바뀌는 것을 의미한다.) 도메인 환경이 구축되었다면, 더 이상 WINS 설정을 하지 않아도 좋다. 이들은 DNS 쿼리를 통하여 자원에 접근하는 것이 가능하기 때문이다. 또한 컴퓨터들의 TCP/IP설정에서 “TCP/IP에서 NetBIOS 사용안함”옵션을 활성화시키는 바람직하다. 이것은 불필요한 네트워크 트래픽을 상당부분 감소시켜 줄 수 있다. 하지만 지금은 분명히 이러한 점에 있어서는 과도기이다. 당분간은 여전히 이전 버전의 클라이언트들을 지원해야 하기 때문에 WINS의 존재는 분명히 필요하다. 제대로 WINS서비스를 잘 구성해 놓는것만으로도 여러분은 네트워크상에서 문제점이 상당히 줄어들었다는 실감할 수 있을 것이다.

앞에서 WINS서버를 설치하고 클라이언트를 설정하는 방법을 설명하였다. 지극히 쉬운 방법이지만 이렇게 설정해 놓은 WINS서버가 실패했을 경우 즉 서비스가 멈추는 상황이 발생한다면 큰일이 아닐 수 없다. 회사에서 WINS서버의 활용도가 크면 클수록 문제발생시의 불편함은 커지기 마련일 것이다. 네트워크 상에서 서비스가 구현이 될 때 관리자가 반드시 고려해 봐야 할 부분이 이러한 것이다. 서비스를 하던 서버가 멈췄더라도 여전히 클라이언트는 원하는 작업을 계속할 수 있어야 한다는 것이다. 바로 가용성(Availability)을 고려해야 한다는 것을 의미한다. 또 한가지는 회사에 하나의 서버가 있는데 서버가 수용하기 어려울 정도로 많은 사용자가 서비스를 요청한다면? 당연히 결과는 너무나 느린 응답시간 때문에 사용자들의 불만은 커질 것이고 심한 경우는 서버의 다운으로 까지 이어져서 네트워크가 마비되는 결과를 초래할 수도 있을 것이다. 가용성과 더불어 추가로 고려해야 할 사항이 바로 성능(Performance)이다. 이 두가지 사항을 감안하여 기업 네트워크 상에 어떻게 하는 것이 WINS서버를 구현하는 최선의 방법이 될 것인지 알아보도록 하자.

아래의 <그림6-11>를 보면서 접근해 보자. 예제그림은 서울에 본사가 있고, 부산에 지사가 있는 회사이다. 서울과 부산간에는 상대적으로 느린 WAN 링크를 이용하고 있고, 두 지역간에는 서로간에 자원을 공유해야 할 필요성이 있다. WINS서버를 구현하고자 하는데 가용성과 성능을 고려해서 최적화된 WINS 서비스를 구현하기를 원한다. WINS서버는 몇대를 두고 어디에 배치를 하고, 클라이언트는 어떻게 설정을 해 줘야 할까?

WINS 서비스의 가용성과 성능을 높일 수 있는 방법중 가장 일반적인 것은 서버를 여러대 배치하는 것이다. 하나의 서버가 서비스를 하지 못하더라도 다른 서버가 계속 서비스를 제공할 수 있기 때문이다. 두 대를 배치한다고 가정하면 서울에만 2대의 WINS서버를 두는 것보다는 지역마다 하나씩 두는 것이 바람직할 것이다. 그렇지 않으면 부산에 있는 WINS클라이언트가 자신의 NetBIOS 이름을 등록할 경우, 또는 다른 서버의 NetBIOS 이름해석을 요청할 때마다 상대적으로 느린 WAN 구간을 거쳐야 할 것이다. 여기서 우리가 고려해 보아야 할 점은 두 대의 서버가 각각 정상적으로 동작하고 있는 경우라면 가급적이면 WAN 트래픽이 발생하지 않도록 해야 한다는 것이다.

이를 해결하기 위해서 일단 서울에 WINS-A를 설치하였다. 그리고 서울에 있는 모든 컴퓨터를 WINS-A의 클라이언트로 설정하였다. 다음에 부산에 WINS-B를 설치하고 부산의 모든 컴퓨터를 WINS-B의 WINS클라이언트로 설정하였다. 이렇게 하면 서울에서의 WINS 트래픽은 서울지역에만 국한되고, 부산에서의 WINS 트래픽은 부산지역에서만 발생될 것이다.

여기까지만 구성하면 문제가 발생한다. <그림6-11>에서 부산의 WINS 클라이언트인 RED가 서울에 있는 BLUE 라는 이름의 서버를 찾고자 한다면 어떻게 될 것인지 생각해 보자. RED는 WINS-B에게 BLUE 라는 NetBIOS 이름을 쿼리할 것이다. 하지만 WINS-B는 BLUE의 IP Address를 알 수가 없다. 왜냐하면 BLUE는 자신의 클라이언트가 아니기 때문이다. BLUE의 레코드는 서울의 WINS서버인 WINS-A가 가지고 있을 뿐이다. 서울의 WINS서버와 부산의 WINS서버의 WINS Database는 서로 다르다. WINS-A는 서울의 WINS 클라이언트의 레코드를 가지고 있고, WINS-B는 부산의 WINS 클라이언트의 레코드를 가지고 있다. 서울과 부산간에 자원의 공유가 가능해 지려면 이 두 WINS서버들의 WINS Database가 교환될 필요성이 생긴다. 이 과정을 WINS Database 복제를 설정함으로써 가능하게 만든다.

이들 두 대의 WINS서버는 서로를 WINS Database 복제파트너로 설정하여 자신의 DB를 밀어주고(push partner), 상대방의 DB를 끌어오는(Pull Partner) 형태로 서로 다른 WINS Database를 하나로 통합할 수가 있게 된다. 이렇게 하면 부산에 있는 WINS Client가 자신의 WINS서버에게 서울의 레코드를 요청하더라도 올바른 응답을 받을 수 있게 된다. WINS 데이터베이스 복제파트너는 WINS 관리콘솔에서 '복제파트너'를 통해서 추가할 수 있다. <그림6-12>에서는 redapple이라는 이름의 WINS서버를 복제파트너로 추가하고 등록정보를 열어서 Pull / Push 복제 일정을 확인한 것을 볼 수 있다. 

 <그림6-13. WINS 복제 파트너 추가 >

복제파트너로 구성할 상대방 WINS서버의 이름이나 IP주소를 입력해야 한다. IP주소를 입력하는 것이 좋다.

이번엔 다른 측면을 고려해 보자. 만일 부산에 있는 WINS 서버가 멈춘다면 어떻게 될까? 당연한 얘기지만 부산지역의 WINS 클라이언트는 더 이상 WINS서버를 이용할 수가 없다. 그러면 그 클라이언트들은 부산지역의 서버를 찾을 때는 WINS서버를 이용할 수 없으므로 다음 방법인 브로드캐스트를 이용해서 검색을 할 수도 있겠지만 서울지역에 위치한 컴퓨터들을 찾고자 할 때는 실패할 수밖에 없게 된다. 그렇다면 이러면 되겠다. 부산에 있는 WINS서버가 동작하고 있을 때는 해당 서버를 통해서 서비스를 받고, 만일 부산의 WINS 서버가 문제가 있다면 서울의 WINS 서버를 사용하면 될 것이다. 그렇게 동작하도록 하기 위해서 부산의 WINS 클라이언트들에게 두 번째 WINS서버를 추가로 설정을 해 줄 수 있다. <그림6-15>의 빨간색 표기부분을 보면 2개의 IP Address가 설정되어 있다. [추가]버튼을 이용하여 WINS서버를 추가할 수 있고 오른편의 [화살표]버튼을 이용하여 쿼리순서를 결정할 수 있다. 물론 서울의 WINS 클라이언트들은 두 번째 WINS Server로서 부산의 WINS서버를 이용할 수 있도록 설정해 줘야 한다.

만일 네트워크에 비 WINS 클라이언트가 있다면 그들을 지원해야 할 필요가 있다. 비 WINS 클라이언트는 자신의 NetBIOS이름을 WINS 서버에 등록하지 않는다. 또, 다른 서버의 자원에 접근하기 위해서 NetBIOS이름풀이(name resolution)를 할 때도 역시 WINS서버에게 쿼리하지 않고 브로드캐스트를 이용한다. 아래의 <그림6-7>을 보면서 설명한다.

<그림6-7>의 예제에서는 라우터로서 분리된 2개의 브로드캐스트 도메인을 보여준다. 왼쪽의 세그먼트에는 WINS서버가 있고, WINS 클라이언트인 'Blue'라는 이름의 컴퓨터도 존재한다. 오른쪽의 세그먼트에는 왼쪽의 WINS Server의 클라이언트로 설정된 WINS 클라이언트도 있고, 'Red'라는 이름의 Non-WINS 클라이언트도 존재한다.

첫 번째 상황을 가정해 보자. 예제와 같은 환경에서 Blue가 Red의 자원에 접근을 하고자 한다(①). Blue의 사용자는 \\red\public 이라는 UNC 경로를 사용하여 red에 접근을 시도했다. red 라는 NetBIOS Name은 TCP/IP 통신을 위해서 당연히 IP Address로 매핑 (resolution)되어야 한다. blue는 WINS 클라이언트이므로 NetBIOS 이름풀이 방법으로써 WINS서버에게 요청을 하게 된다(②). 이 요청을 받은 WINS Server는 WINS Database에서 "Red <20>"이라는 NetBIOS 이름을 검색한다. 하지만 red의 레코드를 찾지 못한다. 이유는 Red가 Non-WINS 클라이언트이므로 자신의 NetBIOS Name을 WINS Server에 등록하지 않았기 때문이다. 결국 WINS 서버는 Blue에게 NetBIOS Name Resolution을 하지 못했다는 응답을 하게 되고, Blue는 그 다음 Resolution방법으로 브로드캐스트를 시도하게 된다. 그렇지만, 라우터로 네트워크가 분리되어 있고 Red 는 원격지의 네트워크에 위치해 있으므로 검색에 실패하게 된다. 결과적으로 Blue에서는 "네트워크 경로를 찾지 못했다."라는 에러 메시지를 확인하게 된다. 통신실패를 의미한다.

해결방법은 있다. 기본적으로 WINS 서버는 동적으로 동작하지만 관리자가 수동으로 레코드를 추가할 수도 있다. 정적매핑을 통하여 Red를 WINS 서버에 추가해 주면 된다. WINS 관리콘솔의 왼쪽 패널의 서버이름 아래에 있는 '활성등록'을 선택한 다음 마우스 오른쪽 클릭하여 '새 정적 매핑'을 선택한다. Red 의 IP Address를 할당해 주면 된다. <그림6-8>

<그림6-9>을 보면 정적 매핑으로 추가한 Red 의 레코드를 확인할 수 있다. 이제 WINS 클라이언트인 Blue는 WINS 서버를 통하여 Red 의 IP Address를 쿼리할 수 있게 되었다.

두 번째 상황도 고려해 보도록 하겠다. 이번에는 Non-WINS 클라이언트인 Red가 WINS 클라이언트인 Blue를 찾고자 할 때의 상황을 생각한다. Red의 사용자는 Blue의 Public 공유폴더에 연결하기 위하여 \\blue\public 이라는 UNC를 통해서 접근을 시도했다(③). Red 는 Non-WINS 클라이언트이므로 Blue의 NetBIOS 이름을 찾기 위해 WINS서버에게 쿼리하지 않는다. 브로드캐스트를 이용해서 이름풀이를 시도할 것이다(④). 당연히 라우터의 건너편 네트워크에 존재하는 Blue로부터 응답이 올 수가 없다. 역시 에러 메시지를 받게 될 것이다. 이것을 해결할 방법은 있다. 다행히 오른쪽 편의 네트워크에 WINS 클라이언트가 존재한다. 이 WINS 클라이언트가 Non-WINS 클라이언트를 대신해서 WINS 서버에 요청을 전달해 주게 구성할 수 있다. 이때 이러한 WINS 클라이언트를 가리켜서 'WINS Proxy Agent'라고 부른다. WINS Proxy Agent를 구성하기 위해서는 레지스트리를 직접 편집해 주어야 한다. WINS Proxy Agent로 구성할 시스템에서 레지스트리 편집기(regedt32.exe 혹은 regedit.exe)를 통해서 레지스트리를 열고 \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\ 키를 찾은후 'EnabledProxy' 값을 '1'로 설정하면 된다.<그림6-10>

뭔가 되긴 된 듯해 보이지만 석연찮은 구석이 있다. 이거 WINS 클라이언트가 아닌 녀석이 하나 끼어있으니까 이래저래 번거로운걸? 하는 생각이 들었다면 지금까지 내용을 잘 이해한 독자라는 생각이 든다. 방법은 있다. 아주 간단한 방법. Non-WINS Client를 두지 않고 전체 모든 시스템을 WINS 클라이언트로 만들면 모든 것이 해결된다. WINS솔루션을 구현하자. 하지 못할 이유가 없다.

위에서 WINS서버를 구현하는 방법이 가장 바람직한다는 말을 했다. 그렇다면 이제 WINS서버를 설치하고 구성을 해 보도록 하겠다. WINS서비스를 먼저 추가해 주어야 한다. 제어판àWindows구성요소 추가à네트워킹서비스àWINS를 통해서 추가할 수 있다.<그림6-4>

<그림6-4. WINS 서비스 설치 >

설치가 완료되면 그것으로 WINS서버의 준비는 끝났다. 다음엔 WINS서버에게 자신의 NetBIOS이름을 등록하고 다른 서버의 NetBIOS 이름을 쿼리할 수 있도록 클라이언트 셋팅을 해야 한다. ‘제어판à네트워크 연결’을 통해서 TCP/IP 등록정보를 연 다음, [고급]버튼을 클릭하면 WINS 탭을 볼 수 있다. [추가]를 이용하여 앞에서 WINS서비스를 설치한 서버의 IP Address를 입력한다. 예제에서는 192.168.0.16을 입력했다.<그림6-5>

클라이언트도 구성을 했다. 이것으로써 WINS서버와 WINS클라이언트 구성을 모두 마쳤다. 사실 설치는 너무나 쉽다. 그것보다는 이러한 서비스들의 필요성을 이해하는 것이 보다 중요한 일이라고 생각한다. 과정을 이해하면 보다 커다란 환경의 네트워크를 만나게 되었을 때도 적절히 대처를 하는 것이 용이할 것이기 때문이다. 이제 WINS서버쪽에서 WINS 관리도구를 열어보면 <그림6-6>에서 보는 것처럼 클라이언트가 등록되어 있음을 알 수 있다. 또 다른 WINS 클라이언트가 BLUEXP라는 NetBIOS 이름에 대한 IP Address를 요청한다면 이 WINS서버는 응답을 할 수가 있게 된다. 이러한 일련의 과정들은 동적으로 동작한다. 관리자는 WINS서비스를 추가해 주고, 네트워크 상의 모든 클라이언트를 WINS 클라이언트로만 구성해 주면 나머지는 WINS서비스가 알아서 처리한다. 말 그대로 ‘서비스’이다.

6-2-1. NetBIOS 이름 등록 및 해제

NetBIOS이름이 사용되기 위해서는 먼저 네트워크에 등록이 되어야 한다. 이름등록을 하는 방법으로는 두가지가 제공된다.

첫 번째 방법은 브로드캐스트를 이용하는 것이다. 시스템이 시작되고 NetBIOS 어플리케이션이 시작되게 되면 이름등록을 진행하게 된다. 이때 브로드캐스트를 통해서 네트워크에 자신의 이름을 등록하게 된다. 만일 사용하고자 하는 이름을 누군가 미리 등록해서 사용하고 있다.면 이름충돌의 에러메시지를 받게 되고, 해당 이름등록은 실패하게 된다.

두 번째 방법은 NetBIOS Name 서버에게 이름등록을 요청하는 방법이다. 네트워크에 브로드캐스트를 발생시키지 않으므로 보다 권장할 만한 방법이라고 하겠다. NetBIOS이름서버에게 이름등록을 요청하기 위해서 해당 시스템은 NetBIOS이름서버의 클라이언트로 설정되어야 한다.  NetBIOS 이름해제는 반대과정이다. 이것은 NetBIOS 어플리케이션이 중지될 때 발생하는 일이다. 결과적으로는 시스템이 셧다운 될 때 생기는 과정이라고 할 수 있다.

6-2-2. NetBIOS 이름 분해 요청 (Name Resolution Request)

이것은 클라이언트가 자원을 가진 서버의 NetBIOS이름에 해당하는 IP Address를 찾고자 할 때 발생한다. 파일서버의 자원에 접근하기 위해 서버를 검색할 때 혹은 도메인으로 로그온을 시도할 때 등등 여러 가지 상황에서 NetBIOS 이름요청이 활성화된다. NetBIOS 이름 요청 방법도 역시 두 가지가 제공된다. 첫 번째 방법은 브로드캐스트를 이용하는 것이고, 두 번째 방법은 NetBIOS 이름 서버를 통해 찾는 것이다.

하나의 시스템이 NetBIOS Name Server의 클라이언트로 셋팅되면 자신의 NetBIOS 이름을 등록할 때도 NetBIOS 이름 서버를 이용하고, 다른 시스템의 NetBIOS Name을 쿼리할 때도 역시 NetBIOS 이름 서버를 이용한다. 그렇지 못한 클라이언트라면 브로드캐스트 통신방법을 사용하여 NetBIOS 이름을 찾으려는 시도를 한다.

아무런 설정이 필요없이 통신을 위한 기본작업인 “이름을 가지고 주소를 찾기”라는 과제를 해결해 줄 수 있다는 측면에서는 브로드캐스드가 편한 방법이라고도 생각될 수 있지만 그렇게 되면 라우터로 분리된 네트워크에서 라우터 건너편 노드의 NetBIOS이름을 찾는 것은 불가능한 일이 된다. 또 노드수가 많아진다면 그만큼 네트워크에 브로드캐스트가 많아지므로 결과적으로 네트워크에 전체적인 성능저하까지 가져올 수 있게 된다. 따라서 기업 네트워크에서 NetBIOS이름을 필요로 하다면 NetBIOS 이름서버를 사용하는 것이 보다 바람직한 방법이다. 마이크로소프트는 NetBIOS 이름서버로서 WINS (Windows Internet Name Service)서버를 제공해 주고 있다.

BIOS (Basic Input Output System)는 컴퓨터에서 각종 디바이스들의 입출력을 담당하는 표준시스템이다. 컴퓨터 한 대만 있는 환경이 아닌 네트워크 환경을 고려해보면 이것만으로는 부족한다는 것을 알 수 있다. 하나의 시스템에 국한된 환경이 아니라 컴퓨터 대 컴퓨터간의 입출력을 처리해야 할 필요성이 생겼다. 이에 IBM은 Network에서 구현되는 BIOS를 개발했다. 이것이 NetBIOS이다. 이것은 네트워크에 있는 시스템들간의 통신을 위한 컴퓨터 이름 관리, 그리고 지속적인 통신을 위한 세션유지 등을 처리하고 실제 패킷을 전송할 책임이 있는 프로토콜을 호출하는데 필요한 일련의 방법들을 제공하고 있다. 하나의 어플리케이션이 네트워크 상에 있는 다른 컴퓨터의 어플리케이션에게 데이터를 주고 받는 데 필요한 네트워크 통신 부분과의 연결지점 역할을 담당하는 것이다.

그렇다면 이들 NetBIOS 프로토콜을 사용하는 어플리케이션이 상대방 컴퓨터를 찾을 때는 어떤 이름을 사용할까? 그것 역시NetBIOS 표준이름 구현을 통해서 상대방 시스템을 찾게 된다. 이러한 이름체계 역시 NetBIOS 라는 표준에 맞도록 정의되어 있다.

NetBIOS는 16byte로 구성이 되어 있지만 실제로 컴퓨터 이름으로 할당할 수 있는 바이트수는 15바이트로 제한된다. 마지막 16byte째의 플래그는 특별한 용도로 사용된다.

하나의 서버가 하는 일은 다양하다. 예를 들어 네트워크에 자신의 자원을 제공해 줄 수 있는 역할인 '서버 서비스'를 하고 있고, 자신도 클라이언트로서 다른 자원에 접근할 수 있는 '워크스테이션 서비스'도 하고 있고, 또 도메인 컨트롤러라면 도메인 사용자들의 로그온을 처리해 주는 '로그온 서비스'도 하고 있고, 다른 서버로부터 알림 메시지를 받기 위한 '메신저 서비스'도 하고 있을 것이다. 이러한 각각의 서비스를 구별하기 위하여 16byte째의 플래그가 사용된다. 이 16번째의 플래그는 1byte를 차지하며 2자리수의 Hexadecimal (16진수) 값으로 만들어지고 각각 서비스 타입별로 숫자가 지정되어 있다. 자주 볼 수 있는 플래그를 정리해 보면 다음과 같다.

<표6-1. NetBIOS Name Flag >

아래의 <그림6-2>은 windowsnetwork 도메인에서 도메인 컨트롤러로 셋팅된 blueapple이라는 이름의 서버에서 nbtstat 명령어를 통해서 blueapple 서버가 등록해서 사용하는 NetBIOS 이름들을 살펴 보았다. Blueapple이라는 이름이 여러개 등록되어 있는 것이 보이고 이름의 뒤쪽에는 <00> <20>등의 숫자가 보인다. 이것이 NetBIOS이름의 16번째 byte에 해당하는 플래그이다. 그리고 이것은 blueapple서버가 어떤 서비스를 하고 있는지 서버의 역할을 나타낸다.

실제로 이러한 NetBIOS 이름이 어떤 경우에 사용되는지 예를 들어보자. 클라이언트가 blue라는 이름의 서버의 공유폴더에 접근하고자 한다면 사용자는 '\\blueapple\공유이름' 의 형태로 접근을 하게 된다. 이때 실제로 네트워크 상에 요청을 확인해 보면 'BLUEAPPPLE <20>'을 찾는 것을 확인할 수 있다. 서버로서의 blueapple을 찾는 요청이기 때문이다. 또, Windows98혹은 NT4.0 사용자가 windowsnetwork 도메인으로 로그온을 시도한다면 도메인에서 로그온을 받아주는 서버, 즉 도메인 컨트롤러를 찾아야 한다. 그때의 요청은 실제로는 'WINDOWSNETWORK<1C>'가 된다.

이렇듯 클라이언트가 특정 서버의 NetBIOS 이름을 찾기 위해서는 선행되야 할 일이 있다. 당연히 네트워크에 서버의 NetBIOS이름이 등록되어 있어야 찾을 수가 있을 것이다. 그렇다면 서버는 어떤 방법으로 네트워크에 자신의 NetBIOS 이름을 등록하는 것일까? 또, 클라이언트는 어떤 방법으로 네트워크에 등록된 NetBIOS 이름을 찾을 수가 있는 것일까? 여기서 WINS의 필요성은 출발 할 수 있다.

마이크로소프트는 자사의 네트워크에서 NetBIOS를 채택하고 꾸준히 이를 지원해 왔다. 그리고 NetBEUI (NetBIOS Extended User Interface)프로토콜을 개발하여 NetBIOS를 지원했다. NetBEUI는 NetBIOS를 지원하기 위해서 개발된 프로토콜이므로 NetBIOS를 완전하게 지원할 수 있는 잘 동작하는 프로토콜이다. 하지만 이 프로토콜의 통신방법은 NetBIOS 이름기반의 브로드캐스트에 의존하고 있고, 이것은 라우터로 브로드캐스트 도메인이 분리된 확장된 네트워크 환경에서는 큰 문제점을 안고 있다. 라우팅이 되지 않기 때문에 네트워크의 확장성이 매우 떨어지게 되는 단점이 있는 것이다. 더불어 인터넷 표준 프로토콜로써 TCP/IP프로토콜이 사용이 되고 회사의 네트워크가 더 이상 로컬 LAN에만 국한되어 단순히 파일이나 프린트 공유정도만을 요구하지는 않는다. 대부분의 시스템에서 인터넷에 접근을 하는 것이 기본적인 사항이 되어가고 있으니 NetBEUI를 사용하는 클라이언트라도 추가로 TCP/IP를 설치하여 사용할 필요성이 생기게 되었다. 마이크로소프트 역시 TCP/IP를 지원하고 있다.

여기서 한가지 고려해 봐야 할 것이 있다. NetBIOS 어플리케이션은 브로드캐스트 통신방법에 기초한 NetBIOS이름을 이용해서 통신을 한다. 하지만, TCP/IP환경에서는 IP Address로써 각각의 시스템을 구분하고 IP Address를 근거해서 통신을 한다. 마이크로소프트에서 TCP/IP를 지원한다고 하더라도 여전히 기존의 어플리케이션이 NetBIOS를 필요로 하고 있고, 이것을 TCP/IP에서도 지원해 주어야만 호환성에 문제가 발생하지 않을 것이다. 그래서 TCP/IP 프로토콜의 구조를 살펴보면 'NetBT'라는 프로토콜이 포함되어 있음을 알 수 있다. NetBIOS over TCP/IP를 줄인 표기이다. TCP/IP상에서 NetBIOS를 구현하기 위한 인터페이스를 제공하고 있다.

위에서 보듯이 NetBIOS 어플리케이션들은 NetBT 인터페이스를 통해서 TCP/IP의 TCP나 UDP를 호출하는 것이 가능해진다. 그렇지만 통신상에서 구별하는 이름에는 여전히 차이가 있다. NetBIOS 어플리케이션에서는 NetBIOS이름을 통해서 상대방 시스템을 찾으려 시도할 것이고, TCP/IP 프로토콜에서는 그러한 이름을 알 수가 없다. 누군가가 이 문제점을 해결해 주어야 한다. 이것을 해결하기 위한 인터넷 표준이 두 가지 마련되어 있다. 하나씩 알아보도록 하자.

마이크로소프트의 네트워크 환경에서 여러 가지 서비스를 하는 서버들이 있지만, 역시 빼 놓을 수 없는 서비스가 하나 있다. Windows NT4.0 에 비하면 Windows 2000 환경에서는 그 역할이 많이 줄어들었지만 여전히 기업네트워크에서는 중요한 서비스중 하나임에는 틀림없다. WINS서버가 왜 필요하고, 네트워크에서 수행하는 역할은 무엇인지, 최적화된 관리방법은 무엇인지 차근차근 접근해 보도록 하겠다.

5-6-1. DNS Round Robin (라운드 로빈) 구현

당신의 회사가 쇼핑몰을 운영하고 있다고 가정을 하자. 당연히 회사에서는 웹서버가 적절한 성능을 제공해야만 할 것이다. 1대의 서버만 운영하다가 사용자들이 느린 성능문제로 불만이 많아짐에 따라 1대의 웹서버를 증설하고 동일한 컨텐츠로서 웹서버를 셋팅해 두었다. 그 다음에 해야 할 일은? 당연히 쇼핑몰을 찾는 클라이언트들이 두 대의 서버를 찾아올 수 있도록 구성을 해 주어야 할 것이고, 거기다가 가급적이면 골고루 찾아올 수 있게 해 줄 필요가 있을 것이다. 이때 가장 저렴하고 간단하게 구현할 수 있는 방법이 DNS서버의 Round robin 기능을 이용하는 것이다.

사실 DNS가 하는 일이 복잡한 기능은 아니다. 단지 누군가가 이름을 물어왔을 때 그 이름의 서버가 어디에 있는지를 가르쳐 주면 되니까. 하지만 그것이 네트워크에서 차지하는 비중은 엄청나다 할 것이다. 제아무리 웹서버가 안정적으로 구현되어 있다고 하더라도 DNS서버가 부실하면 사용자들이 그 웹서버까지 찾아갈 수가 없기 때문에 무용지물이 되고 마는 것이다. 웹서버 두대를 설치해 두었다면 클라이언트들은 그 웹서버를 찾기 위해 DNS쿼리를 하게 될 것이고 그때 DNS서버는 두개의 웹서버를 번갈아 찾아갈 수 있도록 해 주면 될 일이다. 이론상으로 이해하면 너무나 쉬운 기능이다. 구현하는 것도 역시 간단하다.

그림은 DNS관리콘솔의 서버이름을 마우스 오른쪽 클릭하여 등록정보를 열었을때의 화면을 캡처한 것이다. ‘고급’탭을 확인하면 위와 같은 화면을 볼 수 있다. 하이라이트된 부분을 보면 “라운드 로빈 사용”이라는 옵션이 보인다. 기본적으로 Windows2000 DNS서버는 이 옵션이 활성화되어 있다. 다음에 할일은 웹서버 두대에 대한 www 레코드를 생성해 주면 된다. 주의할 것은 www 라는 레코드는 CNAME 레코드로 만들어서는 안 된다는 것이다. www라는 동일한 이름의 A (Address)레코드를 두 개 만들어 준다. <그림5-75>에서는 secure.pe.kr 도메인에 www레코드가 두개 생성되어 있고 두개의 레코드는 각각 다른 IP Address가 설정된 것이 보인다. 웹서버 두대에 대한 레코드가 만들어진 것이다.

이렇게 간단히 DNS만으로 웹서버 두대를 효율적으로 운영할 수 있다는 장점이 있기는 하지만 이 DNS라운드 로빈을 이용하는 방법은 한가지 단점을 가지고 있다. 만일 하나의 웹서버가 다운이 되었다면 관리자는 다운된 서버의 IP에 해당하는 www 레코드를 DNS영역에서 삭제를 하게 될 것이다. 그렇게 해서 잘 동작하는 다른 웹서버로만 요청이 가도록 하기 위함인데, 그것이 마음같이 움직여주지는 않는다. 이 DNS서버로부터 www레코드가 2개라는 사실을 응답받은 상대방의 DNS서버는 그 정보를 자신의 서버에 캐쉬한다. 캐쉬의 TTL이 만료될때까지는 새롭게 요청이 오는 것이 아니라 기존 DNS정보를 그대로 사용하기 때문에 현재는 동작하지 못하는 웹서버로 계속해서 클라이언트들의 요청이 올 수도 있다는 것을 의미한다. www 레코드의 TTL을 “0”으로 만들어 주면 문제는 줄어들지만, 몇몇 ISP의 DNS서버들이 캐쉬를 임의로 길게 설정하여 사용하는 경우가 있기 때문에 그 동안에는 현재 동작하지 못한 웹서버의 IP를 담고 있는DNS로부터 웹서버의 IP주소를 얻은 웹클라이언트들은 웹서버에 접근할 수 없게 된다.

이것은 어디까지나 문제가 되는 상황을 가정했을때의 상황이고 보통의 경우에는 큰 탈없이 운영할 수가 있다. 한번쯤 고려해 볼 만한 방법이다. 그러나 회사가 인터넷쇼핑몰 등을 운영하는 것으로서 수익을 얻고 있는 경우라면 이러한 방법을 써서는 불안하다. 웹서버가 몇시간 다운 되는 상황이 생기면 그것은 바로 회사의 금전적인 손해로 이어지기 때문에 심각한 문제가 될 수도 있기 때문이다. 이럴 경우는 NLBS (Network Load Balancing Service), L4스위치를 이용한 로드밸런싱을 구현하는 것이 올바른 방법이라 할 것이다.

5-6-2. DNS서버 보안의 기본

여러분의 네트워크를 누군가가 공격할 준비를 하고 있다고 가정하자. 공격자는 어떤 작업을 먼저 해야 할까? 네트워크에 어떤 컴퓨터들이 있는지를 파악하는 것은 아주 기본적인 작업이 된다. DNS서버는 네트워크에 존재하는 컴퓨터들의 각각의 역할과 IP Address를 가지고 있어서 사내의 컴퓨터들의 역할을 짐작할 수 있게 해 주기 때문이다. DNS서버는 기본적으로 이러한 위험에 노출되어 있다. Nslookup을 통한 테스트결과를 설명과 함께 기록하였다.

이 “영역전송허용”의 기본값은 ‘아무서버로’로 되어 있다. 이것은 주DNS서버와 보조DNS서버간의 영역전송을 가능하게 만들어 주는데, 보조DNS서버가 없다면 아예 해제를 할 일이고 만일 보조DNS서버가 있다면 특별히 보조DNS서버의 IP Address를 기록하여 영역전송이 가능하도록 해 주어야 한다.

5-6-3. DNS서버의 백업파일로부터 복구

DNS서버를 관리할 때는 DNS관리메뉴를 통해서 GUI환경에서 관리되지만 이것은 실제로는 파일단위로 동작한다. %systemroot% (일반적으로는 winnt 폴더를 가리킨다.)아래의 system32\dns 폴더를 확인하면 DNS관리콘솔을 통해서 추가한 관리영역에 해당하는 DNS파일을 확인할 수 있다. 이 파일만 백업하여 유지하고 있다면 언제든지 관리자는 파일로부터 DNS영역을 복구하는 것이 가능하다.

백업된 파일로부터 DNS영역 설치과정은 다음의 절차를 따른다.

1 단계, 백업받아둔 파일을 %systemroot%\system32\dns 폴더에 저장한다.

2단계, 영역추가과정은 일반적인 방법과 다를바가 없다. 다만, ‘영역파일’선택화면에서 기본설정인 ‘다음 이름으로 새 파일 만들기’대신에 ‘다음 기존 파일 사용’옵션을 선택한다. <그림5-77참고>

5-6-4. DNS서버 캐쉬 삭제하기

DNS서버는 클라이언트의 DNS쿼리를 받은후 상대방 DNS서버로부터 레코드정보를 얻은후 로컬DNS캐쉬를 유지한다. 클라이언트로부터 동일한 레코드에 대한 요청이 들어올 때 캐쉬로부터 응답함으로써 효율성을 높이기 위함인데 가끔은 이런 캐쉬 때문에 말썽이 생길수도 있다. 계속해서 DNS서버가 오동작을 한다라고 생각이 되었다면 그때는 DNS서버의 캐쉬를 삭제해 줄 필요가 있다. DNS관리콘솔에서 서버이름을 클릭하고 마우스 오른쪽 버튼을 누르면 ‘캐시 지우기’를 이용할 수 있다.

5-5-1. DNS Server 모니터링 툴

DNS Server가 시작되어 있는데 제대로 응답을 하지 못하다면, Windows Server 2003 DNS Server가 제공하는 모니터링 툴을 사용하여 상태를 점검해 볼 수 있다. <그림5-72>을 통해서 접근한다.

<그림5-73>의 '테스트종류선택'에서 '이 DNS서버에 대한 단순쿼리'를 선택하고 <지금테스트>버튼을 누르면 클라이언트의 요청에 응답할 수 있는지를 파악할 수 있다. 그림에서는 '성공'이라는 결과를 보여준다. '다른 DNS서버로의 재귀쿼리'를 선택하고 <지금테스트>버튼을 누르면, 해당 DNS Server가 외부로 root name server(그림에서 루트힌트 탭에 리스트된 서버들)로 쿼리를 보낼 수 있는지를 파악할 수 있다. 역시 '성공'이라는 결과를 보여주고 있다.

문제가 발생했다면, ’관리도구à이벤트표시기àDNS Server’ 항목을 통해서 문제점을 볼 수 있다. DNS Server오동작의 상당부분은 DNS Service재시작을 통해서 해결된다. 명령프롬프트를 열고 "net stop dns"를 실행하고,다시 "net start dns"를 입력하면 DNS Server Service를 재시작할 수 있다.

5-5-2. NSLOOKUP

DNS를 진단하는데 있어서 대표적인 유틸리티라고 할 수 있다. NSLOOKUP을 사용하는 방법으로는 크게 2가지를 들 수 있다. Interactive(대화형)와 non-interactive(비대화형)로 나누어 사용해 본다.

5-5-2-1. Non-Interactive

호스트이름이든 IP Address이든 원하는 정보를 그대로 물어보는 가장 간단한 사용법이다. 단순한 정보를 알아보는 데 효과적인 방법이라고 하겠다. 아래의 표에서는 사용방법을 보여주고 있다. 명령프롬프트에서 작업한 내용을 편집하여 옮겼다. 굵게 표기한 부분이 필자가 직접 입력한 부분이고, 나머지는 명령에 따른 결과이다.

5-5-2-2. Interactive

대화형으로 접근하여 보다 자세한 레코드를 요청하고, 어느 서버가 문제가 있는 것인지를 진단해 볼 수 있는 방법이다. 아래의 표를 예제로 설명을 하겠다. 역시 명령프롬프트를 통해서 접근한다. 사용법을 꼭 익혀두자. DNS서버의 문제점을 해결할 때 아주 유용한 유틸리티이다.(참고: 진한색으로 표기된 부분이 직접 입력한 부분이며, 그밖은 명령에 의한 결과값이다. 괄호로 묶인 부분은 필자의 부연설명이다.)

5-5-3. ipconfig/flushdns

Windows 2000은 클라이언트에서도 DNS서버로부터 얻은 호스트이름에 대한 응답을 캐쉬에 저장한다. 간혹 이것 때문에 문제를 일으킬 수도 있다. 잘못된 정보를 제공받은 클라이언트가 DNS서버에서 레코드가 바뀌었음에도 불구하고 계속해서 캐쉬로부터 잘못된 정보를 사용하게 됨으로써 정상적인 이름풀이를 하지 못하는 상황이 있다. 이런 경우 클라이언트의 cache를 비워주는 명령어를 사용하면 된다. 아래의 표를 참고하자.

5-4-1. DNS Zone Transfer

앞에서 DNS서버 셋업에 관련된 작업을 다루어 보았다. 하나의 DNS Server를 가지고 있는 회사가 있었는데 만일 그 서버에 이상이 생겼다면 어떻게 될까? 당연히 외부에서의 접근도, 내부에서 외부로의 연결도 하지 못하게 될 것이다. 또, 조직이 아주 커서 하나의 DNS Server로써 모든 클라이언트의 요청을 효율적으로 처리하기가 어려운 상황이 되었다면 어떻게 해야 할까? 당연히 결론은 "추가 DNS Server"를 설치함으로써 DNS서버 이중화를 고려해야 할 것이다. 하지만, 한가지 고려되어야 할 점은 그 추가 DNS Server는 반드시 첫 번째 DNS Server와 동일한 레코드를 가지고 있어야 하다는 것이다. 그래야만 DNS 클라이언트의 요청을 각각의 DNS서버가 처리하더라도 클라이언트는 동일한 응답을 받을 수 있을 것이기 때문이다.

그렇기 때문에, 회사에서 백업을 고려하여 위해서 추가 DNS서버를 셋업하는 것은 첫 번째 DNS 서버의 설치와는 다르다. 첫번째 DNS서버가 가지고 있던 원본을 복제하는 작업을 해야 하고, 그런 이유로 당연히 첫 번째 서버가 정상적으로 동작하고 있는 상태에서 추가할 수 있다. 이때 백업서버를 가리켜서 Secondary DNS Server라고 부르고, 그 서버가 가지고 있는 도메인영역을 Secondary Zone(보조영역)이라고 부른다.

5-4-1-1. Secondary DNS Server 설치

예제에서는 REDAPPLE라는 이름의 서버에 DNS Service를 추가하고, secure.pe.kr 도메인을 관리하는 Secondary DNS Server를 구성하고자 한다. 이 과정이 성공적으로 진행되기 위해서는 원본을 가지고 있는 DNS Server에서는 Zone database를 전송해 줄 수 있도록 보안설정이 되어 있어야 한다. <그림5-67>의 Zone등록정보를 통해서 확인할 수 있다. 그림에서는 192.168.0.47 IP주소를 가진 DNS서버에게 영역전송을 허용하도록 설정했다. Secondary DNS서버의 IP주소이다.

준비가 되었으면 이제 Secondary DNS Server를 설치해 보자. 과정은 지난 장에서 소개한 것과 큰 차이가 없으므로 어렵지 않을 것이다.

< 그림5-57. Secondary DNS서버에 DNS Zone 추가 1 >	‘정방향 조회 영역’에서 마우스 오른쪽 클릭하고 ‘새 영역’을 선택한다.
< 그림5-58. Secondary DNS서버에 DNS Zone 추가 2 >	다음 그림에서 "보조영역"을 선택해야 한다. 보조DNS서버를 추가하기 위한 과정이다.
< 그림5-59. Secondary DNS서버에 DNS Zone 추가 3 >	영역이름을 먼저 추가해야 한다. 현재 설치하고 있는 DNS서버가 Primary DNS서버의 DNS 클라이언트로 되어 있다면 <찾아보기>를 통해서 접근할 수도 있다. 별 차이는 없다. 이름항목에 정확히 도메인명을 입력한다.
< 그림5-60. Secondary DNS서버에 DNS Zone 추가 4 >	마스터 DNS서버의 IP를 주어야 한다. 마스터DNS서버는 영역의 원본을 제공해 줄 수 있는 DNS서버를 의미한다. 먼저 설치했던 blueapple.secure.pe.kr의 IP주소를 입력했다.
< 그림5-61. Secondary DNS서버에 DNS Zone 추가 5 >	이제 secondary DNS의 설치가 완료되었다.