컴퓨터 네트워크 10주차

---

 

IP 주소는 라우터 각각의 인터페이스와 연관. 많은 사람들이 착각하는 것이 IP 주소가 호스트 또는 라우터에 붙여지는 주소라고 생각하는 사람이 많은데, IP 주소가 호스트나 라우터에 붙는 게 아니라 호스트 또는 라우터의 인터페이스에 붙여주는 이름이다. 무슨 말이냐면 네트워크 접속을 위해 상요하는 네트워크 인터페이스 카드(랜카드)에 붙여주는 주소이다. 알겠냥!

위 그림을 보면 라우터에는 223.1.1.4, 223.1.2.9, 223.1.3.27 세 개의 IP 주소가 붙은 걸 볼 수 있다, 즉, 라우터는 가지고 있는 각 인터페이스마다 IP 주소가 붙는다. 위 라우터는 랜카드를 3개 가지고 있는 것을 알 수 있다.

 

 

Subnet이란

subnet은 무엇인가? ⇒ IP 주소가 동일한 subnets part를 가지고, 중간에 라우터가 없는 그룹이라고 이해하면 된다. 위 그림에서는 각 인터페이스를 연결하는 네트워크 기기가 있을 텐데, 라우터는 아니다. 즉, 223.1.1.1과 223.1.1.2, 223.1.1.3, 223.1.1.4 는 중간에 라우터 없이 연결돼 있으므로 같은 subnet 이라고 할 수 있고, 라우터를 거치면 같은 서브넷 그룹이라 하지 않는다. (

라우터는 절대 포함하지 않는다. 라우터 내부를 거치게 되면 다른 서브넷 그룹으로 구분된다)

 

<6개의 서브넷>

 

 

CIDR(Classless InterDomain Routing)

CIDR이란 무엇인가? 초기의 인터넷에서는 class로 구분을 했다. A class는 가장 큰 네트워크로서 가장 많은 호스트 인터페이스들에게 주소를 줄 수 있는 네트워크이고 이렇게 순차적으로 B class, C class, D class로 구분을 했지만, 이렇게 구분을 지어서 IP를 분배 하다보니, IP의 효율적 분배를 하지 못했다, 즉, IP가 낭비되었다. 그래서 이런 IP 낭비를 없애기 위해, IP를 효과적으로 사용하고자 등장한 게 CIDR 개념이다.

• 서브넷 파트를 구분하는 숫자가 임의로 정해질 수 있다. 무슨 말이냐면 예전에 class로 서브넷을 구분할 때는 A class는 8bits, B class 16 bits C class 24 bits 등 정해진 숫자로 구분이 되었다면 CIDR 표기법을 이용하면 200.23.16.0/23 이렇게 구분할 수 있다. 이렇게 구분하면 23 bits가 서브넷 그룹이고, 나머지 9 bits가 호스트 bits이다. 즉, 앞에 23 bits 가 같으면 같은 서브넷 그룹으로서 같은 네트워크 그룹에 속한 호스트라고 생각하면 된다.

 

---

 

호스트 인터페이스가 어떻게 IP 주소를 획득할까?

• 호스트 인터페이스가 파일 형식으로 하드 코딩

• DHCP(Dynamic Host Configuration Protocol, 동적 호스트 설정): 플러그 인 플레이 방식으로 동적으로 DHCP 서버로부터 IP 주소 획득

 

DHCP Protocol: 어떤 호스트가 네트워크(인터넷)에 참여하고자 할 떄, DHCP 서버로부터 IP 주소를 동적으로 얻을 수 있도록 허용.

• 사용 중인 address에 대해서는 대여 기간을 renew(최신화)할 수 있다.

• 사용하고 있는 주소를 재사용 허가(연결되어 있는 동안에는 사용하고 있는 주소 계속 사용을 할 수 있지만, 네트워크 연결이 끊기면 Host A가 사용하던 주소는 Host B에게 넘겨줄 수 있다. → 효율적인 주소 운영)

• DHCP를 통해서 모바일 와이파이 유저를 신속하고 효율적으로 주소 제공

• DHCP 작동 방식
  1. 호스트가 DHCP discover라는 메시지를 브로드캐스트
  2. DHCP 서버가 DHCP offer 라는 메시지로 응답
  3. 그럼 호스트가 DHCP request 메시지를 통해서 IP 주소 요청
  4. DHCP 서버가 DHCP Ack 메시지를 통해서 IP 주소 전달

 

 

※DHCP 서버는 DHCP가 속해있는 서브넷 그룹 내에서만 사용!!

위 그림을 보면 호스트가 DHCP 서버에게 IP 주소를 요청하면 DHCP 서버는 현재 사용 중인 223.1.2.9, 223.1.2.1, 223.1.2.2를 제외한 223.1.2.0/24 에 속하는 주소 중 하나를 발급해준다

 

 

 

1. 클라이언트가 DHCP discover 라는 메시지를 해당 서브넷 내에 있는 인터페이스들이 모두 메시지를 받을 수 있도록 브로드캐스트. 즉, '혹시 DHCP 서버가 여기 서브넷에 있나요?' 라고 방송하는 것과 같다.

2. 해당 방송 내용을 받은 223.1.2.5 인터페이스를 가진 DHCP 서버는 호스트에게 DHCP offer(ip 주소, 포트번호, 유효기간 등)로 호스트에게 사용할 수 있는 IP 주소로 응답을 한다. 이 때 DHCP 서버는 호스트에게 어떻게 IP 주소를 알려줄 수 있을까? 호스트는 IP 주소가 없는데 말이다. DHCP 서버가 호스트에게 IP 주소를 알려줄 때는 호스트와 마찬가지로 브로드캐스트(서브넷 그룹 내 모든 호스트가 수신할 수 있는)로 알려줘야 한다.

3. DHCP 서버에게 IP 정보를 받은 호스트는 해당 IP 주소를 받았다고 DHCP request를 보내게 된다. 여기서 한 가지 의문점은 이제 호스트는 IP 주소를 받았는데 왜 DHCP 서버에게 응답할 떄 브로드캐스트로 보낼까? → 서브넷 그룹 내 다른 호스트들에게 모두 알리기 위해 브로드캐스트로 보내는 것이다.

4. DHCP 서버는 호스트의 응답을 받았다고 다시 ACK를 보내준다.

실제 송수신되는 메시지

1. DHCP discover
   • src: 0.0.0.0, 68 ⇒ 0.0.0.0 (자기가 가지고 있는 IP 주소가 없다는 의미, 68은 포트넘버)
   • dest: 255.255.255.255, 67(255.255.255.255는 브로드캐스트 주소이므로 해당 서브넷 그룹 참여자들 모두 수신 가능. 67은 포트 넘버)
   • yiaddr(your ip address): 0.0.0.0(자기가 사용할 주소를 달라는 의미)

2. DHCP offer
   • src: 223.1.2.5(DHCP server 주소), 67(포트 넘버)
   • dest: 255.255.255.255(호스트는 아직 IP 주소가 없으므로 offer 메시지를 받기 위해 브로드캐스트로 송신), 68(포트 넘버)
   • yiaddr: 223.1.2.4(해당 클라이언트가 사용할 IP)
   • transition ID: 654(이건 뭐지?)
   • lifetime: 3600 secs(호스트에게 부여할 IP 주소 lifetime, renew 가능)

3. DHCP request (호스트가 수신한 값 확인)
   • src: 0.0.0.0(호스트는 주소를 부여받았는데 왜 0.0.0.0으로 등장할까?), 67(포트 넘버)
   • dest: 255.255.255.255(브로드캐스트), 67(포트 넘버)
   • yiaddr: 223.1.2.4 (호스트가 확인한 IP값)
   • transition ID: 655(1을 증가 ← 이건 뭐하는 걸까?)
   • lifetime: 3600 secs(호스트가 확인한 생명주기 재확인)

4. DHCP ACK(서버에서 확인했다고 호스트에게 전송하는 값)
   • src: 223.1.2.5(DHCP 서버 주소), 67(포트넘버)
   • dest: 255.255.255.255(브로드캐스트), 68(포트 넘버)
   • yiaddr: 223.1.2.4
   • transition ID: 호스트 구분하는 값인 듯함. DHCP에게 동시에 많은 호스트가 IP를 요청할 수 있으니, 호스트 임의로 자기를 구분하기 위해 처음 생성해서 서버에게 보내고, DHCP request에서부터 transition ID를 1 증가시켜서 구분하는 듯)
   • lifetime: 3600 secs

 

★★★★★DHCP는 호스트가 사용할 IP주소만 할당하는 것에 머무르지 않고, 더 많은 정보들을 전송한다. ★★★★★

1. 클라이언트가 마주치게 될 첫 번째 라우터의 인터페이스 IP 주소(default gateway) ⇒ 왜 알려줄까? IP를 부여받은 호스트가 인터넷에 접속했는데, 호스트가 속한 서브넷 호스트들하고만 통신할 게 아니라 서브넷을 벗어나서 다른 서브넷 그룹들과 통신해야 하는데, 내 서브넷을 벗어나려면 first-hop(gateway)를 반드시 거쳐야 하기 떄문에, gateway 주소가 있어야 한다.

2. DNS 서버의 이름과 IP 주소 ⇒ 그렇다면 DNS 서버는 반드시 내가 속한 서브넷에 있어야 할까? NO. 나는 이미 라우터의 IP를 알기 때문에 반드시 서브넷 내에 DNS 서버가 없어도 first-hop 라우터를 거쳐서 DNS 서버로 요청하면 된다.(외부로 나가는 건 라우터가 다 처리해주기 때문에)

3. network mask(subnet mask): 네트워크 그룹과 호스트 그룹을 구분하는 값

 

 

 

---

네트워크는 자신이 사용할 IP 주소의 subnet 파트를 어떻게 얻을까?

가령, 학교에서 컴퓨터공학과에 사용할 IP 주소들은 어떻게 얻을 수 있을까? ⇒ 이건 보통 ISP(Internet Service Provider)가 확보하고 있는 주소 영역의 일부를 할당해준다. 즉, ISP가 가지고 있는 블록의 일부를 나누어준다. 위 예를 보면, 11001000 00010111 0001(20 bits)가 네트워크 주소인데 조직 0 ~ 조직 7까지 주소 블록 일부를 나누어준 것을 알 수 있다. 조직 0 ~ 조직 7까지 IP를 할당하고 남은 주소 블록은 컴퓨터공학과에서 사용

 

IP 주소는 계층적인 주소 체계를 가지고 있다. 즉, A 네트워크 그룹은 B ISP 그룹과 연결돼 있고, C 네트워크 그룹은 D ISP 네트워크 그룹과 연결돼 있는 식이다. 즉, 위 그림으로 예를 들자면, 20비트의 네트워크 그룹은 200.23.16.0으로 보내고, 네트워크 그룹이 23 bits이면 200.23.18.0 보내는 방식이다.

 

그렇다면 한 단계 더 나아가서 ISP는 네트워크 그룹을 어떻게 얻을 수 있을까? ⇒ ICANN 이라는 전체 도메인 네임이나, IP 주소를 관리하는 범세계적인 조직에서 할당받는다.

 

 

현재 인터넷은 IPv4 주소 체계를 채택해서 운영되고 있다. IPv4는 32비트 방식으로 약 43억 개의 주소를 표현할 수 있다. 43억 개의 주소, 굉장히 많은 숫자처럼 보이지만 현재는 뭔가 부족해 보인다. 현 시점(2021-05-02) 유엔이 집계한 전 세계 인구만 해도 약 76억 4047만 명인데, 주소가 43억 개밖에 안 된다니, 전 세계 모든 사람이 인터넷을 사용하는 게 아니라고 하더라도 43억 개로는 전 세계 모든 디바이스가 인터넷 세계에 참가하기에는 매우 부족해보인다. 나만 하더라도 데스크탑, 노트북, 태블릿, 휴대폰 등 다양한 디바이스로 인터넷에 접속하는데 나 같은 사람이 10억 명만 있어도 이미 IPv4 주소는 거널나 있을 것이다. 그래서 2011년 2월 4일부터 모든 IPv4 주소가 소진돼서 IPv4 주소할당이 중지되었다. 많은 서적이나 인터넷에 있는 문서에 의하면 처음에 IPv4를 설계한 사람들은 사실인지는 알 수 없으나 인터넷 주소가 43억 개면 충분하다고 생각했다고 한다. 즉, 인터넷에 참여하는 디바이스들이 이렇게 산술기하, 아니 기하급수적으로 증가할지 몰랐다는 것이다.

사실 위에서 사용할 수 있는 IP 개수를 43억 개 정도라고 언급했지만, 실질적으로 사용할 수 있는 개수는 2억 5천만 개 정도이다. IPV4에서는 부족한 주소 개수를 대응하기 위해 private IP, subnet, DHCP 등 여러 가지 대안을 도입했지만, 그중 대표적인 private IP에 대해서만 알아보자.

위 그림에서 locale network라고 표시된 지역에서 사용하는 IP는 모두 private IP이다. private IP란 일반 가정이나 회사 내 등에 할당된 네트워크 IP 주소이며, 로컬 IP, 가상 IP라고도 하면 Private IP 주소 대역은 10.0.0.0 ~ 10.255.255.255, 172.16.0.0 ~ 172.31.255.255, 192.168.0.0 ~ 192.168.2255.255 이다. 이 IP 범위에 있는 디바이스들은 모두 다 Private IP를 부여 받은 것이며 외부의 Public IP 디바이스와 통신하기 위해서는 별도의 작업이 필요하다. 우리 집을 예를 들어보자. 우리 집은 현재 SK라는 ISP에서 Public IP를 대여하고 있다. 이 Public IP는 서로 다른 권역과 통신할 수 있는, 즉 현재 IPv4 체계의 43억 개의 IP 중 하나이다. 반대로 우리 집에서 사용하는 노트북, 데스크탑, wifi에 연결된 스마트폰의 아이피는 조회해보면 192.X.X.X 라고 뜰 것이다. 이건 Private IP이다. 스타크래프트를 떠올리면 이해가 쉽다. 옛날에 PC방 가서 친구들과 LAN에서 만나서 스타크래프트를 즐겼다면 이건 Private IP 대역에서 게임을 한 것이고, 배틀넷으로 다른 PC방에 있는 친구들과 게임을 했다면, 이것은 Public IP로 통신을 한 것이다. 즉 이 Private IP로 부여 받은 디바이스들은 같은 네트워크 지역에서는 자유롭게 통신을 할 수 있지만, 말 그대로 사설 IP이기 때문에 저기 대구에 살고 있는 내 사촌이 우리 집의 내 PC와 통신하기 위해서는 우리 집이 부여 받은 Public IP를 거쳐야 한다. 하나의 네트워크 권역에 부여 받은 Public IP로 외부와 통신하고 내부적으로는 Private IP를 사용한다. Private IP를 사용하는 디바이스가 다른 네트워크 권역의 디바이스와 통신하기 위해서는 ISP에게 부여 받은 Public IP를 거쳐서 통신하는 것이다. 이런 기술을 NAT(Network Access Translation) 라고 한다. NAT는 어느 정도 보안성을 제공하는 동시에 외부에서 볼 때는 내부에 IP 인터페이스를 가진 디바이스가 몇 개가 있든간에 오로직 하나의 IP로만 본다. (local network uses just one IP address as far as outside world is concerned)

 

NAT router는 어떻게 구현할까?

• outgoing datagrams: 외부로 나가는 데이터그램에 대해서 source ip와 port를 nat ip와 new port 번호로 바꿔준다. 이 바꿔준 정보를 어딘가에 적어줘야 한다(book keeping)

• nat translation table에 모든 source ip 정보와 port 넘버와 nat ip 주소와 port 쌍을 적어줘야 한다.

• 라우터에 들어오는 데이터그램에 대해서는 nat translation table를 참고해서 source ip 번호와 port 정보(private)으로 바꿔준다.

 

 

 

NAT 기술에서 가장 중요한 것은 port 이다. private IP는 내부 서브넷 그룹에서만 구분되는 역할이지, 외부에서 볼 떄는 모두 똑같은 IP이다. 그러면 개별 디바이스들을 어떻게 구분할까? ⇒ Port 번호

하지만 port 넘버를 사용하는 것에는 논란의 여지가 있다. Router layer 3(network)까지만 처리를 해야 하는데 NAT를 사용하면 port 번호를 사용하게 되는데, port 번호는 Layer 4에서 다루는 기술 아니야? 즉, '야 Layer 3까지만 다루는 기기에서 Layer 4까지 건드려?' 라고 반문하는 사람들이 있는 반면, '그래도 NAT 기술 덕분에 IP 주소 부족 문제를 해결했잖아' 라고 반박하면 또, 그에 대한 반박으로 '야, 주소 부족 문제는 새로운 IP 프로토콜을 버전 업해서 해결해야지, 상위 레이어의 기술을 끌어다가 쓰는 건 좀 아니지 않니?' (이런, 논란이 있다...)

NAT를 사용하면 P2P 애플리케이션을 사용할 때 문제가 생긴다. ⇒ 만약에 클라이언트가 NAT 뒤에 있는 서버, 즉 외부 클라이언트가 NAT 뒤에 있는 서버에 접속하고 싶은데, 해당 서버는 지금 private IP를 사용하고 있기 때문에 외부 클라이언트가 NAT 없이는 접근할 수 없다. NAT Translation Table은 내부 네트워크에서 외부 인터넷으로 나갈 때 생성된다. 그런데 만약에 서버가 로컬에 있고, 클라이언트가 외부에 있으면, 서버가 최초로 클라이언트에 접근하는 게 아니라, 클라이언트가 서버에 최초 접근하기 때문에, 아직 서버 쪽에서 외부로 내보낸 데이터 그램이 없으므로 NAT Translation Table이 생성되지 않았다. P2P 애플리케이션이 NAT에 취약하다. 이런 이슈는 어떻게 해결해야 할까? 최초의 local network에서 데이터 그램을 안 내보냈기 때문에 생긴 문제이므로 서버가 클라이언트에 데이터그램을 보내는 게 아니더라도 최초에 한 번만 데이터 그램을 내보내기만 하면 NAT Translation Table이 생성되므로 최초에 한 번만 외부 네트워크로 데이터 그램을 보내자. 실제로 이 이슈를 가장 성공적으로 푼 서비스가 스카이프다. 스카이프는 슈퍼 노드 한 개를 지정해서, 처음 설치 시에 슈퍼 노드에 등록하는 절차로서 peer가 외부 인터넷에 접속하게 해서 NAT를 생성했다.