DHCP서비스를 구현하기 전에 가장 먼저 할 일은 네트워크에서 IP Address관리방법에 대한 결정이 있어야 한다. 클래스 전체를 하나의 네트워크에서 쓸 것인지, 서브넷팅을 통해서 사용을 할 것인지에 대한 결정이 되었다면 이번에는 각 네트워크마다 사용할 호스트ID의 범위중에서 어떠한 IP를 라우터에게 할당을 하고, 어떠한 IP를 서버들에게 할당을 할 것이고, 어떠한 IP를 DHCP를 통해서 클라이언트에게 할당한 것인지 등을 결정하는 과정을 의미한다. 간단하게 A회사의 IP Address 관리테이블을 만들어 보았다.

<그림4-4. A회사 IP Address 관리 테이블>

이제 클라이언트를 위한 DHCP서비스를 구현해 보도록 하겠다. 네트워크에는 DHCP서버가 있어야 하고, 당연히 클라이언트도 구성이 되어야 한다. DHCP서버는 네트워킹 서비스이므로 서버제품군에서 구현될 수 있다. 먼저 DHCP서버를 설정해 보겠다.

Windows Server 2003이 설치될 때 DHCP, DNS 등의 네트워크 서비스는 기본적으로 설치되지 않는다. 구현을 하고자 할 때 추가로 설치를 해야 하는데 제어판의 프로그램 추가/제거를 통해서 설치할 수 있다.

4-2-1. DHCP서비스 설치

제어판의 프로그램추가/제거를 열고 "Windows구성요소 추가"를 선택하면 잠시후 "Windows구성요소"창이 열린다. 리스트를 찾아보면 "네트워킹 서비스"가 있는데 이것은 DHCP, DNS, WINS 등의 네트워킹 서비스들 전체의 묶음이다. -네트워킹 서비스 앞의 체크박스를 클릭하면 전체 네트워킹 서비스들이 설치가 되므로 체크박스 대신에 글자 부분을 클릭한다.- <자세히>버튼을 누르면 리스트에서 "DHCP(동적 호스트 구성 프로토콜)"를 찾을 수 있다. 체크하고 <확인>을 누르면 설치를 시작한다. Windows서버의 원본CD-Rom이 요구된다. 원본CD중에서도 i386 폴더가 셋업을 위한 폴더이다. 원본CD위치를 묻는 메시지가 뜬다면 원본CD를 넣고 i386폴더를 지정해 주면 셋업이 시작된다.

잠시후 설치가 끝났다는 메시지가 나오면 DHCP서비스가 추가된 것이다. 관리도구에 "DHCP" 라는 관리메뉴가 추가된 것을 볼 수 있는데, 클릭하면 <그림4-6>과 같은 그림을 만날 수 있다.

그림을 보면 친절하게도 오른쪽 패널에 설치방법에 대해서 설명을 해 주고 있다. 그리고 왼쪽패널의 서버이름 부분을 보면 아래쪽으로 향한 빨간색 화살표를 확인할 수 있다. DHCP서비스가 멈춰져 있다는 것을 말한다.

4-2-2. DHCP권한부여 작업 - (Active Directory 도메인 환경에서만 적용됨)

<그림4-6>에서 오른쪽 패널의 설명을 읽어보면 "DHCP서버가 IP 주소를 발급하기 전에 범위를 만들고 DHCP서버에 권한을 부여해야 합니다"라고 이야기한다. 범위라 하면 클라이언트들에게 발급할 IP Address를 구성하라는 뜻인 것 같은데, 권한을 부여하라구? 이렇듯 Windows Server 2003 DHCP서비스는 설치만 한다고 동작하는 것이 아니다. DHCP서버가 동작할 수 있도록 권한이 부여가 되어야만 DHCP서버는 동작을 하게 된다.

이것은 아무나 할 수 있는 작업은 아니다. 도메인에서 이러한 작업을 할 수 있는 사용자는 기본적으로 "관리자"로 제한된다. 정확히 말하면 도메인의 "Enterprise Admins"라는 그룹의 멤버가 이러한 작업을 할 수 있다.

이것은 어디까지나 회사의 네트워크 환경이 Active Directory도메인으로 구성되어 있을 때의 상황이다. 만일 회사가 도메인 모델을 채택하지 않고 워크그룹 환경으로 구성되어 독립된 서버에서 DHCP서비스를 구현하고 있다면 이 과정은 건너 뛰고 바로 다음 작업인 DHCP서버 구성으로 넘어간다.

DHCP서버에 권한을 부여하기 위해서는 DHCP관리콘솔을 이용한다. 관리콘솔에서 서버이름을 클릭하고 마우스 오른쪽 버튼을 누른후 "권한부여"를 선택하면 간단히 권한이 부여된다. 권한이 부여된 DHCP서버의 리스트를 확인하거나, 여러대의 DHCP서버를 관리하고자 한다면 다른 방법도 있다. 관리콘솔에서 DHCP항목을 클릭하고 마우스 오른쪽 버튼을 누르면 "권한이 부여된 서버관리"라는 메뉴를 볼 수가 있다<그림4-8>

<그림4-8>의 메뉴를 클릭하면 Active Directory에서 권한이 부여된 DHCP서버의 리스트를 볼 수가 있고 다른 DHCP서버에게 권한을 부여하거나 리스트에서 DHCP서버를 제거하는 것도 가능하다.

DHCP서버에게 권한을 부여하고 나면 관리콘솔의 왼쪽패널의 서버이름 옆에 위로 향한 녹색 화살표를 확인할 수 있다. DHCP서비스가 시작된 것이고, 오른쪽 패널의 설명도 처음 DHCP서비스를 추가했을 때와는 다른 설명을 보여주고 있다. <그림4-10>

4-2-3. DHCP서버 구성

DHCP서비스가 시작되면 DHCP서버는 브로드캐스트를 통해서 DHCP Discover 메시지를 날리는 클라이언트에게 IP Address를 발급해 주어야 하는데 이렇게 하기 위해서는 당연히 DHCP서버는 클라이언트를 위한 IP Address Pool을 가지고 있어야 한다. IP Address 발급을 위한 범위를 만들고 클라이언트를 위한 추가설정을 해 주어야 하는 것이다.

예제에서 DHCP서비스를 하는 blueapple이라는 서버는 192.168.5.0 네트워크를 위해 IP를 발급하고자 한다.

서버이름을 클릭하고 마우스 오른쪽 버튼을 눌러서 "새 범위"를 추가한다. 

범위이름을 입력해야 하는데, 이것은 실제 서비스와는 아무런 상관이 없다. 관리자가 알아보기 쉽게 이름과 설명을 주면 된다. 여러개의 네트워크를 DHCP서버가 지원해야 할 때 각각의 범위를 구별하기 쉽게 이름을 부여한다. 예제에서는 '2층 네트워크'라고 입력했다. 

DHCP클라이언트에게 발급할 IP Address의 범위와 적합한 서브넷마스크를 입력해야 한다. 하나의 DHCP서버는 하나의 네트워크당 하나의 IP범위 관리영역만 가질 수가 있다는 것을 염두에 둔다. 만일 192.168.5.11~100까지가 DHCP클라이언트용 IP Address라고 가정을 했을 때, 51~60까지가 서버들에게 고정IP로 발급한 부분이라서 제외해야 한다고 하더라도 192.168.5.11~50까지의 하나의 범위를 만들고 추가로 192.168.5.61~100까지의 영역을 만들 수는 없다. 그럴 경우에는 일단 전체범위를 잡은 다음에 고정IP로 사용할 IP가 범위에 포함되어 있다면 다음 과정에서 그 특정범위만큼을 제외하는 방법을 사용해야

필요하다면, IP범위중에서 제외할 특정 IP나 IP범위를 추가한다. DHCP서버는 단순한다. 클라이언트가 IP를 요청했을 때 자신의 IP범위중에서 사용가능한 IP를 골라서 망설이지 않고 IP 발급을 한다. 만일 Web서버에게 192.168.5.20 IP Address가 셋팅되어 있다고 가정을 했을 때, DHCP서버의 설정에192.168.5.20 IP가 사용가능한 상태로 되어 있다면 DHCP클라이언트는 192.168.5.20 IP를 발급받게 된다.

이 경우 네트워크에서 이미 사용되고 있는 IP를 발급받은 해당 클라이언트는 정상적으로 TCP/IP를 사용할 수가 없게 된다. 관리자가 해결해 주면 되겠지만 간혹의 경우에는 먼저 이 IP Address가 설정된 Web 서버가 제대로 동작하지 못하는 경우가 발생할 수도 있으므로 IP Address의 충돌이 생길 소지가 있는 부분에는 특별히 신경을 써야 한다.

Windows2000 이상의 서버에서 DHCP서비스를 구현한다면 서버의 고급옵션에서 ‘충돌감지시도횟수’를 할당하여 DHCP클라이언트에게 IP를 할당하기 전에 먼저 IP사용유무를 테스트하게 할 수도 있다. 이번장의 후반부에서 다시 한번 언급된다.

<그림4-14>에서 보듯이 제외할 주소를 추가하는 방법은 두가지이다. IP Address를 하나씩 추가할 수도 있고, 범위를 지정해서 추가하는 방법이 있다.

클라이언트에게 IP를 발급할 때 결정해 줄 임대기간을 지정한다. 기본값은 8일이다. 임대기간이 길어질수록 IP Address 갱신주기가 길어질 것이기 때문에 IP Address가 충분히 여유가 있다면 기간을 더 길게 설정하는 것이 좋다. 네트워크에서 DHCP트래픽의 비중은 극히 일부분이지만 DHCP 관련된 네트워크 트래픽을 최소화 할 수 있는 방법이 된다. 반대의 상황이라면? 당연히 기간을 줄여야 할 것이다.

지금까지 위에서는 클라이언트에게 발급할 IP Address와 Subnet Mask를 구성하였는데, 클라이언트들의 TCP/IP설정에는 Default Gateway, DNS, WINS등의 추가 설정이 필요하다. DHCP서버는 이러한 사항들을 'DHCP옵션'으로 처리해 주고 있다. DHCP옵션을 구성하는 그림이 나오는데 지금 구성할 수도 있고, 나중에 추가로 작업하는 것도 가능하다. "아니오"를 통해서 마법사를 마쳐도 기본적인 DHCP구성은 끝난 것이다. 계속 구성을 해 보도록 하겠다. 

클라이언트에게 할당할 Router, 즉 Default Gateway로 설정될 IP Address를 입력하고 <추가>버튼을 누릅니다.

DNS를 구성하는 과정인데 <그림4-18>의 예제처럼 IP주소만 입력해 주어도 동작하는 데는 문제가 없다. 그렇지만 도메인 환경에서의 작업을 고려한다면 부모도메인의 항목에도 도메인 이름을 입력할 필요가 있다. 예를 들어서 사용자가 속한 도메인이 secure.pe.kr 이라고 하면 '부모도메인'항목에 'secure.pe.kr'이라고 입력을 한다. 그렇게 해 주면 사용자가 hostA.secure.pe.kr 이라는 이름의 호스트를 찾고자 할 때 hostA 라고만 입력을 해도 실제 DNS에 쿼리가 날아갈 때는 hostA.secure.pe.kr 라는 이름으로 요청을 한다.

또한 DNS서버의 IP를 하나만 주는 것보다는 2개를 할당하여 하나의 DNS서버가 문제가 있을 경우를 대비하는 것이 좋다. DHCP클라이언트는 DNS서버의 IP를 2개를 가지게 되며 첫 번째 DNS서버가 문제가 있을시 두 번째 DNS서버를 통해서 호스트이름을 IP Address로 변환하는 작업을 처리할 수 있다. 회사에 DNS서버가 하나만 구현이 되어 있다면 추가로 ISP의 DNS등, 외부의 DNS서버를 두 번째 DNS서버로 셋팅하는 것도 하나의 방법이다. DNS는 아주 중요한 서비스중의 하나이다. DNS에 대해서는 5장에서 자세히 다루도록 하겠다.

WINS서버의 IP를 입력한다. 역시 하나보다는 두 개를 사용하는 것이 좋다. 물론 네트워크에 WINS서버가 적어도 2개 이상 있다는 전제가 따라야 한다. WINS서버는 "NetBIOS이름풀이"를 위해 필요한 서버이다. 6장에서 자세히 다룬다.

이제 옵션구성도 끝났다. 192.168.5.0 네트워크의 IP범위를 활성화 할 필요가 있다. 활성화 하기 전까지는 DHCP서버는 클라이언트의 요청에 응답하지 않다. 만일 추가로 구성을 더 해야 할 필요가 있다면 "아니오. 나중에 활성화하겠다."를 선택해서 DHCP서버가 IP를 발급하지 못하도록 한다. 나중에 DHCP관리콘솔을 통해서 얼마든지 활성화 작업은 가능하다.

 DHCP서버에 '새 범위 마법사'를 완료하는 그림이다.

<그림4-22>에서는 blueapple.secure.pe.kr 이라는 이름의 DHCP서버에 192.168.5.0 네트워크의 IP범위가 설정된 그림을 보여준다. 왼쪽패널의 '주소풀'을 클릭하면 오른쪽으로 IP주소 범위를 보여주는 그림을 볼 수 있다. 그림을 보면 192.168.5.11부터 192.168.5.100 까지가 범위로 되어 있고, 두 번째 리스트에는 192.168.5.20이 제외된 IP주소임을 보여준다. 결국 이 설정에서는 192.168.5.11~192.168.5.19, 192.168.5.21~192.168.5.100까지 총 89개의 IP가 사용가능하다는 것을 알 수 있다. 

DHCP관리콘솔의 192.168.5.0 범위의 '범위옵션'을 눌러보면 오른쪽 패널에 위에서 설정한 몇가지 DHCP옵션이 나오는 것을 확인할 수 있다. 이것은 마이크로소프트의 네트워크를 구축할 때 항상 따라다니는 기본 DHCP옵션들이다.

각 옵션값들의 설명은 각각의 장에서 따로 다루도록 한다.

이제 DHCP서버의 구성은 마쳤다. 다음엔 DHCP클라이언트의 설정을 구성해야 할 차례이다. 그래야 이 DHCP서버로부터 TCP/IP 구성을 받아갈 수 있다.

당신은 회사의 시스템 관리자이다. 사용자들이 네트워크 활동을 할 수 있도록 하기 위해서는 네트워크의 모든 호스트에게 IP Address를 할당하는 작업이 필요하다. 처음 한번만 잘 해주면 된다는 생각에 일일이 수작업으로 PC마다 IP Address를 잘 설정해 주었지만 심심치 않게 새로운 시스템도 늘어나고, 몇몇 사용자들의 호기심(?) 때문에 툭하면 IP Address로 인한 네트워크 장애가 발생하고 있다. 한 두 대도 아니고 수 많은 시스템을 관리해야 하는 관리자로서는 이러한 작업이 부담이 될 수 밖에 없다.

이러한 IP Address 관리작업을 자동화하면 해결된다. 바로 DHCP (Dynamic Host Configuration Protocol)가 그 해답이다.

마이크로소프트는 서버OS제품군에서 DHCP서버 서비스를 지원한다. 이때 DHCP서버로 셋팅된 컴퓨터는 클라이언트들에게 할당할 IP Address Pool을 유지하고 있으면서 DHCP프로토콜을 이용해서 IP Address발급을 요청하는 클라이언트에게 IP Address를 할당한다.

DHCP서비스를 DVD대여점의 프로세스와 유사하다. DVD 대여점이 DVD타이틀을 대여한다면 DHCP서버는 IP Address를 대여하는 역할을 한다. 완전히 소유권이 넘어간 것이 아니라 임대의 형식을 이용하는 만큼 당연히 기간이 만료되기 전에 반납을 해야 하며, 계속 임대를 원한다면 갱신요청을 보내서 임대기간을 연장해야 한다. 아래의 <그림4-1>과 같은 환경을 가정해 보자.

<그림4-1>에서 볼 수 있듯이 하나의 네트워크가 있고, 그 네트워크에는 DHCP서버, DHCP클라이언트, Non-DHCP클라이언트가 있을 수 있다. Non-DHCP클라이언트는 DHCP서버로부터 IP를 할당받지 않고 고정IP를 설정한 호스트를 의미한다. DHCP클라이언트는 IP Address가 변경될 수 있는(유동의) 소지가 있는 호스트이므로, IP가 변경됐을 때 네트워크의 원활한 소통에 문제가 있을 수 있는 서버역할을 하는 컴퓨터들의 경우는 고정 IP를 할당해야 한다. 예를 들면 웹서버, DNS서버, 메일서버, 도메인컨트롤러 등 서버들의 경우이다.

DHCP클라이언트는 시스템이 시작됨과 동시에 DHCP서버를 찾는 메시지를 네트워크에 발송하여 IP Address임대를 요청하게 되며, DHCP서버는 이러한 클라이언트의 요청에 응답하여 자신의 DHCP Database에서 IP Address를 임대한다. 그 과정을 <그림4-2>와 같이 정리하였다.

위의 그림을 보면 4가지 단계로 나뉘어 있는 것을 알 수가 있는데 자세한 과정은 다음과 같다.

(1) Discover : DHCP클라이언트는 부팅이 시작되는 동안에는 IP Address를 가지고 있지 않다. 부팅이 되고 네트워크가 시작되면 먼저 IP Address를 셋팅하여 TCP/IP를 초기화하려는 시도를 한다. 그 방법으로써 DHCP서버를 찾는 요청을 만들어서 패킷을 브로드캐스트한다. 이것이 "Discover"과정이다. 

(2) Offer : Discover 메시지를 받은 DHCP서버는 사용가능한 IP Address 하나를 담은 DHCP패킷을 만들고, 역시 네트워크에 브로드캐스트를 이용해서 전파한다. 만일 한 네트워크에 여러대의 DHCP서버가 있었다면 서버마다 같은 작업을 한다. 이 과정이 "Offer"이다.

(3) Request : DHCP서버로부터 IP Address를 받은 DHCP클라이언트가 그 즉시 이 IP Address를 사용할 수 있는 것은 아니다. DHCP클라이언트는 서버로부터 할당받은 IP Address와 이 IP Address를 임대해준 서버의 IP를 담은 패킷을 만들어서 네트워크에 다시 브로드캐스트를 보낸다. DHCP서버가 여러대 있어서 서버마다 클라이언트에게 각기 다른 IP Address를 발송할 수 있는 상황이 있기에 이러한 작업이 진행되는 것이다. 이 과정이 할당받은 IP를 사용하겠다는 요청인 "Request"이다.

(4) Ack : DHCP클라이언트의 Request브로드캐스트를 받은 DHCP서버는 둘중의 한가지 작업을 할 수 있다. 자신이 보낸 IP Address가 채택되지 않았다면 DHCP서버는 다시 IP Database에 유지하고, 자신이 보낸 IP가 채택되었다면 IP임대기간, DNS, Default Gateway, WINS등의 DHCP옵션값을 담은 "확인(Acknowledgment) "패킷을 만들어서 최종적으로 브로드캐스트로 발송한다.

이것을 마지막으로 클라이언트는 TCP/IP를 초기화하고, 이때부터는 IP Address를 이용한 Unicast 통신이 가능해진다. 복잡해 보일 수 있지만 이 DHCP Broadcast가 네트워크에서 차지하는 것은 극히 일부분일 뿐이다. 중요한 것은 이 네가지 과정이 모두 브로드캐스트 통신이라는 것이다. 그것은 DHCP 클라이언트로 설정된 호스트가 DHCP서버로부터 IP Address를 얻기 전까지는 IP Address가 없다는 것에서부터 기인된다. 자신이 IP Address가 셋팅되지 않은 상태이니 DHCP서버의 특정한 IP를 향해 메시지를 날리는 것은 불가능할 수밖에 없다.

 DHCP Process를 네트워크모니터를 이용해서 캡처하였다.

그렇다면 회사의 네트워크가 브로드캐스트 도메인으로 나뉜 상황, 즉 두 개 이상의 네트워크로 세그먼트된 상황에서의 DHCP는 추가로 고려해야 할 사항이 발생한다. 두 개의 네트워크의 모든 호스트들이 DHCP클라이언트로 설정이 되었을 때 한쪽 네트워크에만 DHCP서버가 있다면 DHCP서버가 없는 쪽 네트워크의 DHCP클라이언트의 요청은 전달이 될 수 없다는 것을 의미한다. DHCP서버가 있는 네트워크까지 DHCP클라이언트의 요청이 넘어가야 할 것인데 이 요청이 브로드캐스트를 이용하므로 네트워크의 가운데에 있는 라우터가 이 브로드캐스트를 넘겨주지 않기 때문이다.

뒤에서 설명하겠지만 이러한 경우라도 역시 얼마든지 DHCP는 구현이 가능한다. 결론부터 말하자면 IP Address를 관리하는데 DHCP서비스를 이용하자는 것이다. 많은 관리자들이 DHCP의 편리성을 알면서도 사용하지 않고 있다. 물론 이유는 있다. 특정 사용자가 임의로 고정IP를 사용함으로써 IP충돌이 생길 수 있다는데 그 이유가 있고, 또 하나는 특정 사용자가 임의로 셋팅한 DHCP Server 때문에 정상적인 DHCP서버가 제대로 서비스를 하지 못하다는 것을 들 수가 있다. 그러한 것은 또다른 측면의 정책을 통해서 해결할 수 있다. 이를 테면 사용자가 임의로 IP주소를 바꿀 수 없도록 제어판의 네트워크 설정에 대한 접근을 제한하는 것도 한가지 방안이 될 수 있다.

또한 Active Directory의 인증을 얻은 DHCP서버만 동작하도록 되어 있는가 하면, DHCP Client을 DNS에 자동적으로 등록하는 등 Windows NT 4.0의 DHCP 서버에 비해서 Windows Server 2003의 DHCP서비스는 개선된 기능을 제공하고 있다.

3-4-1.인증기관의 필요성

공용키 암호화가 어떻게 동작하는지 위에서 설명했다. 앨리스가 보내는 데이터를 암호화하기 위해서는 먼저 밥의 공용키를 얻어야 한다고 했는데, 이때 앨리스는 밥으로부터 공용키를 얻고 나서 한가지 의문이 생긴다. 자신이 받은 공용키가 “진짜 밥의 공용키일까? 밥을 가장한 이브의 공용키는 아닐까?” 하는 의문이 들 것이다. 실제 환경에 적용시켜 보자. 여기서 밥은 웹서버에 해당하고, 앨리스는 웹브라우저에 해당한다. 당신은 인터넷 쇼핑몰을 운영하는 웹서버에 접속한 다음 마음에 드는 물건을 장바구니에 담았다. 마지막으로 구매를 결정하고 [결제하기]버튼을 클릭한 후 신용카드 번호, 유효기간 등의 개인정보를 웹서버에게 제공하려고 한다. 이때 안전하게 데이터를 보내기 위해 웹서버의 공용키를 웹서버로부터 받았다. 당신은 이 공용키를 이용해서 웹서버로 전송했지만 알고보니 이 공용키를 제공했던 것은 악의의 제3자였고, 당신의 중요한 개인정보는 외부로 유출이 되게 되었다.

이것을 해결하기 위해서는 당신이 사용하는 웹브라우저는 웹서버로부터 공용키를 얻게 되면 이것이 진짜 거래의 상대방인 웹서버가 발행한 공용키인지 확인해야 할 필요가 있다. 어떻게 확인할 것인가?

이것은 전자상거래가 오프라인상의 실제상거래에서도 마찬가지이다. 가게에서 물건을 하고 신용카드로 대금을 지불한다고 가정하면 가게에서는 고객을 믿고 물건을 내 주지는 않는다. 제3의 기관인 신용카드 회사(은행)를 믿고 물건을 내 주게 된다. 이것처럼 디지털 세계에서도 거래의 양자간의 각종 불신요소들을 해결하기 위하여 제3의 기관의 필요성이 대두된다.

인증기관(Certificate Authority, CA)은 그러한 필요성에서 의미를 찾을 수 있다. 인증기관은 서버의 신원을 증명해 준다. 때로는 클라이언트의 신원을 증명해 주기도 한다. 서버나 클라이언트가 디지털 세계에서 하고자 하는 작업에 신뢰를 부여하기 위한 인증서를 발행하는 작업, 이것이 인증기관의 주된 업무라고 할 수 있다. <그림3-5>를 통해서 인증기관의 역할을 알아보도록 하자.

그림의 예제는 웹서버와 사용자와의 통신을 그림으로 나타낸 것이다. 안전한 거래를 위해서 먼저 웹서버는 한 쌍의 공용키와 개인키를 생성한다(①). 개인키를 자신의 하드디스크에 안전하게 저장을 한 다음 공용키를 웹서버에 게시를 한다. 사용자들이 웹서버로 보내는 데이터를 웹서버의 공용키를 이용해서 암호화해서 보낼 수 있도록 하기 위한 조치이다. 하지만 사용자가 웹서버의 공용키를 신뢰할 수 없다는 것이 문제이다.

이에 웹서버는 웹서버에서 사용할 한 쌍의 키를 생성한 다음 공용키를 인증받기 위한 과정을 거친다. 자신의 공용키와 서버의 정보등을 첨부해서 CA에게 인증서 발급요청을 넘긴다(②). CA는 인증서 발급요청 정보를 잘 살펴보고 하자가 없다면 인증서를 발행하게 된다. 이 인증서에는 웹서버가 제시했던 공용키, 웹서버의 정보, 인증서의 주체, 마지막으로 CA의 전자서명이 들어있다. 결국 웹서버의 공용키를 제3자에 해당하는 CA가 인증을 해 주었다는 뜻이다(③).

이제 웹서버는 공용키만을 게시하는 것 대신에 CA로부터 받은 ‘인증서(Certificate)’를 게시하게 되고, 사용자가 웹서버로 중요한 데이터를 보내기 전에 웹서버로부터 인증서를 얻는다(④). (이 인증서에는 웹서버의 공용키가 저장되어 있음을 기억하라) 인증서를 받은 사용자는 인증서를 발행한 인증기관(CA)가 믿을만한 인증기관인지, 인증서의 날짜는 유효한지, 인증서의 주체와 현재 접근하는 사이트의 주소는 일치하는 지 등의 내용을 확인한다(⑤).

모든 확인이 끝났으면 이제 인증서안에 있는 공용키를 이용해서 자신이 보내는 데이터를 암호화할 수 있다. 믿고 거래할 수 있게 된 것이다. 이때의 인증서의 역할은 ‘서버의 신원증명’에 해당하는 사항이다.

반대로 생각할 수 있는 인증서의 용도는 인터넷 뱅킹에서 찾아볼 수 있다. 인터넷 뱅킹을 사용하기 위해서 우리는 먼저 은행을 직접 방문하여 인터넷 뱅킹 사용 신청서를 제출하고 사용자 계정을 발급받는다. 그것으로 끝나는 것이 아니라 자신의 컴퓨터에서 인터넷 뱅킹을 하기 위해서는 먼저 은행의 서버에 연결한 다음 ‘인증서’를 발급받아야 하는데 이때의 인증서는 ‘클라이언트의 신원을 증명’하기 위한 인증서에 해당한다.  

3-4-2.내부CA와 외부CA

인증기관을 크게 두가지로 구분해 볼 수 있다. 내부CA와 외부CA로 나누어 보겠다. 여기서 내부CA는 회사에서 임의로 설치한 내부적인 사용목적의 CA가 되겠고, 외부CA는 외부의 다른 서버 혹은 클라이언트와의 통신을 위해 사용할 수 있는 상업용CA라고 할 수 있다. 상업용CA중 대표적인 CA를 들라고 하면 ‘Verisign(베리사인)’을 들 수 있다. 관련분야에서 한마디로 잘 나가는 회사이다. 관심있게 보면 인터넷 쇼핑몰 웹서버의 상당수가 베리사인의 인증서를 사용하는 것을 알 수 있다.

웹서버를 운영하는데 내부CA로부터 인증서를 받을 수도 있고, 외부CA로부터 인증서를 받을 수 있다. 차이가 있다면 금전적인 부분을 먼저 들 수 있는데 외부CA로부터 웹서버 인증서를 하나 받으려면 보통 1년에 100만원 이상의 비용을 지불해야 한다. 상당수의 인터넷 쇼핑몰이 영세성을 면하지 못하고 있는 현실을 고려할 때 거리감을 느끼게 만드는 금액이다. 하지만 그러한 상업용 웹사이트의 경우 필요성을 찾을 수 있게 되는데, 그림을 통해서 접근을 해 보자.

<그림3-6>의 화면은 내부CA로부터 인증서를 받은 웹서버로 https://ssl.secure.pe.kr 를 통해서 접근했을 때 클라이언트의 화면에서 팝업되는 경고메시지이다. 3가지 항목중에서 첫번째 항목에는 노란색 느낌표가 들어있는 세모상자의 아이콘을 볼 수 있다. 메시지를 읽어보면 ‘신뢰 여부를 결정한 적이 없는 회사에서 발급한 보안 인증서입니다. 인증 기관의 신뢰 여부를 결정하려면 인증서를 확인하십시오.’라고 되어 있다. 당신이 관리하는 웹서버가 클라이언트에게 위와 같은 메시지를 주고 있다고 생각을 해 보면 어떠한가? 한글번역된 ‘신뢰여부를 결정한 적이 없다’라는 경고메시지도 치명적이라는 생각이 들게 만드는데, 이러한 메시지를 받은 사용자들이 선뜻 자신의 신용카드 정보등을 제공하고 싶어질까? 이 질문에 대해서는 ‘중요한 정보를 제공하고 싶지는 않지만 그래도 거래는 이루어질 것이다.’라고 개인적으로 생각한다. 그만큼 사용자들이 시스템이 내 보내는 오류, 경고 메시지에 둔감하기 때문에 가능한 일일 것이다. 실제로 국내에서 몇백만명 이상의 회원을 확보한 대규모 웹사이트들도 여전히 상당수의 사이트에서는 이러한 경고메시지를 발생시키는 웹사이트를 찾아 볼 수 있는 것이 현실이다.

언제까지 그렇게 사용자들이 무관심할 수 있을까? 라는 생각을 해 보면 그 시점까지가 내부CA를 이용해서 인증서를 발급받을 수 있는 시기라고 생각된다.

[인증서 보기]버튼을 눌러서 인증서를 확인하면 <그림3-7>과 같다.

그림에서 보면 발급대상이 ssl.secure.pe.kr 이다. 클라이언트가 접근할 때 https://ssl.secure.pe.kr 였으니 발급대상과 사이트 이름은 일치했다. 유효기간도 경과되지 않았으니 문제가 없다. <그림3-6>에서는 이 2가지 항목에 대해서는 녹색 체크 표시 아이콘을 보여준다. 하지만 인증서를 발행한 기관에 대한 신뢰성이 문제가 되는데 이것은 클라이언트가 신뢰하는 인증기관의 목록에서 웹서버의 인증서를 발급한 인증기관을 찾지 못했기 때문에 생기는 결과이다. 클라이언트 컴퓨터에서 ‘인터넷 익스플로러 à도구à인터넷 옵션à내용탭à인증서’ 순서로 접근해 보면 신뢰할 수 있는 인증기관의 목록이 이미 정의되어 있는 것을 알 수 있다. 여기에서 웹서버가 현재 사용하는 인증서를 발급해 준 인증기관의 이름을 찾지 못했다는 것이 경고메시지의 에러표시가 뜻하는 내용이다.

내부CA를 사용하면서 외부의 클라이언트의 웹브라우저에게 이것을 속이는 것은 불가능한 방법이다. 그렇기 때문에 에러메시지는 어쩔 수 없는 결과가 될 것이다. 해결할 수 있는 방법은 이 신뢰된 루트 인증기관의 목록에 있는 인증기관(CA)으로부터 인증서를 받아서 사용하는 방법이다.

<그림3-9>에서는 아무런 에러가 없는 잘 설정된 인증서의 정보를 보여준다. 누구나 알만한 대기업들의 웹사이트들도 이러한 PKI를 도입한 것이 그리 오래 되지 않은 일이다. 그중에서도 상당수의 기업들은 제대로 설정되지 않은 사이트를 오픈하고 있는 실정이니 ‘이제 시작이라 어쩔 수 없는 것인가?’라는 생각을 가지게 만든다. Windows Server 2003에 CA서비스를 추가하는 방법에 대해서는 9장에서 다룬다.

보통 줄여서 PKI라고 부르는 Public Key 구조는 앞에서 설명한 대칭키 기법과는 다른 알고리즘을 가지고 있다. 물론 암호화를 하겠다는 기본적인 생각은 차이가 없다. 대칭키를 사용하는데 있어서의 문제점으로 2가지를 거론했는데 Public Key는 이것을 해결해 주고 있다.

Public Key를 다른 용어로 표현한다면 비대칭키, 페어키(Pair Key)라는 용어를 들 수 있다. 용어에서 느껴지는 것이 있을 것이다. 앞에서 설명한 대칭키 알고리즘은 잠그는 키(암호화키)와 푸는 키(복호화키)가 동일하다는 의미에서 대칭키라고 불리운다고 했다. 그렇다면 비대칭키라는 뜻은 이 두개의 키가 서로 같지 않다는 것을 의미하는 것? 그렇다. Public Key알고리즘에서는 암호화키와 복호화키가 한쌍의 키(Pair Key)를 이루고 있다.

이 한쌍의 키는 Public Key(공용키)와 Private Key(개인키)로 구성되어 있다. 공용키는 누구라도 사용할 수 있도록 공개가 되며, 개인키는 HDD, Smart Card등의 공간에 보관하면서 오로지 키쌍을 만든 주체만 사용할 수 있다는 것이 보장되어야 한다.

이 키들은 다음과 같이 사용된다. Public Key 기법을 사용하기 위해서는 먼저 ‘공용키’와 ‘개인키’라는 한쌍의 키를 생성해야 하고, 공용키로 암호화한 데이터는 오직 해당 공용키와 한쌍으로 생성된 개인키로만 해독할 수 있다는 것이다. 그렇다고 무조건 공용키는 암호화키이고 개인키는 복호화키라는 개념은 아니다. 반대상황도 있다. 개인키로 데이터를 암호화하면? 이번에는 한쌍에 해당하는 공용키로만 해독이 가능하다.

공용키는 이름에서 느껴지는 것처럼 누구나 사용할 수 있는 키다. 공개가 되는 키라는 뜻이다. 이 키는 웹서버에 게시되거나 파일서버에 공유되거나 안전하지 않은 전자메일을 통해서 상대방에게 보내져도 아무 문제가 없다. 대칭키에서 가졌던 비밀키 전송의 문제점을 해결해 주는 것이다. 예를 들어 웹서버가 키쌍을 만든다음 앨리스에게 공용키를 전송해 주었다고 하자. ‘앨리스’는 공용키를 이용해서 웹서버로 보내는 데이터를 암호화할 것이다. ‘이브’역시 이 공용키를 구하는 것이 어렵지 않다. 하지만 공용키를 이용해서 앨리스의 암호화된 데이터를 해독하는 것은 불가능하다. 공용키로 암호화된 데이터는 한쌍이 되는 개인키로만 해독이 가능하기 때문이다.

그러다 보니 이제 웹서버는 1만명의 회원을 위해서 1만개의 키를 생성할 필요가 없다. 오직 하나의 공용키만 가지면 되는 것이다. 1만명의 회원들이 동일한 공용키를 가지게 될 테지만 이들은 공용키로 암호화를 할 수는 있지만 공용키로 암호화된 데이터를 해독하는데 사용할 수는 없다는 것을 기억하라.

개념을 알고 나면 단지 그렇구나! 라고 생각할 수 있겠지만 처음 이러한 알고리즘을 만든 사람들은 대단하다는 생각이 든다. Public Key 알고리즘은 MIT공대에서 개발되었다고 한다. 개발한 사람들의 이니셜을 딴 RSA 프로토콜이 가장 널리 사용되고 있다.

3-3-2.Public Key 암호화 (Confidentiality제공)

Public Key를 이용한 암호화에 대해서 <그림3-2>를 보면서 살펴보도록 하자. 앨리스가 밥에게 데이터를 전송하려고 한다. 중요한 데이터인데 이브의 도청이 염려스럽다. 안전하게 보내기 위해서 데이터를 암호화하기로 결정했는데 암호화키가 필요하다. 암호화키로써 데이터를 암호화해서 보내면 데이터를 받은 밥은 복호화를 해야 한다. 역시 복호화키가 필요할 것이다.

먼저 앨리스는 밥의 공용키를 구하는 것이 선행되어야 한다. 그 다음에 자신이 보내고자 하는 데이터를 밥의 공용키로서 암호화하여 전송해 준다. 밥은 암호화된 메시지를 받은 다음 앨리스가 암호화하는데 사용한 공용키와 한쌍으로 생성해 두었던 개인키를 이용해서 복호화하게 된다. 결국 데이터를 꺼낼 수가 있게 되었다.

한가지는 정리하고 가자. PKI를 이용하고자 할 때 상대방에게 안전하게 암호화된 데이터를 전송하고 싶다면 상대방의 공용키를 얻는 것이 첫번째 할일이다. 데이터에는 여러가지가 있을 것이다. 인터넷 쇼핑몰이 운영되고 있는 웹서버로 신용카드와 유효기간 등의 정보를 보낼 수도 있을 것이고, 회사의 중요데이터를 담은 전자메일 메시지일 수도 있다. 웹서버와의 안전한 통신을 위해서는 웹서버로부터, 전자메일을 보내고자 한다면 상대방으로부터, 먼저 할 일은 공용키를 얻어내는 과정이 필요하다는 것이다. 그 공용키로써 암호화를 했을 때 해독할 수 있는 사람은 오직 공용키와 쌍이 되는 개인키를 소유한 사람이다.

3-3-3.Private Key 암호화 (Authenticity제공)

이번엔 다른 관점이다. 개인키를 이용한 암호화가 어떠한 용도로 사용되는지에 대해 정리해 본다. 이번엔 밥의 입장에서 고려를 해 보자. 밥이 앨리스라고 주장(?)하는 사람으로부터 메시지를 받았다고 가정한다. 밥은 자신이 받은 메시지가 정말 앨리스가 보낸 것인지를 확인하고 싶어한다.

현실세계에서 요즘 거의 종이에 펜을 이용해서 글씨를 쓰고 편지를 보내는 일이 드문일이 되었다. 우리는 무엇인가 문서를 만들고 나서 자신이 확인했다는 표시로 ‘자필서명’이라는 것을 하곤 한다. 그러면 상대방은 그 서명을 통해서 받은 편지를 신뢰한다. 디지털 세상에서도 이와 동일한 알고리즘의 작업이 행해지고 있다.

앨리스는 밥에게 보낼 메시지를 만든 다음 자신이 보냈다는 것을 증명하기 위해 “서명”을 한다. 바로 전자서명이 되는 것이다. 서명이 유효하기 위해서는 지켜져야 할 조건이 있다. 당사자가 아닌 다른 사람은 동일한 서명을 할 수 있어서는 안된다는 것이다. 그렇다면 앨리스가 밥에게 보낼 메시지에 서명을 할때는 다른 사람은 가지고 있지 못한 자신만이 가진 유일한 증표를 사용해야 할 것이다. 그것은 바로 자신의 Private Key(개인키)를 이용하는 것이다. 앞에서 공용키는 누구에게나 공개가 되지만 개인키는 오직 키쌍을 생성한 주체만이 가지고 있다고 한 것을 기억하면 될 것이다. 과정을 <그림3-3>을 통해서 설명한다.

그림에서 앨리스는 밥에게 데이터를 전송하고자 한다. 밥에게 자신이 보내는 메시지라는 것을 신뢰할 수 있도록 하기 위해서 자신만이 가지고 있는 개인키를 이용하여 메시지를 암호화한다. 이것을 가리켜서 “Digital Signature (전자서명)”이라고 부른다. 결국 앨리스는 자신이 서명한 메시지를 네트워크를 통해서 밥에게 보낸다. 이 메시지를 받은 밥은 앨리스의 공용키를 이용해서 복호화를 하고, 앨리스의 공용키로써 복호화가 이루어지면 자신이 받은 메시지가 앨리스가 보낸 것이 맞다고 판단을 한다. 앨리스를 가장한 제3자가 보낸 메시지라면 앨리스의 공용키로 해독이 되지 않을 것이다.

만일 이 메시지를 도중에 이브가 가로챘다면? 이브는 당연히 이 메시지를 읽을 수가 있다. 앨리스의 공용키만 있다면 얼마든지 해독이 가능할 것이기 때문이다. 기밀성은 제공되지 않는다는 것을 의미한다.

이렇듯 개인키를 이용해서 암호화하는 것(전자서명)은 제3자가 데이터를 열지 못하게 하기 위한 방법은 아니다. 다만 상대방에게 자신을 가장한 제3자가 아닌 진짜 자신이 보낸 메시지라는 것을 알려주기 위한 방법일 뿐이다.

3-3-4.Hash함수와 Digest (Integrity 제공)

개인키를 이용한 전자서명과 더불어 추가로 고려해야 하는 내용이 있다. 밥이 앨리스로부터 데이터를 받았을 때 밥은 이 데이터가 앨리스가 보낸 원본데이터 그대로인지, 즉 중간에서 변조가 되었다거나 바이러스코드가 추가되었다거나 하는 등의 훼손된 것은 아닌지를 알고 싶다는 것이다. 결국 무결성(integrity)이 보장되어야 한다는 것인데, 이것은 바로 Hash(해시)라고 부르는 함수(Function)와 관련이 있다.

해시는 주로 원본을 감추고 확인하기 위한 용도의 함수인데, ‘단방향 함수’이며 원본이 1비트만 달라져도 두 개의 문서는 서로 다른 결과값을 가진다는 특징을 가지고 있다. Y=f(x) 라는 일반적인 공식에 대입시켜 보자. 해시함수 역시 모든 함수가 그렇듯이 x값을 대입시키면 결과값(y)이 나오는데, 거꾸로 y값을 가지고는 x가 무엇이었는지를 구할 수가 없다는 특징을 가진 함수이기 때문에 ‘단방향 함수’라고 부른다. 이것은 네트워크 상에서 상당히 유용하게 쓰일 수 있다. 어떤 사용자가 서버로 자신의 암호인 1234 를 전송하고 있다고 가정을 했을 때, 1234를 그대로 전송하면 제3자의 도청위험에 노출되게 된다. 하지만 1234를 그대로 전송하는 것이 아니라 해시함수를 이용해서 해시하여 전송하게 되면 설사 제3자가 이 패킷을 도청했다고 하더라도 1234라는 암호는 감출 수가 있기 때문이다.

제3자는 이 패킷을 가지고 원래 암호를 알아내기 위해 노력하겠지만 해시함수의 특성상 원본을 알아내는 것은 어렵다고 판단된다. 해킹에 조금 관심을 가진 독자라면 흔히 ‘패스워드 크랙킹 툴’들에 대한 이야기를 접할 수 있을 것이다. 이러한 암호 크랙킹 툴들중에는 “사전공격(Dictionary Attack)’이라는 공격방법을 이용하는 툴들이 많은데, 이러한 툴들은 해시값을 역으로 추적해서 원본데이터를 알아내는 것이 아니라 원본데이터를 유추하는 방식을 사용한다. 즉 암호를 짐작하여 생성한 다음 해시함수를 이용하여 해시하고 그 값을 자신이 네트워크에서 훔쳐낸 값과 비교하는 방법을 이용한다. 두 값이 같으면 자신이 유추한 암호가 사용자의 암호라고 판단하는 것이다. 이 때 원본데이터에 해당하는 단어들을 정의한 사전파일을 사용하고 있어서 이를 “사전공격(Dictionary Attack)’이라고 한다. 대부분의 보안지침에서 ‘사전에서 쉽게 찾을 수 있는 단어를 암호로 사용하지 말라’라고 하는 이유는 바로 이러한 공격의 위험을 염두에 둔 것이다.

원본데이터를 해시함수를 이용하여 계산하여 나오는 값을 Digest(요약)이라고 부른다. 원본데이터중에서 뽑아낸 요약된 비트라는 의미에서다.

구체적으로 무결성(Integrity)을 보장하기 위해서 어떻게 해시함수가 사용되는지 <그림3-4>를 통해서 설명한다. 그림의 번호순으로 차근차근 접근해 보자.

그림에서는 앨리스가 밥에게 데이터를 전송하려고 한다. 먼저 앨리스는 데이터를 해시하여 다이제스트를 생성한다. 다이제스트는 해시함수를 이용하여 얻은 결과값이다. 이 다이제스트를 자신의 개인키를 이용하여 암호화한다. 개인키를 가진 사람만이 할 수 있는 이 작업이 ‘전자서명’이라고 설명한 바 있다. 그 다음에 네트워크를 통해서 밥에게 ‘전자서명된 데이터’를 전송한다. ‘전자서명된 데이터’라는 표현을 잘 음미해 보라. 앨리스가 전자서명을 어떻게 만든 것인지를 보면 결국 앨리스가 보내는 ‘전자서명된 데이터’가 의미하는 것은 ‘원본데이터+다이제스트’라는 것을 알 수 있을 것이다.

이 메시지를 받은 밥은 몇 가지 작업을 거친다. 먼저 앨리스가 보낸 메시지라는 것을 확인하기 위해 앨리스의 공용키를 이용해서 ‘전자서명’이라는 암호문을 해독한다. 이 복호화의 결과로 얻는 것은 앨리스가 보내준 ‘다이제스트’이다. 그 다음에 원본데이터를 앨리스가 사용한 것과 동일한 해시함수로 해시하여 다이제스트를 생성한다. 그리고 2개의 다이제스트를 비교하는 일을 한다. 이 2개의 다이제스트가 정확히 일치한다는 것이 밝혀지면 다이제스트를 생성한 원본이 동일하는 것을 증명해 주는 것이다. 밥이 받은 데이터가 도중에 훼손되었다면 밥이 직접 생성한 다이제스트는 앨리스가 만들어서 보낸 다이제스트와 ‘불일치’라는 결과를 보일 것이다.

이러한 방법을 이용해서 데이터 무결성을 보장해 줄 수 있다.

그림의 내용을 다시 정리해 보았다.

오래된 암호화 방법이다. 대칭키 알고리즘을 흔히 비밀키 알고리즘이라고도 부른다. A와 B만이 아는 비밀키를 이용해서 암호화 통신을 한다는데서 기인한다. 여기에서 핵심은 대칭키라는데 있다. 키가 대칭을 이룬다? 이것은 암호화키와 복호화키가 동일하다(대칭을 이룬다)라는 데서 정답을 얻을 수 있다.

<그림3-1. 대칭키 알고리즘>

<그림3-1>의 예제에서 보듯이 대칭키 알고리즘에서는 암호화를 할 때 사용하는 키와 복호화를 할 때 사용하는 키가 동일해야 한다. Alice가 ‘1234’를 키로서 데이터를 암호화했다면 Bob역시 ‘1234’라는 키를 알아야만 복호화를 할 수 있다는 것이다. 이 대칭키 알고리즘을 사용하는 대표적인 암호화 프로토콜로는 DES(Data Encryption Standard, 56bit, ‘데쓰’ 프로토콜로도 읽는다.), 3DES(Triple DES, 168bit)가 있다. DES를 세번 반복하는 3DES는 상대적으로 안전하기는 하지만 당연히 키 길이가 길어짐으로써 더 느려진다는 단점이 있다. 56bit키를 사용하는 DES는 사용을 권장하지 않는다. 현재 대부분의 상업용 암호화는 128비트 이상의 암호화가 구현되는 것이 일반적이다.

이러한 대칭키 알고리즘은 작은 키 길이를 사용함으로써 빠르게 암호화와 복호화가 이루어진다는 장점이 있지만 몇가지 문제점을 안고 있다.

첫번째 문제는 암호화 키 교환의 어려움이다. Alice가 ‘1234’라는 암호화키를 이용해서 암호문을 만들었다면 암호화된 메시지를 받은 Bob은 역시 ‘1234’라는 키를 알아야만 한다. Bob은 이 키를 어떻게 알 수 있을까? 이때 사용된 암호화키는 웹사이트에 게시하거나 공유폴더에 저장해 둘수는 없다. Bob이 아닌 제3자가 이 Key를 가져간다면 Alice의 암호문을 해독하는 것이 가능하기 때문이다. 전자메일을 사용해서 key를 전송하는 것 역시 조금은 낫지만 바람직한 방법은 아니다. 결국 안전한 방법은 디스켓에 담아서 직접 상대방에게 가져다 주는 방법을 사용해야 할 것이다. 번거로운 일이 아닐 수 없다. 이것을 해결하기 위해서 SSL, Kerberos등의 다른 암호화 방법과 더불어 키 교환을 제공하고 있지만 대칭키 알고리즘 자체로만 보자면 고려되어야 할 부분이다.

두번째 문제는 키 관리의 어려움을 들 수 있다. 예를 들어서 웹사이트 하나가 있고 1만명의 회원이 있다고 하자. 1만명의 모든 회원들은 웹서버에 신용카드번호, 유효기간, 비밀번호 등을 전송해야 하는데 당연히 고려할 점은 웹서버가 아닌 어느 누구도 이 데이터를 열수 있어서는 안된다. 이 경우 키는 몇 개가 필요할까? 웹서버가 한대이니 키도 한 개만 있으면 좋겠지만 아쉽게도 키는 1만개가 있어야 한다. 1만명의 회원들에게 각각 고유한 비밀키를 할당해 주어야 한다는 것이다. Alice라는 회원과 Eve라는 회원의 키가 동일하다면 Alice가 암호화한 데이터를 Eve도 해독할 수 있기 때문이다. 그렇게 되면 Confidentiality는 깨지고 만다.

이것에 비해 PKI는 보다 유연한 관리를 가능하게 만든다. 하지만 다음장에서 설명할 PKI는 대칭키 방식에 비해서 키 길이가 길고 알고리즘이 복잡하여 성능면에서 상대적으로 떨어진다. 그런 이유로 현재 사용되는 형태를 보면 대칭키 알고리즘과 공용키 알고리즘이 공존하여 쓰이고 있는 형태이다.

암호화가 왜 필요한가? 이것이 하고자 하는 목표는 뚜렷하다. A가 B에게 데이터를 전송할 때 이 데이터는 B가 아닌 다른 어느 누구도 들여다 봐서는 안된다는 것이다. 그것을 만족시키기 위해서는 A와 B만이 알고 있는 방법을 이용해서 원본 데이터를 위장할 필요가 있다. 제3자는 A가 보내는 데이터를 네트워크에서 훔쳐낼 수는 있지만 A가 보낸 완전한 원본 데이터를 알아낼 수는 없다. 그 방법은 B만이 알고 있기 때문이다.

A가 B에게 보내는 데이터의 종류는 중요하지 않다. A가 B라는 인터넷쇼핑몰에서 물건을 구입하고 자신의 신용카드 번호를 넘겨주는 것일 수도 있고, A가 B라는 사용자에게 회사의 기밀을 담고 있는 전자메일을 전송하는 것일 수도 있다. 어떠한 유형의 데이터이든지 상대방이 아닌 다른 사람은 데이터를 열수 없도록 하기 위해서는 ‘암호화’와 같은 방법이 필요하다.

현재 이러한 암호화가 제공하고자 하는 것, 즉 업계에서 암호화를 통해서 얻고자 하는 요구사항은 크게 4가지로 정리해 볼 수 있다. 잘 정리해 보자. 앞으로의 내용들을 이해하는데 필수적인 사항들이다.

암호화를 통해서 위의 4가지 요구사항을 해결해야 한다. 암호화를 한다는 것은 데이터를 통신의 양자간에만 알 수 있는 ‘방법’을 통해서 데이터를 변경시키는 작업을 의미한다. 이때 ‘방법’에 해당하는 것이 바로 ‘키(Key)’이다. 이 Key가 어떻게 사용되는가가 암호화를 이해하는데 가장 관건이 된다.

개념은 단순하다.

A는 데이터를 암호화키(Encryption Key)를 이용해서 걸어잠그고(암호화하고), B는 복호화키(Decryption Key)를 이용해서 해독하는 것이다.

요즘 IT관련지를 들여다 보면 빠지지 않고 등장하는 것이 VPN, 무선네트워크, PKI 등의 용어일 것이다. PKI를 이해할 때는 이것을 하나의 기술로만 이해하기보다는 하나의 커다란 ‘인프라’라고 이해할 필요가 있다. 전자상거래, 인터넷 뱅킹, 기밀 데이터의 보호, 사용자의 인증 등 안전한 데이터전송을 필요로 하는 수많은 분야에서 PKI기반의 보안이 구현되고 있고 이것에 대한 수요는 향후 보다 급속도로 확산되고 있다.

데이터를 보호하기 위한 기본적인 생각은 제3자는 읽을수 없도록 데이터를 암호화하자는 것이다. 필자는 독자들에게 ‘암호학’에 대해서 이야기 하자는 것이 아니다. 암호학에 관련한 내용은 필자도 모른다. 다만 암호화기술이 어떤 기본 알고리즘을 가지고 있고, 어떻게 네트워크 환경에 적용되어 사용되는지, 그리고 어떻게 당신이 관리하는 회사에서 응용을 할 수 있을 것인지에 대해 알아보자는 것이다. 기본 알고리즘 역시 몰라도 구현하는데는 큰 지장이 없지만, 서두에서 말했듯이 우리에게 비교적 생소한 기술이기 때문에 막연히 툴을 이용하여 구현하고자 한다면 상당히 어렵고 구현을 하고서도 ‘내가 도대체 지금 무슨 작업을 한 거지?’라는 의문을 가지게 될 것이다.

<문제> 218.55.9.0 C Class Network ID하나를 할당받았다. 회사에서는 6개의 물리적인 네트워크로 나뉘어 있다. 6개의 네트워크를 지원하기 위한 서브넷ID와 각 서브넷별 호스트ID의 범위를 구하면?

<계산>

(1) 6개의 네트워크를 지원하기 위해 필요한 비트의 개수 산출 : 3개 (2³)

(2) 사용자 정의 서브넷 마스크를 계산하면 : 아래의 <그림2-25>을 참고한다. 255.255.255.224가 된다.

(3) 서브넷 ID 계산 : <그림2-25>에서 두 번째 박스를 살펴보면 화살표로 표기된 부분이 서브넷ID부분인데 여기서 가장 낮은 자리수를 십진수로 바꿔보면 32가 나온다. 이것은 32씩 증가하는 서브넷ID임을 보여준다. 즉 0.32.64.96.....224 가 바로 서브넷 ID가 되는 것이다.

2-4-1. CIDR - Subnetting

회사의 전체직원이 210명인 회사가 있다고 가정을 해 보겠다. 회사에서는 1인당 1대의 컴퓨터를 사용하고 있다. 회사에서는 보다 빠른 회선으로 업그레이드를 하면서 새로운 ISP로부터 인터넷 서비스를 받게 되고, 207.46.230.0 이라는 C Class Network ID를 할당받았다. 당신은 이 Network ID를 이용해서 회사의 클라이언트들에게 IP Address를 할당하는 작업을 해야 한다.

C Class Network ID 하나를 가지고 지원되는 호스트의 수는 최대 254까지이다. 회사의 전체 호스트 숫자가 210대이므로 C Class 하나만 가지면 충분히 지원할 수 있지만 이들

전체를 하나의 네트워크로 만들어 사용을 하기보다는 네트워크를 보다 작게 여러 개로 나누어 효율성을 기하고 싶다.

네트워크에 호스트수가 많아질수록 바로 브로드캐스트 통신이 문제가 되는데 네트워크에서는 이러한 브로드캐스트를 줄이는 방법으로 OSI 3계층 장비인 라우터를 통하여 네트워크를 여러개의 브로드캐스트 도메인으로 세그먼트하는 방법을 사용한다. 네트워크를 여러개로 나누면 각각의 네트워크에서 발생되는 브로드캐스트 패킷은 해당 네트워크에 한정되기 때문에 그만큼 효율적인 네트워크의 사용이 가능해 지는 것이다.

당신의 회사 역시 네트워크를 4개로 나눠서 한 세그먼트에 호스트의 숫자를 60대 미만으로 셋팅하고자 한다. 이러한 상황을 고려해 보겠다.

여기에서 당장에 혼란이 생긴다. 앞에서 서로 다른 물리적인 네트워크에서는 반드시 서로 다른 네트워크ID를 사용해야 한다고 했는데 당신은 ISP로부터 하나의 C Class 네트워크ID를 할당받았을 뿐이다. 이 하나의 네트워크ID를 4개의 세그먼트에 나눠서 차례대로 할당할 수는 있지만 그렇게 했을 때 이들 서로간에는 서로 통신을 할 수가 없게 된다. 같은 네트워크ID를 가지고 물리적으로 서로 다른 네트워크에 위치해 있으니 통신이 안 되는 것은 당연한 일이다.

ISP에 추가로 C Class네트워크 ID 3개를 요청했지만 추가비용을 요구한다. 거기다가 가만히 생각해 보니, 각각 254개를 쓸 수 있는 C Class ID를 3개 더 받아서 하나의 네트워크당 60개만 사용한다고 가정하니 나머지 194개씩의 IP는 버려질 수밖에 없는 노릇이다. IP Address의 낭비가 너무 심하다는 생각이 든다.

이것이 Class 체계의 IP Address가 가지는 맹점인 것이다. 보다 효율적인 방법은 없을까? 물론 있다. CIDR(Classless Inter Domain Routing)이라는 기법을 이용하여 IP Address를 보다 효율적으로 관리할 수 있다. 구현하는 방법은 의외로 간단하지만 처음 접근할 때 많이들 어려워하는 개념이다. 차근차근 접근해 보도록 하겠다. 실제로는 대기업 환경이나, ISP에서 쓰임새가 많은 기술이지만 시스템관리자에게는 상식적인 사항이 될 수 있다.

CIDR은 Subnetting과 Supernetting이라는 두가지로 구분해 볼 수 있다. 위의 예제의 경우에는 Subnetting이 필요한다. 할당받은 C Class ID는 네트워크 ID로 3개의 옥텟(24bit)을 사용하고 호스트ID로 1개의 옥텟(8bit)가 사용된다. 현재의 상황은 네트워크ID가 더 필요한 상황임을 고려하자. 해결방법은 호스트ID가 사용할 8bit중 일부를 네트워크ID용도로 전환하면 문제는 간단해 진다.

<그림2-21. CIDR기법- subnetting>

<그림2-21>에서 보듯이 호스트ID 8비트중에서 3비트를 네트워크ID 용도로 전환하여 사용하려고 한다. 이때 이 3비트를 "서브넷ID"라고 부르게 된다. 크게 본다면 네트워크ID에 포함될 수 있다. 좀 더 단계적으로 전체적인 계산방법을 알아보겠다.

2-4-2.  Subnetting 계산 방법

Subnetting을 계산할 때 익숙해지면 암산으로도 가능해진다. 하지만 지금은 단계별로 접근해 볼 것이다. 다섯단계로 구분을 해서 계산을 해 볼 것이다. 차근차근 한단계씩 이해하고 넘어가도록 하자.

2-4-2-① 회사에서 필요로 하는 네트워크의 수 결정

서브넷팅을 하기전 가장 먼저 할 일은 회사에서 필요로 하는 네트워크의 수를 파악하는 일이다. 이때 고려할 사항은 당장 필요한 것도 중요하지만 향후 네트워크의 확장이 고려된다면 네트워크의 여유가 있을 때 그 부분을 미리 고려하는 것도 필요한 일이다. 위의 예제상황에서는 총 4개의 네트워크가 필요하다고 결정되었다.

2-4-2-② 필요한 네트워크ID를 만들기 위해 전환할 bit수의 결정

①에서 결정된 4개의 네트워크를 지원하려면 호스트ID가 사용하는 8개의 비트중에서 몇 개의 비트를 네트워크ID로 전환시켜 사용해야 할까? 2²⁼ 4라는 결과가 나오니 2개의 비트가 있으면 되겠다. ( 만일 6개의 네트워크가 필요하다면 어떻게 할까? 2³=8이 되니 3개의 비트가 있으면 된다)

2-4-2-③ 서브넷 마스크(User defined Subnet Mask, Custom Subnet Mask) 계산

다음 해야 할 작업은 변경된 서브넷 마스크를 계산해야 한다. C Class의 기본서브넷 마스크는 255.255.255.0이었다. 이것은 C Class IP Address중에서 네트워크ID부분은 1, 호스트ID부분은 0으로 채운 결과 나온 값이었는데, 지금은 상황이 조금 달라졌다. 서브넷ID가 할당됨으로써 네트워크ID가 변동이 생겼으니 서브넷 마스크도 달라져야 한다. <그림2-22>에서는 변경된 서브넷 마스크가 계산되는 과정을 보여준다. 네 번째 옥텟의 호스트ID가 8비트에서 6비트로 줄어들고 상대적으로 네트워크ID가 2비트가 늘어났다. 일반적인 서브넷 마스크는 255.255.255.0 이었지만 호스트비트중 앞의 두 비트가 1로 바뀌었으므로 다시 계산하면 사용자정의된 서브넷 마스크는 255.255.255.192가 된다.

<그림
<2-22.사용자 정의 서브넷 마스크 계산방법>

여기서 한가지 고려해 볼 것이 있는데, 서브넷 마스크가 바뀌었다는 것이 무엇을 의미할까? 앞에서 우리는 호스트가 TCP/IP통신을 하는 절차를 보았는데 그때 호스트는 목적지 호스트가 자신과 로컬에 있는지 원격지에 있는지를 결정하게 되었다. 그 방법으로 자신의 서브넷 마스크를 이용해서 자신과 목적지 호스트의 네트워크ID를 계산한 다음에 결과값을 살펴서 같으면 로컬, 다르면 원격지로 판단한다고 했다. 위에서 계산된 새로운 서브넷 마스크를 이용하면 하나의 C Class인 207.46.230.0을 사용하더라도 범위에 따라서 서로 다른 네트워크ID라는 결과를 얻을 수가 있게 된다. 결국 하나의 C Class ID로써 여러개의 네트워크ID를 가진 효과를 내게 되는 것이다. 

2-4-2-④ 서브넷 ID 계산

 <그림2-23. Subnet ID 계산>

서브넷팅된 Network ID (Subnet ID)를 계산해야 한다. 207.46.230.0 네트워크 ID는 건드릴 수 없다. 호스트 비트인 8비트 중에서 앞의 2비트를 서브넷ID로 사용하고자 하기 때문에 <그림2-23>에서 노란색부분인 Subnet ID 2비트로써 생성할 수 있는 모든 경우의 수를 구해본다. 위의 그림에서 보듯이 00, 01, 10, 11 이라는 4가지 경우의 수가 나온다. 이것을 십진수로 전환하면 각각 0,64,128,192가 된다. 결국 서브넷 ID를 정리하면 다음과 같다.

- 207.46.230.0

- 207.46.230.64

- 207.46.230.128

- 207.46.230.192

2-4-2-⑤ 서브넷별 호스트ID의 범위 계산

이제 마지막 단계이다. 각 서브네트워크별 사용할 호스트ID의 범위를 구해야 한다. ④에서 구한 4개의 서브넷ID마다 생성할 수 있는 호스트ID의 범위를 구하기 위해 <그림2-24>를 참고해 보겠다.

<그림2-24>의 ①번 서브넷을 예로 들면, 서브넷팅을 하기 전 호스트비트는 8개를 사용할 수 있었지만 서브넷팅을 하고 앞의 2비트를 서브넷 용도로 전환시켰기에 남은 것은 6비트가 있다. 서브넷ID인 처음의 00은 그대로 두고 나머지 6비트를 이용해서 생성할 수 있는 가장 작은 수와 큰 수를 각각 구하면 호스트ID의 범위가 나온다. 여기서 주의할 것은 호스트비트가 전체가 0이되는 경우와 전체가 1이 되는 경우 두 가지를 제외하여야 한다는 것이다.

이미 설명한 바 있지만 호스트비트 전체가 0이되는 주소는 해당네트워크 자신을 나타내고, 전체가 1이되는 수는 해당 네트워크의 브로드캐스트 ID로 사용되기 때문에 호스트에게는 할당할 수 없다. TCP/IP등록정보를 열고 이러한 주소를 입력해 보면 실제로 입력이 되지 않고 에러가 발생하는 것을 확인할 수 있다. 이것을 십진수로 전환해 보면 1과 62가 된다. 첫 번째 서브넷 ID인 207.46.230.0 네트워크에서 쓸 수 있는 호스트ID의 범위는 207.46.230.1부터 207.46.230.62까지로 총 62개의 호스트ID를 사용할 수 있는 것이다. (2⁶-2=62개)

같은 방법으로 2~4번째 서브넷ID의 호스트ID의 범위를 구해보면 다음과 같다.

- 207.46.230.65~207.46.230.126

- 207.46.230.129~207.46.230.190

- 207.46.230.193~207.46.230.254

지금까지 몇단계를 거쳐서 서브넷팅 작업을 해 보았다. 단순히 IP Address의 클래스를 알아보았던 것에 비하면 조금 어렵다는 생각이 들 것이다. 하지만 분명히 필요성이 있는 것이기에 잘 익혀 두어야 한다.

2-4-3. CIDR 표기법

CIDR은 이진표기법을 사용한다. 위의 예제와 같이 서브넷팅된 상황이라면 207.46.230.2 라는 IP Address를 쓰는 호스트는 다음과 같이 표기할 수 있다.

이것은 207.46.230.2 IP Address중에서 26비트가 네트워크ID임을 가리켜 준다. 결국 Subnet Mask는 255.255.255.192라는 것을 알 수 있다.

지금까지 Subnetting의 개념과 구현방법에 대해서 알아보았다. 가장 많이 접할 수 있는 네트워크ID인 C Class를 통해서 예제를 만들어 보았다. B Class라면 더더욱 작업은 쉬워진다. 위의 방법을 토대로 하여 B Class 예제를 하나쯤 다루어 보기 바란다.

2-4-4. CIDR - Supernetting

Subnetting과는 반대의 개념으로 Supernetting을 구현할 수 있다. 상대적으로 중소규모의 회사 차원에서 수퍼넷팅이 구현될 필요는 없다. 개념적인 것을 알아두는 차원에서 다루어 보고자 한다. 한 회사가 192.168.1.0부터 192.168.5.0까지 5개의 네트워크ID를 사용하고 있다고 가정한다. 인터넷상에서 네트워크가 동작하기 위해서는 이 하나의 회사를 위해서 라우팅 테이블이 5개가 추가되어야만 할 것이다.

이경우 보다 효율적인 네트워크를 위해서 라우팅 테이블을 최적화하기를 원한다. 비록 C Class Network ID가 5개라고 할지라도 라우팅 테이블에서는 5개가 아닌 1개의 라우팅 경로만으로 이 회사의 네트워크를 지원할 수 있다면 그만큼 인터넷의 라우터들은 성능의 향상을 가져올 수 있을 것이다. 이런 경우에 수퍼넷팅을 이용하여 라우팅 테이블을 최소화 하는 것이 가능한다.

보다 간단하게 이해를 돕자면 위의 회사에서 5개의 네트워크ID를 사용하는데 물리적으로 하나의 네트워크에 이 5개의 서로 다른 네트워크ID를 할당해서 사용하고 싶다는 뜻이다. 네트워크를 하나로 통합하고 싶다는 것을 의미한다. 어떻게 하면 될까? 역시 서브넷 마스크에 달려 있다는 생각이 들 것이다. 비록 서로 다른 네트워크이지만 서브넷 마스크를 가지고 계산을 했을 때 같은 네트워크ID라는 결과가 나오도록 서브넷 마스크를 조절한다면 이들은 서로 같은 네트워크에 있는 셈이 될 테니까. 어째 생각하면 쉬운 것 같다.

이것을 가리켜서 수퍼넷팅이라고 부른다. 수퍼네팅된 서브넷 마스크를 구하는 방법은 <그림2-26>과 같다.

<그림2-26. 수퍼넷팅 계산방법>

255.255.248.0을 서브넷 마스크로 사용한다면 5개 네트워크의 어떠한 호스트ID를 사용하더라도 하나의 물리적인 네트워크에서 통신이 가능해진다.  예를 들어 192.168.1.100을 쓰는 호스트와 192.168.4.200을 쓰는 호스트가 물리적으로 하나의 세그먼트에 물려 있더라도 255.255.248.0을 사용하면 통신이 가능하다는 것을 말한다. 서로 같은 네트워크 ID라는 결과가 나오기 때문이다.

수퍼넷팅의 이해를 돕기 위하여 위와 같은 설명을 했으나 내부적인 네트워크에서는 위와 같은 처리를 할 이유가 없다. 이것은 어디까지나 인터넷 상에서 네트워크 경로를 최소화하여 보다 원활한 라우팅을 구현하는데 의의가 있다. ISP와 같은 대형 서비스 벤더에서 구현되는 방식이라고 이해하는 편이 좋겠다.

2-4-5. VLSM (Variable Length Subnet Mask)

마지막으로 한가지만 설명을 하고 마칠까 한다. 아래의 <그림2-27>을 보겠다. 이 회사는 192.168.200.0 C Class Network ID를 사용한다. 회사의 네트워크는 그림에서 보듯이 6개의 네트워크로 나뉘어 있는데 각 네트워크마다 서로 다른 노드(컴퓨터,라우터 등 하나의 포트를 차지하는 모든 디바이스를 총칭)를 가지고 있다. 이러한 상황에서 Subnetting을 통해서 6개의 네트워크에서 사용할 수 있는 ID들을 계산해 보고자 한다.

 
<그림2-27. 6개로 세그먼트된 192.168.200.0 네트워크>

위의 상황을 지금까지 배웠던 서브넷팅의 방법으로 계산하려고 하면 뭔가 맞지 않는다는 것을 알 수가 있을 것이다. 6개의 네트워크를 지원해야 하니, 호스트비트 8비트중 3비트를 서브넷 비트로 써야 할 것이다. 거기까진 좋은데 3비트를 서브넷비트로 사용했을 경우 호스트ID로 사용할 비트가 5비트가 되니 5비트를 가지고 만들 수 있는 호스트ID의 수는 2⁵-2=30개가 된다. 그러면 <그림2-27>에서 60node가 있는 네트워크에는 IP Address가 부족하게 된다. 60개의 IP Address를 확보하려면 적어도 6비트는 필요하다.(2⁶-2=62개) 8비트중 나머지 2개의 비트로 서브넷팅을 하면 되는데 문제는 그럴 경우 서브넷ID가 4개밖에 나오지 않는다는 것이다. '응 안되는구나.. '라고만 판단하면 길은 정해져 있다. 네트워크의 수를 줄이거나, 추가로 C Class Network ID를 더 확보하거나, 사설 네트워크로 가는 방법이 있을 것이다.

그렇지만 회사의 전체 호스트수를 더해봐도 194대밖에 되지 않는데 최대 254개의 호스트를 지원하는 C Class 하나로써 이것을 지원하지 못한다는 것은 뭔가 석연치 않다. 이러한 경우 당신은 Subnetting을 효율적으로 운영할 수 있다. 각각의 네트워크에 필요한만큼만 호스트ID를 할당하는 방법을 사용하는데 방법은 다음과 같다.

전체의 서브넷ID를 한꺼번에 계산해서는 안된다. 필요한 부분마다 각각 계산을 해 나가는데 필요한 네트워크ID를 지원하기 위해 필요한 비트수를 계산하는 것이 아니라 필요한 호스트ID를 지원하기 위해 필요한 비트수를 먼저 계산한다. 호스트의 수가 많이 필요한 서브넷부터 먼저 계산해 나가는 편이 좋다.

(1) 60개 호스트를 지원하기 위한 서브네팅

 - 60개의 호스트를 지원하기 위해 필요한 호스트 비트수 = 6개 (2⁶-2=62)

 - 서브넷 마스크는 11111111.11111111.11111111.11000000 (남은 2비트로 서브네팅)

 - 서브넷ID는 서브넷ID중 낮은 자리수의 십진수를 구하면 -> 64 (64씩 증가하는 서브넷)

 - 호스트ID의 범위 2개를 구하면 -> 192.168.200.1~62, 192.168.200.65~126 / 26

(2) 30개 호스트를 지원하기 위한 서브네팅

 - 30개의 호스트를 지원하기 위해 필요한 호스트 비트수 = 5개 (2⁵-2=30)

 - 서브넷 마스크는 11111111.11111111.11111111.11100000 (남은 3비트로 서브네팅)

 - 서브넷ID는 서브넷ID중 낮은 자리수의 십진수를 구하면 -> 32 (32씩 증가하는 서브넷)

 - 호스트ID의 범위 2개를 구하면 -> 192.168.200.129~158, 192.168.200.161~190 / 27

   ( 1~127까지는 이미 앞의 네트워크에서 사용되었음을 유의한다.)

(3) 12개 호스트를 지원하기 위한 서브네팅

 - 12개의 호스트를 지원하기 위해 필요한 호스트 비트수 = 4개 (2⁴-2=14)

 - 서브넷 마스크는 11111111.11111111.11111111.11110000 (남은 4비트로 서브네팅)

 - 서브넷ID는 서브넷ID중 낮은 자리수의 십진수를 구하면 -> 16 (16씩 증가하는 서브넷)

 - 호스트ID의 범위 1개를 구하면 -> 192.168.200.193~206 / 28

   ( 1~191까지는 이미 다른 네트워크에서 사용되었음을 유의한다.)

(4) 2개 호스트를 지원하기 위한 서브네팅

 - 2개의 호스트를 지원하기 위해 필요한 호스트 비트수 = 2개 (2²-2=2)

 - 서브넷 마스크는 11111111.11111111.11111111.11111100 (남은 6비트로 서브네팅)

 - 서브넷ID는 서브넷ID중 낮은 자리수의 십진수를 구하면 -> 4 (4씩 증가하는 서브넷)

 - 호스트ID의 범위 1개를 구하면 -> 192.168.200.209~210 / 30

   ( 1~207까지는 이미 다른 네트워크에서 사용되었음을 유의한다.)

위와 같이 계산을 하여 아래의 <그림2-28>과 같이 IP Address를 배치하는 결과를 얻은 것이다. 가만히 살펴보면 이들 서브넷들은 앞에서의 일반적인 서브네팅과는 달리 서브넷마다 서브넷 마스크가 다르다는 것을 알 수가 있는데 이러한 기법을 가리켜서 "가변길이서브넷"(VLSM; Variable Length Subnet Mask) 기법이라고 한다.

 <그림2-28. VLSM을 이용한 서브네팅>

아직 서브넷팅이 익숙하지 않기 때문에 한꺼번에 4개의 서브넷팅이 부담스러울 수 있겠으나, 위와 같은 방법을 이용하면 보다 효율적인 IP Address 관리가 가능해진다. 전체 호스트에게 IP Address를 할당하고도 아직 192.168.200.212~254까지의 여분이 남아 있다. 추가로 네트워크가 더 생기더라도 할당할 여유가 있게 되었다. 앞의 서브넷팅을 완전히 이해하고 나면 VLSM의 필요성, 방법 등을 이해하기가 쉬울 것이다.

이글을 읽는 독자들은 대부분 20대 이상일 거라는 생각이다. 그렇다면 벌써 십진수와 이진수의 전환하는 계산법 등은 아주 오래전에 다루어 본 일일 것이다. 그 시절로 돌아가서 계산해 보겠다. 언제였던가? 초등학교때였나 아니면 중학교시절이었나.

(1) 십진수를 이진수로 전환하는 법

어떻게 했었더라? 하는 독자들이 있겠지만 한번만 보면.. 아~!! 한다. 십진수를 더 이상 나누어지지 않을 때까지 계속 나누어서 그 나머지들을 아래에서부터 위로 순서대로 나열하면 된다.

  예)    2)  218     (나머지)

          2)  109  ----  0

          2)   54  ----  1

          2)   27  ----  0

          2)   13  ----  1

          2)    6  ----  1

          2)    3  ----  0

                 1  ----  1

      더 이상 2로 나누어질 수 없다. 노란색 부분을 거꾸로 나열하면 11011010 이 된다. 이것은 "218"이라는 십진수를 2진수로 전환한 값이다.

(2) 이진수를 십진수로 전환하는 법

이진수에 각 자리수에 맞는 십진수를 곱해주면 되는데, 그것은 <그림2-17>에서 찾을 수 있다.

    예1) 11111111 = (1x2⁷)+(1x2⁶)+(1x2⁵)+(1x2⁴)+(1x2³)+(1x2²)+(1x2¹)+(1x2⁰)

                          = 128+64+32+16+8+4+2+1 = 255

    예2) 11011010 = (1x2⁷)+(1x2⁶)+(0x2⁵)+(1x2⁴)+(1x2³)+(0x2²)+(1x2¹)+(0x2⁰)

                          = 128+64+0+16+8+0+2+0 = 218

위의 <그림2-17>십진수 변환표를 외워두면 편한다. 익숙해지면 전자계산기가 없이도 10진수와 2진수의 계산이 가능해진다. 예를 들어서 11110011을 십진수로 바꾸려면 전체가1인 경우 255에서 세,네 번째 자리수가 0이므로 거기에 해당하는 십진수인 8과 4를 빼면 된다. 결국 255-8-4=243 이 답이 된다.

거꾸로 계산할 때도 마찬가지이다. 203을 이진수로 전환하려면 첫 번째 자리수부터 203이 될 때까지 계속 채워 나가면 된다. 11이면 128+64이니 합이 192가 된다. 6번째 자리까지 1을 채우면 111이 되어 합이 224로써 203을 넘으니 안 된다. 192에서 203이 되려면 11이 더 필요하다. 11에 해당하는 2진수는 1011이다. 결국 닶은 11001011 이 되는 것이다.

사실 필자 역시 안 해보면 금방 잊혀지는 것중의 하나이지만 급할 때 도움이 된다. 적어도 자리수 정도는 기억을 해 두는 것이 좋다.

(3) 전자계산기 이용

윈도우즈OS에는 보조프로그램에서 계산기를 제공한다. 이것을 이용하면 계산이 용이하다. 계산기 프로그램을 열고, 보기 메뉴에서 "공학용"으로 바꾼다. 왼쪽위에 Hex,Dec,Oct,Bin 이라는 라디오버튼이 있는데 각각 16,10,8,2진수를 의미한다. 이진수 11001011을 십진수로 전환하고 싶다면 먼저 Bin을 선택하고 11001011를 입력한후, <Dec>버튼을 선택하면 된다.

앞의 'IP Address의 이해'장에서 IP Address의 개요에 대한 설명을 한 바 있다. IP Address는 네트워크ID와 호스트ID로 나누어진 다는 것을 알았다. 저번 예제에서 동과 우체국으로 나뉘어졌던 것을 대신해서 이번에는 실제로 라우터와 컴퓨터를 놓고, IP Address를 할당해 보았다. <그림2-15>를 보면서 이야기한다. 예제는 131.107.0.0 과 1331.108.0.0 이라는 두 개의 네트워크로 구성된 환경이다. 이들 네트워크에는 A,B,C라는 세대의 컴퓨터가 있고 각각 적절한 IP Address, Subnet Mask, Default Gateway가 할당되어 있다.  

예제에서 131.107.0.0네트워크에 있는 "B"는 "C"와 통신을 하고자 한다. 통신의 종류는 너무나도 다양하다. 간단하게 B에서 "ping 131.108.0.2"라는 명령을 날릴 경우도 있을 것이고, C컴퓨터가 서비스하는 웹서비스에 B가 웹 브라우저를 띄우고 "http://131.108.0.2"를 입력한 경우도 있을 수 있다. 어떠한 종류의 작업이건 결국은 IP Address를 이용한 통신을 하는 것이기에 B는 C의 IP Address를 목적지로 하는 메시지를 날려 보내야만 한다.

이 단원의 처음에 "같은 동에 속한 사람들끼리는 직접 편지를 교환하고, 다른 동으로 편지를 보내기 위해서는 반드시 우체국을 이용해야 한다."라는 가정을 한 바 있다. 바꿔 말하면 컴퓨터는 TCP/IP통신을 할 때 자신과 같은 네트워크에 속한 컴퓨터와는 직접 통신을 하고, 다른 네트워크에 속한 컴퓨터와 통신을 할 때는 '라우터"를 이용해야 한다는 것을 말한다.

이러한 이유로 B가 C에게 메시지를 보내고자 할 때 첫 번째 해야 할 일은 "C"라는 컴퓨터가 자신과 같은 네트워크에 있는지(로컬인지), 아니면 다른 네트워크에 있는지(원격지인지)를 결정해야 한다는 것이다. 이것을 구분하는 컴퓨터는 IP Address중에서 Network ID부분을 가려낸 다음 Network ID를 서로 비교해 보게 된다. 자신의 네트워크 ID와 상대방 컴퓨터의 네트워크ID가 같다면 당연히 같은 네트워크 임을 의미하고, 네트워크ID가 서로 다르다면 서로 다른 네트워크에 존재한다는 것을 나타내기 때문이다.

문제는 IP Address중에서 도대체 어디까지가 네트워크ID가 차지하는 부분인지를 알 방법이 필요하다는 것이다. 조금 더 자세히 말한다면 IP Address로 사용되는 32비트의 숫자중에서 몇비트가 네트워크ID가 사용하는 부분인지를 알아내야 할 필요성이 있는 것이다. 그것을 가리켜주는 것이 바로 Subnet Mask의 역할이다.

2-2-1. Subnet Mask

Subnet Mask는 IP Address중에서 네트워크ID 부분을 가려내는 역할을 담당한다. Subnet Mask를 잘못 입력하는 것은 통신불가능이라는 문제점을 야기시킬 수 있다. 서브넷 마스크가 IP Address중에서 네트워크ID를 가려내는 일을 하므로 서브넷 마스크가 잘못 할당되어 있으면 IP Address중에서 네트워크ID가 틀리게 가려질 수 있다. 결국은 같은 네트워크에 존재하는 호스트와 서로 다른 네트워크ID를 사용하게 되는 등의 문제가 생길수 있는 것이다. 서브넷 마스크를 제대로 사용하는 것은 중요한 일이다.

좀더 구체적으로 Subnet Mask를 통해서 어떻게 상대방 컴퓨터가 로컬인지 원격지인지를 가려내는지를 알아보겠다. 아래의 <그림2-16>에서는 B의 네트워크ID와 C의 네트워크 ID를 계산하는 방법을 그림으로 표현하였다. B컴퓨터는 통신을 하고자 할 때 가장 먼저 자신의 서브넷 마스크를 이용해서 자신의 IP Address와 상대방의 IP Address로부터 Network ID를 계산한다.

<그림2-16>의 "(1)B의 네트워크ID계산"을 보면, 131.107.3.100을 이진수로 전환했다. 자신의 서브넷 마스크인 255.255.0.0역시 이진수로 전환을 한 다음 And연산을 이용해서 두 수(bit)를 결합시켰다. Bit 에 대한 And연산은 두 수가 1일 때만 1이라는 결과를 나타낸다. (And연산 -> 1=참, 0=거짓, 둘다 참일 때만 참).

값을 계산해 보면 세 번째의 그림인 Network ID결과값을 얻을 수 있다. 이것을 가만히 살펴보면 네트워크 ID결과값중에서 두 개의 옥텟은 IP Address의 두 개의 옥텟과 일치함을 알 수 있다. 서브넷 마스크의 두 개의 옥텟이 11111111.11111111 이므로 당연히 IP Address 쪽의 수자를 따라가게 된 것이다.  세, 네 번째 옥텟은 00000000.00000000 이라는 결과를 보여주는데, 서브넷 마스크의 세,네 번째 옥텟이 00000000.00000000 이므로 (두 수중 둘 다 1일 때만 1, 결국 한쪽이라도 0이면 0이 나온다는 Bit And연산에 따라) 결과값 역시 00000000.00000000 이 나온 것이다. 결국 나온 결과값은 이것을 십진수로 전환하면 131.107.0.0 이라는 네트워크ID를 얻어낼 수 있다.

10000011.01101011.00000000.00000000 이라는 결과값을 십진수로 전환하면 131.107.0.0 이라는 네트워크ID가 계산된다. 당연한거 아닌가 싶지만 우리는 전체적인 그림을 보니까 당연해 보이지만 호스트 입장에서는 IP Address만 가지고 목적지 컴퓨터가 도대체 어느 위치에 존재하는지 심지어는 자신이 어느 위치에 존재하는지도 알 턱이 없다. 이들이 알고 있는 것이라고는 단지 IP Address, Subnet Mask 등의 숫자 몇 개가 고작인 것이다.

같은 방법으로 (2)에서는 C의 네트워크ID를 계산했다. 그 다음에 할 일은 B는 자신의 네트워크ID와 상대방인 C의 네트워크ID를 비교하는 일이다. 이 결과값이 일치하다면 이들 둘은 같은 네트워크ID를 사용하고 있다는 것을(로컬) 의미하며, 다르다면 다른 네트워크ID를 사용하고 있다는(원격지) 것을 의미한다.

결과값이 같다면 직접 로컬에서 통신을 시도할 것이지만 결과가 다르다면 로컬의 라우터의 도움을 받아야 C와 통신을 할 수가 있게 된다. 예제에서는 131.107.0.0과 131.108.0.0이라는 서로 다른 결과를 보여준다. 서로 다른 물리적인 네트워크에 있다는 결과가 나왔다. 제대로 계산이 나왔다.

Subnet Mask가 잘못 입력된다면 통신이 실패한다는 말을 했는데 한가지 상황을 가정해 보겠다.

<그림2-15>에서 A와 B는 같은 네트워크에 있으며, 같은 네트워크ID인 131.107.0.0을 사용하고 있다. 만일 B컴퓨터의 Subnet Mask를 255.255.0.0이 아닌 255.255.255.0을 할당했다고 가정을 하고 결과를 살펴보겠다. B컴퓨터는 일단 A가 로컬에 있는지 원격지에 있는지를 알아내고자 시도를 할 것이고 자신의 서브넷 마스크인 255.255.255.0을 통해서 자신의 IP와 상대방의 IP중에서 네트워크 ID를 계산해 낼 것이다. <그림2-16>을 참고로 해서 결과값을 계산해 보면, B는 131.107.3.0이라는 결과가 나오고, A는 131.107.4.0이라는 결과가 나온다.

이것은 B와 A가 서로 다른 네트워크에 있음을 보여준다. 결국 실제로는 물리적으로 같은 네트워크에 있지만 서로 다른 네트워크ID를 가졌으므로 B는 직접 로컬통신을 시도하지 않고 라우터에게 패킷전송을 요청하게 된다. 이 패킷은 131.107.4.0 네트워크를 찾아서 외부로 나가게 되고, 결국 통신은 실패하게 된다. 이렇듯 잘못된 Subnet Mask를 부여했을 때에는 B는 A와 통신하는 것이 불가능하다. 같은 네트워크에 존재하면서도 네트워크ID가 다르다는 결과가 나왔기 때문이다.

또 한가지 경우, 만일 B의 서브넷 마스크가 255.0.0.0이 할당되어 있다면 어떻게 될까? 결과부터 말한다면 이번에는 같은 네트워크의 A와는 통신할 수 있지만 C와는 통신하는 것이 불가능하다. 차근차근 결과를 계산해보면 답이 나온다. 255.0.0.0 서브넷 마스크를 이용해서 B와 C의 IP Address에서 Network ID를 각각 계산해 보면 같은 결과인 131.0.0.0이 나온다. 물리적으로는 다른 네트워크에 위치해 있으면서 서로 같은 네트워크ID를 사용하게 되면 이들 둘은 통신을 할 수가 없게 되는 것이다.

이렇듯 Subnet Mask도 IP Address못지 않은 중요한 역할을 담당하고 있는데 이러한 Subnet Mask는 어떻게 할당되는 것일까? 이것도 기본적인 원칙이 있다.  

서브넷 마스크 결정방법 IP Address중 네트워크ID 부분은 1로 기록하고, 호스트ID  부분은 0으로 기록한다.

앞에서 각 클래스별로 Network ID가 사용하는 옥텟을 이야기한 바 있다. 거기에 따른 서브넷 마스크를 정리하면 <그림2-19>과 같다.

<그림2-19. Default Subnet Mask>

 

위와 같이 클래스별로 고정된 Subnet Mask를 할당하게 되는데 이것을 가리켜 "Default Subnet Mask"라고 부른다. 특별히 Default라는 표현을 썼다는 것은 뭔가 냄새를 풍긴다. 그렇지 않을 수도 있다는 것을 의미하는데, 각각 8비트, 16비트, 24비트 등으로 고정된 길이만큼 네트워크ID가 사용되는 것이 아닌, 클래스개념을 무시한 IP Address관리방법이 제공되기 때문이다. 이것을 CIDR(Classless Inter Domain Routing)이라고 한다. IP Address를 효율적으로 관리하기 위한 필수적인 개념인만큼 정리를 해 보도록 하겠다. 다음 장에서 CIDR, VLSM등에 대해서 설명한다.

 

2-2-2. Default Gateway

 

호스트가 TCP/IP통신을 할 때 가장 먼저 목적지 호스트가 자신과 같은 로컬에 있는지 원격지에 있는지를 판단한다고 했다. 이때 원격지에 있는 결과가 나오면 컴퓨터는 Default Gateway를 이용해서 통신을 하게 된다. 결국 Default Gateway를 정리하면 "자신의 네트워크에 있는 라우터의 로컬 인터페이스의 IP Address"라고 할 수 있다.

 

라우터도 역시 자신의 네트워크에 있는 하나의 호스트처럼 생각하면 된다. 하는일이 다를 뿐이지 통신에 있어서는 차이가 없다. 만일 목적지 호스트가 로컬에 있다면? 그때는 Default Gateway는 쓰임새가 없다. Default Gateway가 없어도 로컬네트워크와의 통신에는 아무런 문제가 없음을 말하는 것이다.

 

<그림2-20. 로컬 컴퓨터의 라우팅 테이블>

 

위의 그림은 Windows환경의 OS에서 라우팅 테이블을 확인해 보았다. Ipconfig 를 통해서 Default Gateway가 192.168.5.1인 것을 알 수 있다. 그 다음에 Route print 명령을 실행하니 라우팅 테이블을 보여준다. 하이라이트된 부분을 보니 다음과 같다.

Network Destination            Netmask              Gateway              Interface               Metric 0.0.0.0                    0.0.0.0              192.168.5.1           192.168.5.5                  1

0.0.0.0 이 Default Gateway를 나타내는 테이블이다. 만일 이 호스트에서 “Ping 192.168.6.200”이라고 명령을 실행하였다면 192.168.6.0네트워크는 라우팅 테이블에 명시되어 있지 않은 네트워크이기 때문에 어디로 패킷을 내 보내야 할지 모르게 된다.

이때 이 호스트는 0.0.0.0 으로 시작하는 이 테이블을 이용해서 통신을 시도하게 된다. 네트워크로의 통신은 이 테이블 항목을 사용해서 통신을 시도한다. 이것을 해석해 보면, 192.168.5.5로 셋팅된 네트워크 어댑터 카드를 통해서 192.168.5.1에게 패킷을 내 보내라는 것을 의미한다. 결국, 네트워크 경로에 명시되지 않은 모든 네트워크를 목적지로 하는 패킷은 192.168.5.1에게 보내서 통신을 처리하라는 것을 알 수 있다. 이것이 기본게이트웨이 이다.

간혹 TCP/IP 등록정보에서 볼때는 기본게이트웨이가 잘 셋팅되어 있지만 라우팅테이블이 없어지는 경우가 발생한다. 이럴 경우는 당연히 이 호스트는 외부 인터넷 환경으로는 접근이 되지 않게 되는데 그때는 문제해결이 쉽지 않다. 문제해결을 위해 TCP/IP등록정보를 확인해 봐도 아무런 문제가 없기 때문이다. 그때 route print 명령을 이용하여 0.0.0.0 경로가 잘 살아있는지를 확인해 볼 필요가 있다. 만일 없다면 기본게이트웨이가 설정이 되어 있지만 없는것과 마찬가지이다. 그럴 때는 route add 명령을 이용해서 직접 추가해 주거나, TCP/IP등록정보를 열고 기본게이트웨이를 지웠다가 다시 생성해 주면 해결된다. 라우팅 테이블에 0.0.0.0 경로가 살아났는지 확인하는 것은 당연한 일이다.

<그림2-7>에서의 호스트는 IP Address로써 "192.168.5.3"이라는 숫자를 사용하고 있다. 이 IP Address를 살펴보면 3자리 숫자가 4개가 모여있고, 사이사이에는 dot로써 구분을 해 주고 있다. 이 3자리 숫자는 우리에게 익숙한 10진법으로 표기가 되어 있는 것을 알 수 있다.

<그림2-7. TCP/IP 등록정보>

그렇다면 아래의 그림을 보자.

<그림2-8. IP Address 입력 오류 메시지>

TCP/IP 구성을 수동으로 하다 보면 가끔 <그림2-8>와 같은 메시지를 받는 경우가 있다. <그림2-8>의 메시지를 보면 256이라는 숫자를 입력하려고 시도했을 때 "256의 항목이 올바르지 않다. 0~255사이의 값을 지정하라"는 메시지를 보여주고 있다. 이상한 생각이 든다. 10진수라면 3자리를 가지고 만들 수 있는 가장큰 수는 999 여야 하는데, 256을 넣었더니 입력이 되지 않고 0부터 255사이의 값을 지정하라고 한다. 그렇다. 10진수로 표기를 하고 있지만 내부적으로는 10진수가 아닌 것이다. 그렇다면 어떻게 구성이 되어 있을까?

IP Address는 디자인될 때 32개의 비트를 사용하여 IP Address를 만들어졌다. 다시 말하면 0 아니면 1인 값이 32개가 나란히 늘어서 있는 것이 IP Address를 구성하고 있다는 것을 의미한다. 아래의 <그림2-9>를 보면서 설명한다.

<그림2-9>에서는 192.168.5.2 라는 IP Address를 예제로 보여주고 있다. IP Address는 십진수도 아니고 세자리 숫자 4개가 3개의 dot(.)로 구분된 것도 아니다. 단지 0 아니면 1인 비트가 32자리가 쓰여 있을 뿐인 것이다. 32bit이니 결국 4Byte이다. 현재 우리가 사용하는 IP Address의 버전은 "4(Four)"이고 이 버전 4는 32bit 즉 4Byte체계의 IP Address를 사용하고 있다. 이러한 32bit숫자를 그대로 시스템의 IP Address로 사용한다면 우리가 사용하기는 꽤 어려울 것이다. 0아니면 1인 숫자가 32자리가 배열이 되어 있으면 사용하기가 어려울 수 밖에 없다. 그런 이유로 보다 편한 표기법을 채택하고 있다. 일단 8bit씩 나눠서 구분을 한다. 8bit면 1Byte이니 구분하기가 한결 용이해진다. 이렇게 나뉜 하나하나의 단위를 "8"을 나타내는 "옥텟 (Octet)"라고 부른다. 32bit를 8bit씩 나누니 4개의 8bit. 즉 4개의 octet가 생겼다. 이들 octet와 octet를 구분하기 쉽게 하기 위해 dot(.)를 구분자로 사용하였다. 마지막으로 각각의 옥텟 단위별로 2진수를 10진수로 변환하여 놓은 것이 바로 우리가 사용하고 있는 IP Address이다.

아래의 <그림2-10>을 보겠다. 3단계로 나눠서 보면, 맨 위의 그림은 32개의 자리수를 가진 빈 상자가 있다. 여기에 0, 1 둘중의 한가지 숫자를 채울 수가 있을 것이다. 첫 번째의 옥텟만 가지고 계산을 해 보았다. 8bit 자리에 넣을 수 있는 가장 큰 숫자는 여덟 개의 비트 전체가 "1"로 만들어지는 숫자가 된다. "11111111"을 십진수로 계산하면 "255"라는 결과를 얻을 수 있다. 이렇게 되면 위에서의 의문이 풀린다. 왜 IP Address로 할당할 수 있는 최대숫자가 999가 아닌 255가 되는지를 알 수 있을 것이다. 그렇게 전체 옥텟을 채워보면 255.255.255.255가 나온다. 이것이 IP Address로 사용될 수 있는 가장 큰 주소이다.

위에서 우리는 IP Address가 32개의 bit로 이루어진 값이라는 사실을 알 게 되었다. 이제 그러면 이러한 IP Address가 어떠한 체계로 관리가 되는지 알아보도록 하자. 현재 IP Address는 IANA(Internet Assigned Numbers Authority)라는 기관에서 관리되고 있다. IANA는 전체 IP Address를 관리하며 ISP(Internet Service Provider)들에게 IP Address를 발급하고, 일반 사용자들은 그러한 ISP로부터 IP를 할당받아서 호스트에게 할당하고 인터넷에 액세스하게 되는 것이다. 당연히 IP Address가 무작위로 할당되지는 않는다. 이 IP Address는 Class 라는 특별한 개념에 근거하여 관리되고 있다. 자세히 알아보자.