NAT와 DHCP

지금까지 IP 주소와 서브넷을 배우면서, 공인 IP와 사설 IP가 구분된다는 것을 알았습니다.

그런데 한 가지 의문이 남습니다.

사설 IP는 인터넷에서 라우팅되지 않는다고 했는데, 그렇다면 192.168.x.x 주소를 가진 내 노트북은 어떻게 구글에 접속하는 걸까요?

이 질문에 대한 답이 NAT(Network Address Translation)입니다.

NAT는 주소를 단순히 바꾸는 기능이지만, 가정과 기업에서 흔히 말하는 NAT는 대부분 PAT/NAPT입니다.

내부의 여러 장치가 하나의 공인 IP를 함께 쓰기 위해 IP 주소뿐 아니라 TCP/UDP 포트까지 함께 변환합니다.

NAT의 동작 원리

다음은 PAT 매핑 한 건을 추적한 예시입니다. 실제 포트는 장비가 선택하며 충돌이 없으면 원래 포트를 유지할 수도 있습니다.

같은 내부 포트를 쓰는 두 연결: 다음은 TCP로 같은 예시 외부 서버 198.51.100.10:443에 연결하고, 표의 매핑이 유효하며 응답 정책도 허용된 조건입니다. 장비가 아래 외부 포트를 선택했다고 가정합니다.

내부 포트 51514가 같아도 내부 IP가 다르므로 두 연결은 서로 다릅니다. 이 표에서 외부 서버의 응답 목적지가 203.0.113.7:40002라면 유효한 매핑을 조회하여 192.168.1.11:51514로 복원합니다. 요청에서는 출발지, 돌아오는 응답에서는 목적지 필드가 바뀌므로 방향을 먼저 확인해야 합니다. RFC 3022 §2.2의 NAPT 설명도 이 주소·전송 식별자 매핑과 복원을 다룹니다.

독립 판단: 위 표의 두 번째 매핑 상태만 소실되었습니다. 이어 203.0.113.7:40002를 목적지로 하는 기존 연결의 응답이 도착했습니다. 첫 번째 행이나 내부 포트 51514만 보고 어느 내부 장치로 보내도 될까요?

NAT의 종류

PAT(NAPT라고도 함)가 실무에서 가장 많이 사용됩니다.

하나의 공인 IP에서 포트·프로토콜·외부 목적지 등의 튜플로 연결을 구분합니다. 동시 연결 한계는 장비와 설정에 따라 달라집니다.

가정의 공유기가 수행하는 NAT가 바로 PAT입니다.

PAT 장비는 내부 IP:포트 ↔ 공인 IP:포트 ↔ 외부 목적지 관계를 NAT 테이블에 저장합니다.

응답 패킷이 돌아오면 이 테이블을 보고 원래 내부 장치로 되돌려 보냅니다.

이런 동적 PAT는 매핑 상태를 유지합니다. NAT 자체가 트래픽 허용 정책을 대신하지는 않습니다.

포트 포워딩 (DNAT)

포트 포워딩은 외부에서 먼저 들어오는 연결을 허용하기 위한 정적 DNAT 규칙입니다.

예를 들어 203.0.113.7:443으로 들어온 연결을 내부 서버 192.168.1.50:8443으로 넘기도록 미리 매핑합니다.

단, 실제 장비에서는 방화벽 규칙도 함께 열려 있어야 합니다.

여기서 사용하는 203.0.113.x, 198.51.100.x 같은 주소는 실제 서비스 주소가 아니라 문서 예시용 대역입니다.

실제 설정에서는 ISP나 클라우드가 할당한 공인 IP를 사용합니다.

다음은 80번 포트를 사용하는 별도 규칙 예시입니다. 이 규칙만으로 구성이 끝나지는 않으며 IP 포워딩, 방화벽 허용 정책과 응답 경로도 맞아야 합니다.

# Linux에서 NAT 설정 (iptables)

# SNAT: 내부 → 외부 (마스커레이드)
sudo iptables -t nat -A POSTROUTING \
  -s 192.168.1.0/24 -o eth0 -j MASQUERADE

# DNAT: 외부 80 → 내부 웹서버
sudo iptables -t nat -A PREROUTING \
  -i eth0 -p tcp --dport 80 \
  -j DNAT --to-destination 192.168.1.50:80

# NAT 테이블 확인
sudo iptables -t nat -L -n -v

# 현재 NAT 세션 확인
sudo conntrack -L | head -20

NAT의 한계

이런 한계를 우회하기 위해 STUN/TURN 서버(WebRTC), UPnP(자동 포트 포워딩), NAT-T(IPsec VPN) 등의 기술이 사용됩니다.

CGNAT 환경에서는 100.64.0.0/10 공유 주소 대역이 고객 장비와 ISP NAT 사이에서 사용될 수 있습니다.

이 경우 공유기에서 포트 포워딩을 설정해도 ISP NAT를 통과하지 못해 외부 접속이 막힐 수 있습니다.

DHCP 동작 흐름

컴퓨터를 네트워크에 연결하면 자동으로 IP 주소가 할당되는 것이 당연하게 느껴지지만, 사실 이 뒤에는 DHCP(Dynamic Host Configuration Protocol)라는 프로토콜이 동작하고 있습니다.

최초 임대의 성공 흐름을 DORA라고 부릅니다. 아래는 같은 LAN에서 서버 하나가 응답한 예시이며 relay와 갱신은 생략했습니다. Discover와 서버 선택을 알리는 Request는 브로드캐스트로 보내고, Offer·ACK는 상태와 플래그에 따라 브로드캐스트 또는 유니캐스트로 전달됩니다.

제안과 사용 확정을 나누기: 최초 연결한 클라이언트가 Offer에서 192.168.1.100과 마스크를 받았다고 합시다. 아직 유효한 이전 임대는 없습니다. 이 주소는 서버의 제안이며, 클라이언트는 선택한 서버·주소를 Request로 알리고 ACK의 조건을 확인해 임대를 설정합니다. 주소 충돌 확인 등 실제 구성 절차도 필요합니다. RFC 2131 §4.4.1의 최초 임대 절차를 기준으로 읽습니다.

독립 판단: Discover→Offer→Request까지만 관측했고 ACK나 임대 설정 성공 기록은 아직 없습니다. “DHCP 서버가 응답했으니 주소 할당이 끝났고 인터넷 연결도 성공했다”는 결론을 낼 수 있을까요?

DHCP가 할당하는 정보

여기서 다루는 동적 DHCP 할당은 시간 제한이 있는 lease입니다.

클라이언트는 lease가 끝나기 전에 갱신을 시도하고, 다른 네트워크에 DHCP 서버가 있을 때는 라우터가 DHCP relay로 메시지를 중계할 수 있습니다.

# 현재 DHCP 임대 정보 확인 (Linux)
cat /var/lib/dhcp/dhclient.leases

# DHCP 임대 갱신
sudo dhclient -r eth0     # 임대 해제
sudo dhclient eth0        # 새로 요청

# Windows
ipconfig /release
ipconfig /renew
ipconfig /all             # DHCP 서버 주소 확인

# DHCP 서버가 할당한 정보 확인
nmcli connection show "이더넷" | grep -i dhcp

공유기의 복합 기능

개발자가 로컬에서 서버를 실행하고 외부에서 접속하려 할 때, 포트 포워딩 설정이 필요한 이유가 바로 NAT 때문입니다.

요즘은 ngrok이나 Cloudflare Tunnel을 사용하면 포트 포워딩 없이도 외부에서 로컬 서버에 접근할 수 있습니다.

다음 절에서는 IPv4의 주소 고갈 문제와 그 근본적 해결책인 IPv6를 살펴보겠습니다.