NAT의 단점
NAT 방식은 다음과 같은 문제점을 갖고 있다.
- 라우터는 네트워크 계층까지만을 담당하기 때문에 오로지 IP 패킷만 다룰 수 있다. 하지만 NAT에서 라우터는 전송 계층의 포트 번호를 변경하기 때문에 상위 계층을 침범한다.
- NAT는 네트워크 노드는 패킷을 수정할 수 없다는 end-to-end 규칙을 위반한다.
- 로컬 환경에서 서버 운영이 어렵다. 로컬 환경에서 서버를 만들어도 그 서버의 IP와 포트 번호는 외부 환경에서의 것이 아니라 로컬 내부에서만 사용할 수 있다. 따라서 외부 환경에 있는 클라이언트가 접속할 수 없다.
- NAT는 로컬에서 외부로 나갈 때 라우터에 NAT 테이블을 만들어서 정보를 저장해놓고, 다시 외부에서 내부로 돌아올 때 이 NAT 테이블을 참조해서 알맞은 위치로 보내준다. 하지만 로컬 환경이 서버일 경우, 외부에서 생판 처음 보는 데이터가 들어올텐데 이에 해당하는 NAT 테이블이 없으므로 로컬 환경 안에 어디로 보내야할지 알 수 없다.
- 대부분의 로컬 환경 사용자들은 클라이언트이기 때문에 큰 문제가 되지 않는 것 뿐이다.
이러한 문제점으로 인해 IPv6로 바꿔버리는 것이 훨씬 깔끔한 방법이지만, 비용과 정치 싸움으로 인해 쉽지 않은 상황이다.
Dynamic Host Configuration Protocol (DHCP)
Dynamic Host Configuration Protocol
동적 호스트 설정 프로토콜
DHCP는 IP를 필요로 하는 컴퓨터에게 자동으로 할당해서 사용할 수 있도록 해주고, 사용하지 않으면 반환받아 다른 컴퓨터가 사용할 수 있도록 해주는 방식이다.
호스트가 네트워크에 접속할 때 마다 동적으로 IP 주소를 할당해 주기 때문에 Plug and Play 방식이라고도 한다.
명령창에 ipconfig를 입력하면 현재 IP 주소 및 여러 정보를 알 수 있다.
IP : 192.168.1.47
Subnet Mask : 255.255.255.0
Route : 192.168.1.1
DNS : 192.168.1.1이때 새로운 네트워크에 연결할 때 마다 새로운 IP 주소를 담당해서 배정해주는 프로토콜이 바로 DHCP이다.
다만 항상 DHCP의 동적 IP 할당이 필요한 것은 아니다. 학교 네트워크같은 경우는 DHCP가 아닌 고정된 IP 주소가 필요하다. 이처럼 고정된 IP 주소를 사용하는 경우는 DHCP가 필요 없다.
DHCP는 IP 주소를 일정 시간동안 대여해주고 이후 회수하는 방식으로 동작한다. 따라서 비교적 적은 수의 IP 주소를 갖고 돌려 쓸 수 있다. 이로 인해 고정 IP 방식에 비해 Address Pool을 더 유연하게 사용할 수 있다.
예를 들어 10,000명의 네트워크 사용자가 있으면, 고정 IP 방식에서는 10,000개의 IP 주소가 필요하지만 DHCP에서는 1,000개 정도의 IP만 갖고 그때그때 사용하는 사람에게 임대해주는 방식으로 동작이 가능하다.
DHCP client-server scenario
처음에 PC를 부팅하고 네트워크에 연결했을 때에는 IP 주소는 물론 DHCP 서버도 모른다.
다음과 같은 과정을 거쳐 IP 주소를 할당받는다.
1. DHCP discover
src: 0.0.0.0, 68: 아직 IP 주소를 할당받지 못했으며, DHCP 클라이언트로써 68번 포트에서 활동하고 있음을 의미.dest: 255.255.255.255, 67: 목적지는 255.255.255.255 즉, 브로드캐스트.- 브로드캐스트란 동일 서브넷에 있는 모든 멤버들에게 이 메시지를 전송한다는 의미.
- DHCP 프로토콜의 포트 번호는 67번을 사용. 따라서 DHCP와 관련 없는 다른 호스트들은 67번 포트를 닫아놓았기에 이 메시지를 무시하고, DHCP 서버만 67번 포트를 열어놔서 이 메시지를 수신.
transaction ID: 654: 클라이언트가 랜덤으로 선택한 ID.
2. DHCP offer
- 67번 포트를 열어놓은 DHCP 서버에서 discover 메시지를 받은 후 그 응답으로 offer를 전송.
src: 223.1.2.5, 67: 서버 자신의 IP 주소와 포트 번호.dest: 255.255.255.255, 68: 브로드캐스트.- 서버는 아직 클라이언트가 누군지 모른다. 왜냐하면 그저 브로드캐스트로 어디에선가부터 날아들어온 메시지를 받았을 뿐이다.
- 따라서 브로드캐스트로 offer를 전송하되, 포트를 68번으로 설정하여 DHCP 클라이언트만이 이 메시지를 수신할 수 있도록 설정한다.
yiaddr: 223.1.2.4 / lifetime: 3600 secs: 223.1.2.4 라는 IP 주소를 3600초동안 사용할 수 있도록 대여해준다는 것을 의미.- 이 정보 뿐만 아니라 라우터, DNS, 서브넷마스크의 IP 주소 역시 offer에 포함되어있음.
- DHCP ACK가 온 순간부터 이들을 사용할 수 있음.
- 만약 DHCP가 여러개 있다면 그 여러개의 서버로부터 각각 offer가 온다. 이후 클라이언트는 이 offer 중에서 하나를 선택하여 request를 보내게 된다.
3. DHCP request
- offer를 받은 클라이언트가 이를 수락한다는 의미로 보내는 request 메시지.
src: 0.0.0.0, 68: 아직 IP 주소가 확정되지 않았기 때문에 IP 주소는 무명.dest: 255,255,255,255, 67: 여러개의 DHCP 서버에게 클라이언트가 선택한 DHCP 서버의 존재를 알리기 위해 브로드캐스트로 전송.yiaddr: 223.1.2.4 / lifetime: 3600 secs: offer와 동일.- 서버가 제안한 IP 주소와 lifetime을 클라이언트가 수락한다는 의미.
transaction ID: 655: 클라이언트의 원래 transaction ID + 1.
4. DHCP ACK
- DHCP offer와 똑같은 내용. transaction ID만 +1.
- 서버가 DHCP request를 받고 ACK을 보낸 순간부터 클라이언트는 해당 IP 주소를 사용할 수 있음.
IP fragmentation and reassembly (IP 단편화)
데이터는 전송될 때 다수의 링크를 거쳐가는데, 각 링크마다 보낼 수 있는 데이터의 사이즈가 전부 다르다.
MTU : Maximum Transmission Unit
각 링크가 한번에 보낼 수 있는 데이터의 사이즈
IPv4를 사용하는 링크는 MTU 보다 더 큰 사이즈의 데이터가 들어오면 이를 분리해서 MTU 사이즈에 맞는 독립적인 프레임으로 나누는데, 이를 IP fragmentation (IP 단편화)이라고 한다.
이렇게 쪼개진 데이터들은 목적지에 도착한 후 다시 하나로 합쳐지며, 이를 reassembly (재조립)라고 한다.
위 사진을 보면 처음 들어온 데이터는 4000 바이트지만, MTU는 1500바이트이다.
따라서 4000 바이트를 총 3개의 fragment로 쪼갠다. (1500, 1500, 1040)
맨 마지막에 40바이트가 추가되어 1040이 된 이유는 헤더가 포함되기 때문이다.
- ID : 원래는 하나의 데이터임을 표시하기 위해 동일하게 설정.
- fragflag : 쪼개진 데이터는 1로 설정. 쪼개진 데이터 중에서 가장 마지막 fragment는 0으로 설정.
- 애초에 쪼개지지 않은 데이터 역시 0으로 설정.
- offset : 전체 데이터에서 쪼개진 데이터가 원래 있던 위치 중 첫번째 값 / 8
- 헤더의 데이터 저장 공간을 줄이기 위해 8로 나눈다.
만약 이렇게 쪼갠 fragment 중 하나라도 유실된다면 reassembly는 일어나지 않는다. 따라서 전체 데이터 역시 전부 폐기되고, 다시 처음부터 재전송 해야 한다.
