항공대학교 최차봉 교수님의 강의를 참고하여 작성하였습니다.
전 포스팅에서 IPv4를 두고 많은 이야기를 했다.
IP address를 Class로 나누어도 보고, Subnet portion을 할당해보기도 하고, 또 CIDR 방식으로 IP주소를 나누어도 보았다.
이번엔 IP 고갈 문제를 해결하기 위해 고안된 방법 중 CIDR 를 제외한 나머지 3가지 방식에 대해 알아보자!
맨 처음 IPv4가 고안된 후, 계속해서 IP 주소가 고갈될 것이라는 압박감속에 만들어낸 첫 고갈 문제 해결 방법은 전 포스팅에서 알아보았던 CIDR 방식의 IP주소 할당법이었다. 이를 통해 IP 주소를 좀 더 효율적이고 구조적으로 할당할 수 있었다.
그 뒤로 DHCP, NAT, IPv6 가 차례차례 고안되었는데, 그 중 DHCP 방식을 먼저 알아보자
<DHCP>
Dynamic Host Configuration Protocol 로써 이 방식의 유래에 대해 나무위키에 검색해보았다.
Dynamic
Host
Configuration
Protocol
직역하자면 '동적 호스트 설정 프로토콜(통신규약)'이다.
IP 라우터는 인터페이스 및 호스트에 IP 주소를 할당해 줄 수 있다. 예전에는 각 PC마다 고정 IP 설정을 도입하여 사용 하거나, RFC 903에 정의된 것처럼 RARP를 도입하여 동적으로 적절한 IP 주소를 취득할 수 있게 구현하여 사용하였다. 고정 IP 설정의 단점은 무엇보다도 IP 설정에 실수가 있는 경우 인터넷이 안 된다. 예를 들어 실수로 오타가 날 경우도 있고, 실수로 다른 컴퓨터와 동일한 IP를 할당하여 충돌나는 경우도 존재한다. 그외에도 사용하지 않고 꺼놓은 컴퓨터에도 모두 IP를 하나씩 할당해야 하다 보니 IP가 모자라는 문제도 발생한다. 후자로 사용한 RARP의 단점은 데이터 링크층에서 작동되었어야 했으므로 하드웨어로서 구현이 어려웠으며, 서버가 각각의 네트워크에 존재해야만 한다는 단점이 있어 추후 DHCP가 발표되며 사장되었다.
이런 문제를 해결하기 위해서 IP를 필요로 하는 컴퓨터에게 자동으로 할당해서 사용할 수 있도록 해주고, 사용하지 않으면 반환받아 다른 컴퓨터가 사용할 수 있도록 해주는 것이 DHCP이다. 이는 보통 라우터 장비에 해당 기능이 탑재되지만, 별도의 서버 에 DHCP 서비스를 설정하여 사용할 수도 있다. 라우터는 단지 게이트웨이 역할만 하고, DHCP 서버는 별도로 두는 구성도 많이 사용된다.
결국 모든 말단 디바이스에 고정 IP를 설정하게 되면, IP가 당연히 모자를 수 밖에 없다. 사용하지 않게 되는 디바이스에도 IP주소를 부여하자니 효율이 좋지가 않고, 이 static IP는 사용자가 직접 설정해야 하는데, 이 과정에서 실수로 오타가 나 IP 주소가 중복되는 문제도 생기기 마련이었다.
그래서 이 IP주소를 동적으로, 자동으로 서버로부터 할당하고, 만약 사용하지 않으면 그 디바이스를 연결 대상에서 제외시키고 연결이 필요한 다른 디바이스의 IP주소로 재활용 할 수 있도록 하는 시스템이 DHCP이다.
DHCP는 "Plug and Play" 방식으로도 불린다.
DHCP는 총 4단계에 거쳐 IP주소를 할당한다.
1. Client 의 Broadcast 단계 "DHCP discover "
2. Server의 대답 " DHCP offer "
3. Client의 확답 " DHCP request "
4. Server의 ACK 전송 " DHCP ack "
** User는 68번 포트를, Server는 67번 포트를 사용한다.
이 4가지 단계 discover -> offer -> request -> ack 에 대해서 알아보자.
현재 새로운 DHCP client가 IP주소를 요구하고 있는 상황이다. DHCP server의 subnet part는 223.1.2.0/24 으로, IPv4 기준임을 고려했을때 32 - 24 = 8. 즉 2^8 개의 IP 주소를 host에게 할당할 수 있는 상황이다. ( 사실 2개를 빼면 2^8 => 256 에서 2를 뺀 254 개의 호스트가 할당 가능)
1. Discover by Client
먼저 클라이언트는 특정 수신자를 지정하지 않고 그냥 본인이 IP주소가 필요하다는 메세지를 서버에 던진다. 이를 BroadCasting 이라고 하며, 이는 우리가 넷플릭스에서 영화를 골라 관람하는 형태(1대1 소통) 와는 달리, 방송국에서 시청자들에게 방송을 틀거나, 라디오로 전파하는 방식과 같다.
여기서 Client는 본인의 transaction ID를 메세지에 함께 포함시켜, 서버가 본인에게 응답을 줄 수 있도록 플래그를 준다.
2. Offer by Server
서버는 이 Broadcast msg를 확인하고, 새로운 IP 주소를 client에게 보여준다. 위 그림에서 보면 yiaddrr이 223.1.2.4 로 부여된 것을 볼 수 있다. 하지만 이렇게 Server가 IP주소를 보내줬다고 해서 Client가 오케이 감사 하고 그냥 써버릴 수가 없다. 다음 단계가 필요하다.
3. Request by Client
클라이언트는 본인이 부여받은 IP주소를 담은 Request msg를 다시 "브로드캐스팅" 한다.... 에?
여기서 의문점이 들 수 있다.
"아니 이미 서버로부터 IP주소를 받았는데 왜 또 브로드캐스팅을..? 그냥 그 서버랑 단둘이 소통하면 되잖아 이제"
라고 할 수 있지만, Request 단계에서 브로드캐스팅을 하는 이유는 크게 2가지가 있다.
1. DHCP가 여러 개 일수도 있기 때문
: 그게 무슨 상관인가 싶겠지만, DHCP 서버가 여러개라는 것은, 한 서버가 브로드캐스팅을 하면 여러 개의 offer가 올 수도 있다는 뜻이다. 그럼 Client는 그 여러가지 서버의 offer 중 어느것을 선택해서 사용할 것인지 선택받지 않은 offer를 준 서버에게 알려줘야 하기 때문에 그렇다. 이를 판단하는 기준은 가장 먼저 도착한 offer 메세지를 선택하는 것이 일반적인 기준이다.
2. Request 단계에서는 아직 IP가 없는 상태..
: IP 가 확정되지 않은 상태의 client는 기본적으로 브로드캐스트를 사용해야만 한다
뭐 이러한 이유가 있다. 만약 내가 집을 구하려고 여러 부동산에 연락을 했는데, 그 중 한 곳에 계약을 하기로 했으면, 나머지 부동산에 "저 계약했으니 다른 사람 알아보세요~" 라고 알려주는 것과 비슷하다.
4. ACK by Server
서버는 본인이 준 IP 주소를 사용하겠다고 Request가 온 Client에게 ACK 메세지를 날려야한다. Transport Layer에서 배웠듯이 Client와 Server의 Handshaking 과정에서의 OK sign은 ACK이기 때문이다.
*** 여기서 Server 가 Client에게 단순히 상대가 쓸 IP주소만 주는 것이 아니라, 실제로 클라이언트가 네트워크에서 정상적으로 작동하는데 필요한 다양한 정보들을 함께 제공한다.
1. First-hop Router
: 인터넷 등 외부 네트워크로 나갈 때 통과할 라우터의 주소
2. DNS server
: 도메인 이름을 IP주소로 변환해주는 서버
3. Subnet Mask
: 이 IP주소가 속한 네트워크 범위를 알려줌 -> 이를 AND 연산하여 인지.
DHCP는 대부분 UDP를 사용한다. 위 그림처럼 헤더를 다 장착하고 밖으로 전송되어 4단계를 거쳐 IP주소를 할당받게 된다.
이를 Wireshark 상에서 캡쳐한 캡쳐본으로 좀 더 살펴보자
UDP가 upper layer 인 것을 확인할 수 있고, 처음에 client가 Transaction ID와 Broadcasting 정보, MAC address(?)를 포함하여 Discover 단계임을 브로드캐스팅하면, 서버에서 ID에 맞추어 IP 주소를 알려주고, 본인의 주소도 제공한다.
그 다음엔 client가 다시 브로드캐스팅하여, 너가 준 IP주소를 사용하겠다 선언하고, 그 브로드캐스트 msg를 본 서버는 ACK를 보내는 방식이다.
<IP 주소를 받아서 쓰는 과정>
만약 우리 학교가 IP주소를 처음 할당받았다고 가정해보자. 저 위의 20bit짜리 블럭을 할당받았다고 했을 때, 이를 부서별로 나누어야 구조적으로 복잡하지 않기 때문에, Subnet을 3bit로 두고 나누어 놓은 사진이다. Organization을 보면 Subnet portion이 20에서 23으로 늘어난 것을 확인할 수 있다.
이렇게 Subnet에 따라 나누어 놓은 Organization 들을 묶어놓고, 라우팅 테이블에 200.23.16.0/20 에서 온 통신들은 다 1로 보내자 라는 정보를 적어놓는다. 그 아래에는 다른 네트워크로 연결된 주소로써 2번으로 연결되게 테이블에 적혀있다. 그런데,,
피치 못할 사정으로 Organization 1이 아래 네트워크로 넘어가게 되었다. 이때의 처리 과정은 위 사진과 같이 옮겨진 IP주소만 따로 테이블에 추가하는 방식으로 수정한다. 사실 200.23.16.0/20 의 범위안에 200.23.18.0/23 이 있는거라서 저렇게 해놔도 1번으로 이동하는 거 아닌가? 라는 의문이 들 수도 있지만, 이전에 배운 prefix 개념을 생각해보면, 후자IP가 전자IP보다 Prefix가 길다. 이는 더 명확하게 쓰인 IP주소임을 뜻하고, 이 때문에 올바르게 네트워킹이 될 수 있음을 알 수 있다.
** Nbit 의 Block을 할당받는 방법 -> ICANN ( http://www.icann.org/ ) 로부터 할당받을 수 있다.
1. allocate address
2. manages DNS
3. assigns domain names, resolves disputes..
<NAT>
NAT : network address translation
다음은 IP 고갈 문제를 해결하기 위해 고안된 방법중 NAT에 대해 알아보자.
일단 NAT에 대해 간단히 설명하자면,,
"사설 IP주소 <-> 공인 IP 주소를 서로 변환해주는 기술" 이다.
예를 들어. 집에서 인터넷을 쓸 때
1. 집에 컴퓨터와 스마트폰, TV 가 있고 이 디바이스 각각은 사설 IP주소를 가진다.
2. 집에 비치된 공유기(라우터) 가 NAT 기능을 수행한다. 공인 IP : 138.76.29.7 ( 하나만 존재 )
3. 각 기기가 인터넷에 나가면? NAT가 출발지 IP를 모두 138.76.29.7으로 바꿔서 보내준다. 대신 내부에서 어떤 디바이스가 보낸건지 기억해야 하므로, 포트 번호도 같이 붙여서 변환한다.
결국 NAT의 목적은,,
한개의 IP address(공인IP)로 집안의 여러 Device를 사용할 수 있도록 하기 위함이다.
외부에서 보았을 때는, 그냥 하나의 IP를 가진 컴퓨터에 Port가 여러개네? 라고 생각한다. 하지만 내부적으로는 공유기가 여러 디바이스의 사설 IP를 하나의 공인 IP로 통합하면서 그렇게 보이도록 속이는 것이라고 할 수 있다.
결국 키워드만 따놓고 보면 replace, remember, 그리고 다시 replace이다.
사설 IP가 인터넷으로 나갈 때는 NAT 을 통해 하나의 사설 IP로 replace되어 나가고, 어느 디바이스에서 보낸 통신인지 remember 위해 port 번호를 붙인다. 인터넷으로 부터 대답을 받을때는 다시 사설IP로 replace해서, port 번호로 어느 디바이스에서 온 통신인지 구분하고 그 디바이스에 다시 대답을 준다.
그림으로 또 한번 이해해보자.
1,2,3,4 번 단계를 하나하나 차근차근 따라가보자. 먼저 host 중 10.0.0.1 이라는 사설 IP를 가진 디바이스에서 인터넷에 접속하고자 한다. 이가 라우터를 통해 나갈 때, NAT 에 의해 5001 이라는 포트번호를 받아 공인IP주소로 변경되어 나간다. 그 후 인터넷에서 응답을 받을 때는 다시 포트번호 5001이 포함된 주소로 Dest 가 설정되고, 라우터는 그 통신을 받아 5001 을 할당받은 디바이스로 응답을 재전송한다.
자 여기서 hole punching 이라는 개념이 나오는데,,
port number 을 지정하여 그 포트를 뚫어놓는 것이 hole punching 이다. 그런데, 이렇게 Port가 뚫린 후, 다시 지워지는 것은 언제일까? TCP 같은 경우 통신의 끝맺음 시그널인 FIN이 오면 바로 hole을 닫고, UDP는 언제 끝날지 모르는 상황이므로 timer를 설정하여 그 시간이 지나면 닫는 방식으로 port를 닫는다.
이렇게 NAT 방식은 60,000개의 동시 연결이 가능한 획기적인 방법이다.
하지만 이런 NAT 방식에는 논란의 여지가 존재한다.
지금까지 각 layer 들의 특징을 배우면서, 각각의 계층이 가진 역할이 있는데, 지금 이 NAT 방식은 Network Layer에서 사용되는 방식임에도 불구하고 port 번호를 지정하여 통신하는 방식을 택하고 있는데, port번호는 Transport 계층의 범위를 침범했다는 의미에서 논란이 있고, 이를 IPv6로 주소 지정 범위를 늘리는 식으로 해결해야한다는 의견이 많지만, 사실 교수님 피셜 이 NAT 방식은 일반인들이 사용하기에 너무나도 편리한 방식이라 아마 대체되진 않을 것이라고 하셨다.
<NAT traversal>
NAT traversal : 클라이언트가 연결을 원하면, 그 지정 Port를 미리 열어두어야 한다. 그 예로써 Port Forwarding 이라는 것이 존재한다.
이는 앞서 보았던 NAT translation table 과 달리 한 번 연결된 port 정보가 지워지지 않는다. 지우려면 사용자가 직접 지워야 한다.
그래서 이렇게 뚫어놓은 Port를 통해 상시 통신이 가능하다. 이를 Port Forwarding 이라고 한다.
위 그림처럼 포트를 정해놓아 Port forwarding 이 가능하고, 아래는 DMZ 방식으로, 전에 설명했던 것 처럼 여러개의 Device를 나누어 놓는게 아니라, 그냥 나 혼자 쓴다 마인드로 설정하는 방식인데, 이는 해킹이 쉬워서 특정상황이 아니라면 사용하지 않는다.
다음은 IPv6와 ICMP 에 대해 포스팅하겠습니다!!!!! 기말 화이팅~
'CS > 네트워크' 카테고리의 다른 글
| [Network] IPv6 & ICMP (0) | 2025.05.28 |
|---|---|
| [네트워크] Network Layer - (2) IP가 뭔데요 (2) | 2025.05.26 |
| [네트워크] Network Layer - (1) 라우터 구조가 뭔데요 (0) | 2025.05.22 |
| [네트워크] Network Layer - (1) VC가 뭔데요 (0) | 2025.05.22 |