NAT (Network Address Translation)

Linux 커널의 NAT는 별도 마법이 아니라 nf_nat와 nf_conntrack가 결합된 상태 기반 주소 변환 경로입니다. 이 문서는 SNAT·DNAT·MASQUERADE·REDIRECT, hairpin NAT, helper/ALG, CGNAT, NAT64와 NPTv6의 차이, nftables flowtable 가속, 튜닝 포인트와 실제 장애 분석 절차를 공식 문서와 커널 소스 기준으로 다시 정리합니다.

NAT 개요

NAT는 IPv4 주소 부족 때문에 널리 쓰였지만, 커널 관점에서 더 본질적인 정의는 패킷 헤더의 주소·포트 필드를 한 지점에서 다른 값으로 안정적으로 재기록하고, 응답 경로에서 그 역변환을 보장하는 상태 기계입니다. Linux에서는 이 상태 기계를 nf_conntrack가 유지하고, 실제 필드 수정을 nf_nat가 수행합니다.

중요한 오해 하나를 먼저 지우면 좋습니다. NAT는 흔히 “외부에서 못 들어오게 하니까 보안”으로 설명되지만, 그 효과는 대개 기본 드롭 정책과 상태 기반 필터가 함께 있을 때 생깁니다. NAT만 있다고 해서 보안 정책이 자동으로 완성되지는 않습니다. 반대로 포트 포워딩과 hairpin NAT처럼, NAT는 오히려 외부 노출 경로를 만드는 도구이기도 합니다.

NAT 아키텍처와 커널 경로

NAT의 핵심은 “룰 평가”와 “패킷 재기록”을 분리하는 데 있습니다. 첫 패킷에서 nf_nat_setup_info()가 새 튜플을 고르고 reply 방향 튜플을 바꿉니다. 그 다음 패킷부터는 nf_nat_packet()이 이미 저장된 상태만 보고 헤더를 수정합니다. NAT는 매 패킷마다 규칙 전체를 재평가하는 시스템이 아닙니다.

/* net/netfilter/nf_nat_core.c, 개념 파악용 축약 */
if (nf_ct_is_confirmed(ct))
    return NF_ACCEPT;

nf_ct_invert_tuple(&curr_tuple,
                   &ct->tuplehash[IP_CT_DIR_REPLY].tuple);
get_unique_tuple(&new_tuple, &curr_tuple, range, ct, maniptype);

if (!nf_ct_tuple_equal(&new_tuple, &curr_tuple)) {
    nf_ct_invert_tuple(&reply, &new_tuple);
    nf_conntrack_alter_reply(ct, &reply);
    ct->status |= (maniptype == NF_NAT_MANIP_SRC) ?
                  IPS_SRC_NAT : IPS_DST_NAT;
}

if (ct->status & statusbit)
    verdict = nf_nat_manip_pkt(skb, ct, mtype, dir);

SNAT와 MASQUERADE

SNAT는 출발지 주소와 포트를 바꿔서 내부 호스트 여러 대가 외부와 통신하도록 만드는 가장 흔한 NAT 형태입니다. 리눅스에서 보통 POSTROUTING 훅에 두며, nftables manpage 기준으로 snat는 postrouting과 input nat chain에서 유효합니다. 실무에서는 거의 항상 POSTROUTING을 봅니다.

커널 소스 nf_nat_masquerade.c를 보면 MASQUERADE는 NETDEV_DOWN와 주소 제거 이벤트를 감시해 해당 인터페이스에 묶인 conntrack 엔트리를 정리합니다. 그래서 주소가 바뀌는 uplink에서는 단순 SNAT보다 운용상 안전합니다.

table inet nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;

    # 고정 공인 IP 풀 사용
    oifname "wan0" ip saddr 10.10.0.0/16 \
      snat to 203.0.113.10-203.0.113.13 persistent,fully-random

    # 동적 주소 uplink
    oifname "ppp0" ip saddr 192.168.0.0/24 masquerade
  }
}

persistent는 가능한 한 같은 내부 클라이언트에 같은 외부 매핑을 유지하려는 플래그이고, fully-random은 포트 선택을 완전히 무작위화합니다. nftables manpage에 따르면 커널 5.0 이상에서는 random과 fully-random이 같은 의미입니다.

DNAT, REDIRECT, 그리고 hairpin NAT

DNAT는 목적지 주소와 포트를 바꿔 패킷을 내부 서버나 다른 경로로 보냅니다. 가장 전형적인 예는 포트 포워딩입니다. nftables 기준으로 dnat와 redirect는 prerouting과 output nat chain에서 유효합니다. 로컬 프로세스가 생성한 패킷을 다른 로컬 소켓으로 돌리는 경우에는 OUTPUT REDIRECT가 자연스럽습니다.

table inet nat {
  chain prerouting {
    type nat hook prerouting priority dstnat; policy accept;

    iifname "wan0" tcp dport 443 dnat to 192.168.10.30:8443
    iifname "wan0" tcp dport 22 redirect to :2222
  }

  chain output {
    type nat hook output priority -100; policy accept;

    tcp dport 853 redirect to :10053
  }
}

REDIRECT는 DNAT의 특수형이며 목적지 주소를 현재 로컬 장비로 바꿉니다. 커널 소스 nf_nat_redirect.c는 이 경로가 NF_INET_PRE_ROUTING과 NF_INET_LOCAL_OUT에서만 사용되어야 함을 분명히 드러냅니다.

실무에서 자주 놓치는 부분은 hairpin NAT입니다. 내부 클라이언트가 외부 공개 주소(203.0.113.10:443)로 같은 내부 서버(192.168.10.30:8443)에 접근하면 DNAT만으로는 끝나지 않는 경우가 많습니다. 서버가 클라이언트에게 직접 응답해 버리면 경로가 비대칭이 되고, 클라이언트는 “내가 접속한 외부 주소”가 아니라 “내부 서버 주소”에서 답이 돌아와 세션이 깨질 수 있습니다. 그래서 hairpin에서는 반환 경로를 번역기 자신으로 묶기 위한 추가 SNAT/masquerade가 흔히 필요합니다.

conntrack과 NAT 상태

NAT를 이해할 때 가장 중요한 자료구조는 struct nf_conn입니다. 여기에 원본 방향 tuple, reply 방향 tuple, 상태 비트, 필요시 NAT 확장과 helper 확장이 연결됩니다. NAT가 “연결 기반”처럼 보이는 이유는 실제로 이 상태가 모든 후속 패킷의 판단 기준이 되기 때문입니다.

여기서 흥미로운 점은 RFC 4787이 일반 UDP NAT 매핑 타이머에 대해 “2분 미만으로 끝나면 안 된다”고 요구한다는 점입니다. 반면 현재 Linux nf_conntrack_udp_timeout 기본값은 30초입니다. 이는 리눅스 기본값이 곧바로 CPE/CGN 상호 운용성 요구사항을 만족한다는 뜻이 아님을 보여줍니다. 인터넷 경계 NAT 장비로 쓸 때는 역할에 맞게 타임아웃을 직접 조정해야 합니다. 이 문장은 RFC와 커널 문서를 함께 읽은 해석입니다.

# 현재 사용량과 한계
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max

# 상태 보기
conntrack -L -o extended
conntrack -E

# 특정 흐름만 보기
conntrack -L -p tcp --orig-src 192.168.10.20 --dport 443

NAT helper와 ALG

FTP, SIP, 일부 레거시 제어 프로토콜처럼 “제어 채널 안에 다음 데이터 채널 주소와 포트가 실려 오는” 프로토콜은 NAT에 불리합니다. NAT는 L3/L4 헤더만 바꿔서는 충분하지 않고, 애플리케이션 페이로드를 읽어 RELATED 흐름을 예상해야 합니다. 이 역할이 conntrack helper입니다.

현재 nftables 모델은 iptables 시절의 “자동으로 붙어주는 helper” 관성보다 훨씬 명시적입니다. nftables manpage도 helper는 ct helper set으로 연결에 명시적으로 붙여야 하며, conntrack lookup 뒤에서만 유효하다고 설명합니다. 즉, helper는 가능한 한 좁은 범위에 붙여야 합니다.

table inet helpers {
  ct helper ftp-standard {
    type "ftp" protocol tcp;
  }

  chain prerouting {
    type filter hook prerouting priority filter; policy accept;
    ip daddr 192.168.10.30 tcp dport 21 ct helper set "ftp-standard"
  }

  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    ip daddr 192.168.10.30 ct helper "ftp" tcp dport 1024-65535 accept
  }
}

더 긴 설명은 conntrack 헬퍼 & ALG 문서를 참고하세요. NAT 문서에서는 helper를 “예외적 필요”로 보는 편이 정확합니다. 현대 프로토콜은 가능하면 애플리케이션 계층 NAT 의존을 줄이는 방향으로 설계됩니다.

RFC 동작 모델: mapping, filtering, hairpin

“full cone”, “restricted cone”, “symmetric NAT” 같은 표현은 여전히 현장에서 자주 쓰이지만, RFC 4787 이후 문서는 이를 mapping behavior, filtering behavior, hairpin behavior, timer behavior로 더 정밀하게 분해합니다. Linux NAT를 이 별명 하나로 규정하려고 하면 거의 항상 과도한 단순화가 됩니다.

정리하면, Linux NAT를 “기본적으로 port-restricted cone NAT다” 같은 한 줄로 정의하는 것은 정확하지 않습니다. 외부에서 관찰되는 동작은 NAT 바인딩 정책, 필터 규칙, helper 사용 여부, hairpin 설계, 타이머 설정이 합쳐져 결정됩니다.

CGNAT (Carrier-Grade NAT)

CGNAT는 가정용 공유기의 NAT를 그대로 크게 키운 것이 아니라, 수많은 가입자가 한정된 공인 IPv4 주소 공간을 공유하도록 만드는 통신사업자급 상태 시스템입니다. 그래서 단순한 address rewrite보다 공정성, 로그량, 포트 할당, 메모리 예산, 장애 반경이 핵심 문제가 됩니다.

RFC 6598은 CGN과 CPE 사이에서 사용할 공유 주소 공간으로 100.64.0.0/10을 예약했습니다. 이 공간은 RFC 1918 사설 주소와 비슷하게 외부 라우팅 대상이 아니지만, 목적이 다릅니다. 통신사업자 내부에서 CPE와 CGN 사이 구간을 번호 매기기 위한 별도 공간으로 이해하는 편이 정확합니다.

NAT64와 NPTv6

IPv6 전환 문맥에서 “NAT”라는 단어는 NAT44 하나만 가리키지 않습니다. RFC 6146의 stateful NAT64는 IPv6 클라이언트와 IPv4 서버를 이어 주는 주소·프로토콜 번역기이고, RFC 6296의 NPTv6는 IPv6-to-IPv6 프리픽스 번역기입니다. 둘은 목표도, 상태 모델도, 운용상의 함정도 다릅니다.

RFC 6146는 stateful NAT64가 Endpoint-Independent Mapping을 사용하고 TCP, UDP, ICMP Query마다 별도 BIB와 session table을 가진다고 설명합니다. 또 hairpin을 고려하며, end-to-end IPsec과는 기본적으로 양립하지 않는다고 적시합니다. 즉 NAT64는 단순한 dnat/snat 규칙의 변형이 아니라, 별도의 주소 패밀리 변환 모델입니다.

반면 RFC 6296의 NPTv6는 상태가 없고 checksum-neutral하며, 포트를 건드리지 않습니다. 그래서 NAT44보다 훨씬 단순하지만, 보안 기능을 제공하는 것은 아닙니다. RFC 6296도 NPTv6만으로 방화벽이 되는 것은 아니며, 필요한 경우 별도 필터링이 병행되어야 한다고 읽는 편이 맞습니다.

Stateless NAT와 prefix rewrite

stateful NAT가 conntrack을 기반으로 흐름 상태를 유지하는 반면, stateless NAT는 패킷마다 규칙대로 헤더를 바꾸고 별도 상태를 유지하지 않습니다. nftables NAT 위키가 강조하듯, 이런 방식은 1:1 변환이나 매우 통제된 환경에서는 빠르고 단순할 수 있지만, 일반적인 인터넷 경계 NAT로는 함정이 많습니다.

핵심 제약은 conntrack을 끄고 사용해야 한다는 점입니다. 공식 문서는 notrack를 raw 우선순위 또는 그보다 이른 훅에 배치하지 않으면 conntrack lookup이 먼저 일어나므로 stateless 설계가 성립하지 않는다고 설명합니다.

table inet rawnat {
  chain prerouting {
    type filter hook prerouting priority raw; policy accept;
    tcp dport 443 ip daddr set 192.0.2.10 tcp dport set 8443 notrack
  }
}

nf_flowtable과 NAT fastpath

nf_flowtable은 “conntrack을 버리는 기능”이 아니라, 한 번 conntrack/NAT로 검증된 흐름을 더 짧은 경로로 전달하는 fastpath입니다. 커널 문서가 분명히 적듯 첫 패킷은 기존 IP forwarding path를 통과해야 하고, flowtable 엔트리는 보통 첫 응답 패킷을 본 뒤 만들어집니다. 이후 패킷은 ingress 훅에서 flowtable lookup을 하고, hit이면 neigh_xmit()로 바로 전송할 수 있습니다.

여기서 중요한 사실은 flowtable 엔트리도 NAT 구성을 저장한다는 점입니다. 따라서 flowtable hit 경로에서도 SNAT/DNAT는 계속 적용됩니다. 이것이 “NAT가 있으면 fastpath를 못 탄다”는 단순화가 틀린 이유입니다. 다만 fragment, helper, 복잡한 예외 경로, 미지원 드라이버는 여전히 classic path에 남을 수 있습니다.

table inet fastpath {
  flowtable f {
    hook ingress priority 0;
    devices = { lan0, wan0 };
    flags offload;
  }

  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related flow offload @f accept
    tcp dport { 80, 443 } accept
    udp dport 443 accept
  }
}

성능과 용량 설계

NAT 성능 문제는 대개 “룰이 많아서 느리다”보다 다음 네 축에서 터집니다. 상태 수, 포트 수, 경로 대칭성, 예외 프로토콜입니다. 근거 없는 Mpps 숫자를 외우기보다, 어떤 자원이 먼저 고갈되는지 모델링하는 편이 훨씬 실전적입니다.

운영 튜닝의 기본 원칙은 단순합니다. 세션 수를 예측하고, 세션당 메모리와 타이머를 계산하고, 주소/포트 풀을 그보다 넉넉하게 설계하면 됩니다. 반대로 “일단 nf_conntrack_max만 크게 올리자” 접근은 메모리 압박과 GC 지연을 다른 형태로 되돌려 받을 가능성이 큽니다.

디버깅 절차

NAT 문제를 디버깅할 때는 항상 질문 순서를 고정하는 편이 좋습니다. 1) 룰이 맞는가, 2) 첫 패킷이 어떤 체인에서 어떤 verdict를 받는가, 3) conntrack 엔트리가 어떤 tuple로 확정됐는가, 4) 응답이 같은 번역기를 지나오는가. 이 순서를 지키면 문제 공간이 빠르게 줄어듭니다.

# 1. 현재 룰셋과 체인 우선순위 확인
nft list ruleset

# 2. 실제 첫 패킷 추적
nft monitor trace

# 3. conntrack 상태/이벤트 확인
conntrack -L -o extended
conntrack -E

# 4. 경로 확인
ip route get 198.51.100.10 from 192.168.10.20 iif lan0

# 5. 양쪽 인터페이스에서 동시에 관찰
tcpdump -ni lan0 host 192.168.10.30
tcpdump -ni wan0 host 203.0.113.10

컨테이너와 네임스페이스에서의 NAT

컨테이너 환경의 NAT는 대개 “컨테이너 안”이 아니라 호스트 네임스페이스의 브리지 출구에서 일어납니다. Docker 기본 브리지 모델을 떠올리면 이해가 쉽습니다. 컨테이너는 veth로 브리지에 붙고, 호스트의 POSTROUTING MASQUERADE가 외부 통신을 담당합니다.

table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    ip saddr 172.17.0.0/16 oifname "eth0" masquerade
  }
}

네트워크 네임스페이스를 쓰면 NAT 규칙과 conntrack 상태도 네임스페이스 경계와 함께 관리됩니다. 다만 실제로 어느 네임스페이스의 NAT가 적용되는지는 “패킷이 어느 네임스페이스의 훅을 지나는가”로 결정되므로, 브리지·veth·hostNetwork·CNI 정책을 같이 봐야 합니다. Kubernetes도 CNI에 따라 iptables/nftables NAT, eBPF 기반 SNAT, 또는 NAT 최소화 모델까지 다양합니다.

참고자료

• Linux Kernel Documentation: Netfilter Conntrack Sysfs variables — conntrack/flowtable sysctl 기본값과 의미
• Linux Kernel Documentation: Netfilter's flowtable infrastructure — flowtable 소프트웨어/하드웨어 fastpath
• nftables manpage — snat, dnat, masquerade, redirect, helper, flow offload 문법
• nftables wiki: Performing NAT — 첫 패킷 바인딩, stateful/stateless NAT 설명
• nftables wiki: Conntrack helpers — helper 할당과 보안상 주의점
• net/netfilter/nf_nat_core.c — nf_nat_setup_info(), nf_nat_packet()
• net/netfilter/nf_nat_masquerade.c — MASQUERADE와 netdevice/address notifier 처리
• net/netfilter/nf_nat_redirect.c — REDIRECT 훅 제약
• net/netfilter/nf_flow_table_core.c — flowtable NAT 플래그와 fastpath 코어
• RFC 3022 — Traditional NAT
• RFC 4787 — UDP NAT 동작 요구사항
• RFC 5382 — TCP NAT 동작 요구사항
• RFC 5508 — ICMP NAT 동작 요구사항
• RFC 6888 — CGN 요구사항
• RFC 6598 — CGN Shared Address Space 100.64.0.0/10
• RFC 6146 — Stateful NAT64
• RFC 6296 — IPv6-to-IPv6 Network Prefix Translation (NPTv6)

관련 문서

• Netfilter — 훅 우선순위와 체인 구조
• 라우팅 — DNAT 이후 경로 결정과 비대칭 라우팅 해석
• conntrack 헬퍼 & ALG — helper 내부 동작과 보안상 제약
• Netfilter Flowtable — SW/HW 오프로드 상세
• TPROXY — REDIRECT와 다른 투명 프록시 경로
• 네트워크 네임스페이스 — 컨테이너 NAT와 네임스페이스 경계
• Linux Containers — 브리지와 MASQUERADE 기반 외부 통신