달력

3

« 2024/3 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
2008. 11. 11. 13:02

2-3. Subnet Mask, Default Gateway Windows Networking2008. 11. 11. 13:02


앞의 '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가 할당되어 있다.  



<그림2-15. 2개의 네트워크 ID>

 

예제에서 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. 목적지 컴퓨터가 로컬인지 원격인지 결정하는 방법>

 

<그림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를 부여했을 때에는 BA와 통신하는 것이 불가능하다. 같은 네트워크에 존재하면서도 네트워크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 경로가 살아났는지 확인하는 것은 당연한 일이다.

:
Posted by 새벽예찬