NAT와 DHCP

앞의 글들에서 사설 주소는 인터넷으로 내보내지 않는다고 했습니다. 그렇다면 192.168.0.x 주소를 받은 노트북은 어떻게 인터넷의 서버와 통신할까요? 답은 공유기가 하는 NAT(network address translation)입니다. 또 노트북이 그 주소를 어떻게 받았는지도 궁금한데, 그것은 DHCP의 일입니다. 이 글에서는 이 두 가지를 차례로 살펴봅니다.

NAT와 PAT

NAT는 패킷이 지나갈 때 IP 주소를 바꾸어 주는 기능입니다. 집이나 회사에서 흔히 NAT라고 부르는 것은 대개 PAT(port address translation) 또는 NAPT라고도 하는 방식으로, IP 주소뿐 아니라 TCP와 UDP의 포트 번호까지 함께 바꾸어 내부의 여러 장치가 공인 주소 하나를 나누어 쓰게 합니다.

그림처럼 내부 장치가 바깥으로 연결을 시작하면, 공유기는 패킷의 출발지 주소와 포트를 자기의 공인 주소와 비어 있는 포트로 바꾸어 내보내고, 그 짝을 변환 표에 적어 둡니다. 바깥 서버의 응답은 공인 주소의 그 포트로 돌아오므로, 공유기는 표를 찾아 목적지를 원래 내부 장치의 주소와 포트로 되돌려 보냅니다. 나가는 패킷에서는 출발지가, 돌아오는 패킷에서는 목적지가 바뀐다는 점이 중요합니다. 다음 코드는 이 변환 표를 흉내 냅니다.

class PAT:
    def __init__(self, public_ip, first_port=40001):
        self.public_ip, self.next_port = public_ip, first_port
        self.out, self.back = {}, {}                    # 나가는 방향과 돌아오는 방향의 표

    def outbound(self, src, dst):
        key = (src, dst)
        if key not in self.out:                         # 처음 보는 연결이면 공인 포트를 하나 배정한다
            mapped = (self.public_ip, self.next_port)
            self.next_port += 1
            self.out[key], self.back[(mapped, dst)] = mapped, src
        return self.out[key]

    def inbound(self, dst_mapped, src):
        return self.back.get((dst_mapped, src), "표에 없음: 버림")

nat = PAT("203.0.113.7")
server = ("198.51.100.10", 443)
a = nat.outbound(("192.168.1.10", 51514), server)
b = nat.outbound(("192.168.1.11", 51514), server)
print("A의 연결:", a)
print("B의 연결:", b)
print("40002로 온 응답:", nat.inbound(("203.0.113.7", 40002), server))
print("모르는 곳에서 40002로:", nat.inbound(("203.0.113.7", 40002), ("192.0.2.99", 443)))

A의 연결: ('203.0.113.7', 40001)
B의 연결: ('203.0.113.7', 40002)
40002로 온 응답: ('192.168.1.11', 51514)
모르는 곳에서 40002로: 표에 없음: 버림

두 장치가 우연히 같은 출발지 포트 51514를 썼지만, 공유기가 서로 다른 공인 포트 40001과 40002를 배정했으므로 두 연결은 섞이지 않습니다. 40002로 돌아온 서버의 응답은 표를 찾아 B로 갔고, 표에 없는 상대가 같은 포트로 보낸 패킷은 버려졌습니다. 실제 장비는 포트를 고르는 방법과, 처음 연결한 상대가 아닌 곳에서 온 패킷을 받아 줄지가 저마다 다르며, RFC 4787은 이런 동작을 몇 가지로 나누어 정리합니다. 변환 표는 연결이 끝나거나 한동안 쓰이지 않으면 지워집니다.

NAT의 종류와 포트 포워딩

PAT는 내부에서 먼저 시작한 연결에 대해서만 표가 만들어지므로, 바깥에서 먼저 들어오는 연결은 갈 곳을 모릅니다. 그래서 내부 서버를 바깥에 공개하려면 "공인 주소의 443번 포트로 들어온 연결은 내부의 192.168.1.50:8443으로 보낸다"는 정적인 DNAT 규칙을 미리 만들어 두는데, 이를 포트 포워딩(port forwarding)이라고 합니다. Linux를 라우터로 쓴다면 다음과 같이 설정합니다.

sudo sysctl -w net.ipv4.ip_forward=1                        # 패킷 전달을 켠다
sudo iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE    # 내부에서 나가는 연결의 출발지를 바꾼다
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 \
  -j DNAT --to-destination 192.168.1.50:8443                # 바깥의 443을 내부 서버로 넘긴다
sudo iptables -t nat -L -n -v                                # NAT 규칙 확인
sudo conntrack -L                                            # 지금의 변환 표(연결 추적 항목)

NAT 규칙은 주소를 바꿀 뿐 통과를 허락하지는 않으므로, 방화벽의 FORWARD 규칙도 그 연결을 허락해야 합니다. 요즘 배포판은 같은 일을 nftables로 하기도 합니다.

NAT의 한계

NAT는 주소의 부족을 크게 덜어 주었지만, 인터넷의 장치들이 서로 직접 연결할 수 있다는 원래의 설계를 깨뜨렸습니다. 바깥에서 먼저 연결할 수 없으니 P2P나 화상 통화는 STUN 서버로 자기의 공인 주소와 포트를 알아내 상대와 맞추어 보고, 그래도 안 되면 TURN 서버를 거쳐 중계해야 합니다. 변환 표의 포트와 메모리가 바닥나면 새 연결을 만들 수 없고, 공유기가 다시 시작해 표를 잃으면 진행 중인 연결이 모두 끊깁니다. FTP의 액티브 모드나 SIP처럼 데이터 안에 IP 주소와 포트를 적어 보내는 프로토콜은 NAT가 그 내용까지 고쳐 주어야 동작합니다.

통신사가 가입자 여럿에게 공인 주소 하나를 나누어 쓰게 하는 CGNAT(carrier-grade NAT) 아래에서는 문제가 더 커집니다. 가입자의 공유기가 받은 주소가 4장 1편에서 본 100.64.0.0/10의 공유 주소라면, 공유기 위에 통신사의 NAT가 하나 더 있는 것입니다. 이때는 공유기에 포트 포워딩을 설정해도 통신사의 NAT가 바깥의 연결을 넘겨주지 않으므로 소용이 없고, 통신사에 공인 주소를 요청하거나 IPv6를 쓰거나, 내부에서 바깥으로 먼저 연결을 맺어 두는 Cloudflare Tunnel이나 ngrok 같은 터널을 써야 합니다.

더 깊이: NAT가 지켜야 할 동작을 정한 RFC

RFC 4787(BCP 127)과 RFC 5382(BCP 142)는 각각 UDP와 TCP에 대해, NAT가 어떻게 동작해야 응용 프로그램이 덜 깨지는지를 정한 운영 지침입니다. 두 문서는 매핑(mapping)과 필터링(filtering)을 나누어 봅니다. 매핑은 내부의 주소와 포트에 어떤 공인 포트를 배정하느냐이고, 필터링은 그 공인 포트로 들어온 패킷 가운데 무엇을 받아 주느냐입니다. 매핑은 목적지가 어디든 같은 공인 포트를 다시 쓰는 끝점 독립 매핑(endpoint-independent mapping), 목적지 주소가 같을 때만 다시 쓰는 주소 의존 매핑, 목적지 주소와 포트가 모두 같을 때만 다시 쓰는 주소·포트 의존 매핑으로 나뉩니다.

두 RFC는 NAT가 끝점 독립 매핑을 따라야 한다고 요구합니다. 그래야 STUN 서버에게 물어 알아낸 공인 주소와 포트를 다른 상대에게 알려 주었을 때 그 상대와도 같은 포트로 통신이 이어지기 때문이며, RFC 4787은 이를 지키지 않으면 UDP 중계를 쓸 수밖에 없다고 적습니다. 매핑을 이렇게 정해도 보안이 약해지지는 않습니다. 어떤 패킷을 들여보낼지는 매핑과 따로 필터링이 정하기 때문입니다.

변환 표를 언제 지울지도 정해 두었습니다. UDP의 매핑은 2분보다 빨리 지우면 안 되고 기본값은 5분 이상을 권하며, 맺어진 TCP 연결은 조용하더라도 2시간 4분보다 빨리 지우면 안 됩니다. 이 값은 TCP keep-alive가 켜져 있으면 기본으로 2시간마다 나간다는 점에 맞춘 것입니다. 다만 모든 NAT가 이 권고를 따르는 것은 아니어서, 예를 들어 AWS의 NAT 게이트웨이는 350초 동안 조용한 연결을 끊고, 그 뒤에 연결을 이어 가려는 내부 쪽에 RST를 돌려준다고 문서에 밝혀 두었습니다.

DHCP: 주소를 자동으로 빌려주기

컴퓨터를 네트워크에 연결하면 주소가 저절로 정해지는 것은 DHCP(dynamic host configuration protocol)가 있기 때문입니다. DHCP 서버는 정해 둔 주소 범위에서 주소를 골라 일정한 기간 동안 빌려주는데, 이를 임대(lease)라고 합니다. 처음 주소를 받는 교환은 네 메시지의 첫 글자를 따서 DORA라고 부릅니다.

아직 주소가 없는 클라이언트는 출발지 0.0.0.0의 UDP 68번 포트에서, 목적지 255.255.255.255의 67번 포트로 "주소를 줄 서버가 있느냐"는 Discover를 브로드캐스트로 보냅니다. 서버들은 빌려줄 주소를 담은 Offer로 답하고, 클라이언트는 그 가운데 하나를 골라 "이 서버의 이 주소를 쓰겠다"는 Request를 다시 브로드캐스트로 보냅니다. 브로드캐스트로 보내는 것은 고르지 않은 다른 서버들도 자기 제안이 거절되었음을 알게 하기 위해서입니다. 마지막으로 고른 서버가 ACK로 확정하면, 클라이언트는 그 주소를 인터페이스에 설정합니다. 이 절차는 RFC 2131에 정해져 있습니다.

DHCP 서버가 주는 것은 주소만이 아닙니다.

임대의 갱신

클라이언트는 임대가 끝나기 전에 연장을 요청합니다. RFC 2131의 기본값에 따르면 임대 시간의 절반이 지나면(T1) 주소를 빌려준 서버에 직접 연장을 요청하고, 그 서버가 답하지 않은 채 87.5%가 지나면(T2) 다른 서버라도 답하라고 브로드캐스트로 요청합니다.

LEASE = 86_400                       # 임대 시간 24시간(초)
t1, t2 = LEASE * 0.5, LEASE * 0.875  # RFC 2131의 기본값
for name, sec in (("갱신(T1): 임대해 준 서버에 유니캐스트로 연장 요청", t1),
                  ("재바인딩(T2): 아무 서버에나 브로드캐스트로 연장 요청", t2),
                  ("만료: 주소를 더 쓸 수 없다", LEASE)):
    print(f"{sec / 3600:>4.1f}시간 뒤  {name}")

12.0시간 뒤  갱신(T1): 임대해 준 서버에 유니캐스트로 연장 요청
21.0시간 뒤  재바인딩(T2): 아무 서버에나 브로드캐스트로 연장 요청
24.0시간 뒤  만료: 주소를 더 쓸 수 없다

임대가 끝날 때까지 아무 서버도 답하지 않으면 클라이언트는 그 주소를 더 쓸 수 없고, 처음부터 Discover를 다시 시작합니다. DHCP 서버가 다른 서브넷에 있으면, 브로드캐스트는 라우터를 넘지 못하므로 라우터가 DHCP 릴레이(relay)로 메시지를 서버에 대신 전해 줍니다.

nmcli -f DHCP4 device show eth0    # Linux(NetworkManager): 받은 DHCP 옵션
ipconfig /all                      # Windows: DHCP 서버, 임대를 받은 시각과 끝나는 시각
ipconfig /release                  # Windows: 지금의 임대를 돌려준다
ipconfig /renew                    # Windows: 임대를 새로 요청한다

ipconfig /all에 나오는 임대를 받은 시각과 끝나는 시각의 차이가 임대 시간이며, 앞에서 계산한 것처럼 기본값으로는 그 절반이 지나면 클라이언트가 갱신을 시도합니다. /release는 받은 주소를 서버에 돌려주므로 그 순간 네트워크 연결이 끊깁니다. 원격 데스크톱처럼 네트워크로 접속한 컴퓨터에서 실행하면 /renew를 입력할 연결도 함께 사라지므로 주의해야 합니다.

공유기가 하는 일

집의 공유기는 여러 장비를 하나로 합친 것입니다. 내부와 외부 사이에서 패킷을 넘기는 라우터, 사설 주소와 공인 주소를 바꾸는 NAT, 내부 장치에 주소를 나누어 주는 DHCP 서버, 유선 포트 사이의 스위치, Wi-Fi를 제공하는 무선 AP, 바깥에서 들어오는 원치 않는 연결을 막는 방화벽이 한 상자에 들어 있습니다. 개발 중인 서버를 집에서 띄워 바깥에서 접속하려면 포트 포워딩이 필요한 이유도, 그 상자 안의 NAT 때문입니다.

정리

• NAT는 패킷이 지나갈 때 주소를 바꾸며, 흔히 쓰는 PAT는 주소와 포트를 함께 바꾸어 여러 장치가 공인 주소 하나를 나누어 쓰게 합니다.
• PAT는 내부에서 시작한 연결을 변환 표에 적어 두고, 돌아오는 응답의 목적지를 표에 따라 되돌립니다. 표에 없는 패킷은 갈 곳이 없습니다.
• 바깥에서 먼저 들어오는 연결은 포트 포워딩 같은 정적인 DNAT 규칙과 방화벽의 허락이 있어야 내부로 들어옵니다.
• CGNAT 아래에서는 공유기의 포트 포워딩만으로는 바깥에서 접속할 수 없어, 공인 주소나 IPv6, 터널이 필요합니다.
• DHCP는 Discover, Offer, Request, ACK의 교환으로 주소와 게이트웨이, DNS를 빌려주며, 클라이언트는 임대의 절반과 87.5%에서 연장을 요청합니다.

연습 문제

1. 변환 표의 한 줄이 사라지면

본문의 표에서 B의 연결에 해당하는 줄만 사라졌습니다. 그 뒤 서버가 보낸 응답이 공인 주소의 40002번 포트로 도착했습니다. A의 줄이나 내부 포트 51514만 보고 응답을 어느 장치로 보낼지 정할 수 있나요?

2. Request까지만 보였다

패킷 캡처에서 Discover, Offer, Request까지는 보이지만 ACK는 보이지 않습니다. "DHCP 서버가 응답했으니 주소를 받았고 인터넷도 될 것"이라고 말할 수 있나요?

3. 포트 포워딩을 했는데 접속이 안 된다

집에서 띄운 웹 서버를 바깥에 공개하려고 공유기에 80번 포트의 포트 포워딩을 설정했지만, 바깥에서 접속하면 연결되지 않습니다. 공유기의 WAN 주소를 보니 100.72.15.4입니다. 무엇이 문제이고, 어떻게 해결할 수 있나요?

다음 글 IPv6에서는 IPv4 주소의 고갈을 근본적으로 해결하려고 만든 IPv6의 주소 체계와, 주소를 스스로 정하는 방법을 살펴봅니다.