NAT (Network Address Translation)

Linux 커널의 NAT는 별도 마법이 아니라 nf_nat와 nf_conntrack가 결합된 상태 기반 주소 변환(Address Translation) 경로입니다. 이 문서는 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이 같은 의미입니다.

포트 할당 내부 동작: get_unique_tuple()

NAT 바인딩이 만들어질 때 커널이 실제로 하는 일은 충돌하지 않는 유일한 튜플을 찾는 것입니다. 이 과정의 핵심 함수가 get_unique_tuple()이며, nf_nat_core.c에 위치합니다. 이 함수는 사용자가 지정한 범위(주소 풀, 포트 범위) 안에서 기존 conntrack 엔트리와 충돌하지 않는 새 튜플을 선택합니다.

/* net/netfilter/nf_nat_core.c — get_unique_tuple() 개념 축약 */
static void
get_unique_tuple(struct nf_conntrack_tuple *tuple,
                 const struct nf_conntrack_tuple *orig_tuple,
                 const struct nf_nat_range2 *range,
                 struct nf_conn *ct,
                 enum nf_nat_manip_type maniptype)
{
    /* 1단계: 원래 tuple이 범위에 속하면 그대로 사용 시도 */
    if (in_range(orig_tuple, range)) {
        if (!nf_nat_used_tuple(orig_tuple, ct)) {
            *tuple = *orig_tuple;
            return;
        }
    }

    /* 2단계: 범위 내에서 사용되지 않은 조합 탐색 */
    find_best_ips_proto(zone, tuple, range, ct, maniptype);

    /* 3단계: 프로토콜별 포트/ID 선택 */
    if (!(range->flags & NF_NAT_RANGE_PROTO_RANDOM_ALL))
        if (!nf_nat_used_tuple(tuple, ct))
            return;

    /* 4단계: 포트 범위를 순회하며 비충돌 포트 확보 */
    find_proto_unique(tuple, range, ct, maniptype);
}

이 알고리즘의 핵심 포인트는 다음과 같습니다.

nf_nat_used_tuple()은 conntrack 해시 테이블(Hash Table)에서 reply 방향 충돌을 검사합니다. 이 검사가 중요한 이유는 두 개의 서로 다른 내부 연결이 같은 외부 5-tuple을 공유하면 응답 역변환이 모호해지기 때문입니다. 포트 고갈이 발생하는 근본 원인도 여기에 있습니다. 범위 안의 모든 포트가 이미 다른 연결에 사용 중이면 get_unique_tuple()이 실패하고, 해당 패킷은 NAT를 받지 못합니다.

/* net/netfilter/nf_nat_core.c — nf_nat_used_tuple() 개념 */
static bool
nf_nat_used_tuple(const struct nf_conntrack_tuple *tuple,
                   const struct nf_conn *ignored_conntrack)
{
    /* reply 방향의 역튜플을 만들어서 해시 테이블에서 검색 */
    struct nf_conntrack_tuple_hash *found;
    struct nf_conntrack_tuple reply;

    nf_ct_invert_tuple(&reply, tuple);
    found = nf_conntrack_find_get(net, zone, &reply);

    if (found) {
        /* 이미 다른 연결이 이 튜플을 쓰고 있음 → 충돌 */
        if (nf_ct_tuplehash_to_ctrack(found) != ignored_conntrack)
            return true;
    }
    return false;
}

DNAT, REDIRECT, 그리고 hairpin NAT

DNAT는 목적지 주소와 포트를 바꿔 패킷을 내부 서버나 다른 경로로 보냅니다. 가장 전형적인 예는 포트 포워딩입니다. nftables 기준으로 dnat와 redirect는 prerouting과 output nat chain에서 유효합니다. 로컬 프로세스(Process)가 생성한 패킷을 다른 로컬 소켓(Socket)으로 돌리는 경우에는 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 헤더만 바꿔서는 충분하지 않고, 애플리케이션 페이로드(Payload)를 읽어 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 Space)을 공유하도록 만드는 통신사업자급 상태 시스템입니다. 그래서 단순한 address rewrite보다 공정성(Fairness), 로그량, 포트 할당, 메모리 예산, 장애 반경이 핵심 문제가 됩니다.

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 우선순위(Priority) 또는 그보다 이른 훅에 배치하지 않으면 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 지연(Latency)을 다른 형태로 되돌려 받을 가능성이 큽니다.

디버깅(Debugging) 절차

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

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

컨테이너 환경의 NAT는 대개 “컨테이너 안”이 아니라 호스트 네임스페이스의 브리지(Bridge) 출구에서 일어납니다. 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 최소화 모델까지 다양합니다.

NAT와 터널의 상호작용

NAT가 터널(GRE, VXLAN, IPsec, WireGuard 등)과 만나면 어떤 헤더를 기준으로 NAT가 동작하는가가 핵심 문제가 됩니다. 터널 캡슐화(Encapsulation) 전에 NAT가 적용되는지, 캡슐화 후 외부 헤더에 NAT가 적용되는지에 따라 완전히 다른 경로가 만들어집니다.

특히 GRE는 L4 포트가 없기 때문에 NAT에 본질적으로 불리합니다. 커널의 nf_conntrack_proto_gre는 GRE key와 call-id를 사용해 흐름을 구분하지만, 하나의 NAT 뒤에 여러 GRE 터널이 존재하면 충돌이 발생할 수 있습니다.

/* net/netfilter/nf_conntrack_proto_gre.c — GRE conntrack 튜플 추출 */
static bool gre_pkt_to_tuple(
    const struct sk_buff *skb,
    unsigned int dataoff,
    struct net *net,
    struct nf_conntrack_tuple *tuple)
{
    const struct pptp_gre_header *grehdr;

    /* GRE key 또는 call ID를 L4 포트 대신 사용 */
    tuple->src.u.gre.key = grehdr->call_id;
    tuple->dst.u.gre.key = grehdr->call_id;

    return true;
}

# 터널 환경에서 MSS 클램핑 예시
table inet mangle {
  chain forward {
    type filter hook forward priority mangle; policy accept;
    oifname "gre1" tcp flags syn tcp option maxseg size set rt mtu
    oifname "wg0" tcp flags syn tcp option maxseg size set rt mtu
  }
}

eBPF 기반 NAT

전통적인 Netfilter NAT는 conntrack 상태와 nf_nat 경로에 의존하지만, 최근에는 eBPF를 사용하여 NAT를 구현하는 접근법이 등장했습니다. 대표적으로 Cilium은 conntrack과 NAT 테이블을 BPF 맵으로 구현하고, TC 또는 XDP 훅에서 패킷 헤더를 직접 수정합니다.

eBPF NAT의 핵심 아이디어는 BPF 맵을 conntrack 테이블 대용으로 사용하고, TC/XDP 프로그램에서 직접 L3/L4 헤더를 재기록하는 것입니다. 기본적인 SNAT를 BPF로 구현하면 다음과 같은 형태가 됩니다.

/* eBPF TC 프로그램에서의 SNAT 개념 예시 */
struct nat_entry {
    __be32 orig_src;
    __be16 orig_sport;
    __be32 nat_src;
    __be16 nat_sport;
};

struct {
    __uint(type, BPF_MAP_TYPE_LRU_HASH);
    __uint(max_entries, 65536);
    __type(key, struct flow_key);
    __type(value, struct nat_entry);
} nat_table SEC(".maps");

SEC("tc")
int snat_egress(struct __sk_buff *skb)
{
    struct nat_entry *entry;
    struct flow_key key = {};

    /* 5-tuple 추출하여 key 구성 */
    extract_flow_key(skb, &key);

    entry = bpf_map_lookup_elem(&nat_table, &key);
    if (!entry) {
        /* 새 흐름: NAT 매핑 생성 */
        struct nat_entry new_entry = {};
        allocate_nat_binding(&new_entry, &key);
        bpf_map_update_elem(&nat_table, &key, &new_entry, BPF_NOEXIST);
        entry = &new_entry;
    }

    /* IP 헤더의 source address 변경 + 체크섬 보정 */
    bpf_l3_csum_replace(skb, IP_CSUM_OFF, entry->orig_src, entry->nat_src, 4);
    bpf_skb_store_bytes(skb, IP_SRC_OFF, &entry->nat_src, 4, 0);

    /* L4 source port 변경 + 체크섬 보정 */
    bpf_l4_csum_replace(skb, L4_CSUM_OFF, entry->orig_sport, entry->nat_sport, 2);
    bpf_skb_store_bytes(skb, L4_SPORT_OFF, &entry->nat_sport, 2, 0);

    return TC_ACT_OK;
}

NAT 바인딩 생명 주기

NAT 바인딩은 생성부터 소멸까지 명확한 생명 주기를 가집니다. 이 주기를 이해하면 "규칙을 고쳤는데 왜 안 바뀌지", "타임아웃 전에 왜 끊기지", "왜 새 연결이 실패하지" 같은 실무 질문에 체계적으로 답할 수 있습니다.

특히 confirm 전에 드롭되는 패킷은 conntrack 엔트리와 NAT 바인딩이 모두 사라집니다. 이것은 실제로 방화벽 정책이 FORWARD에서 패킷을 거부했을 때 의도적으로 발생하는 것이며, 바인딩이 누적되는 것을 막아 줍니다.

/* net/netfilter/nf_conntrack_core.c — confirm 전후의 차이 */

/* confirm 전: unconfirmed list에만 존재, 해시 미등록 */
static int __nf_conntrack_confirm(struct sk_buff *skb)
{
    struct nf_conn *ct = nf_ct_get(skb, &ctinfo);

    /* reply 방향 충돌이 있으면 confirm 실패 */
    if (nf_ct_is_dying(ct) || __nf_conntrack_confirm_conflict(ct))
        return NF_DROP;

    /* 해시 테이블에 양 방향 삽입 */
    __nf_conntrack_hash_insert(ct, hash, reply_hash);
    ct->status |= IPS_CONFIRMED;

    return NF_ACCEPT;
}

NAT 로깅과 감사

법적 요구사항이 있는 환경(통신사업자, 공공기관)에서는 NAT 바인딩을 기록해야 할 수 있습니다. "누가 언제 어떤 외부 주소/포트를 사용했는가"를 사후에 추적하려면 최소한 타임스탬프, 내부 주소/포트, 외부 주소/포트, 프로토콜을 기록해야 합니다.

# nftables 로그 기반 NAT 감사
table inet nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "wan0" ip saddr 10.0.0.0/8 log prefix "NAT-SNAT " group 1 \
      snat to 203.0.113.10-203.0.113.13
  }
}

# conntrack 이벤트 기반 로깅 (더 정확함)
conntrack -E -e NEW -o timestamp,id

# nfnetlink_log 그룹 수신
ulogd -c /etc/ulogd.conf

IPv6 환경에서의 NAT 필요성 재평가

IPv6의 설계 철학은 "NAT 없이 end-to-end 연결성을 회복"하는 것입니다. 하지만 실무에서는 IPv6에서도 NAT가 사용되는 경우가 있으며, 각각의 동기와 trade-off를 정확히 이해하는 것이 중요합니다.

CGNAT: 포트 블록 할당과 RFC 6888

앞서 CGNAT의 운영 포인트를 개괄했지만, 실제 대규모 CGN을 설계할 때는 포트 블록 할당(Port Block Allocation, PBA) 전략이 성능, 로그 비용, 공정성 세 축을 동시에 결정합니다. 단순히 "포트를 랜덤으로 뿌리자"가 아니라, 가입자별로 미리 할당된 포트 범위 안에서만 NAT 바인딩을 만드는 방식입니다.

RFC 6888은 CGN에 대해 다음과 같은 핵심 요구사항을 명시합니다. 이들은 단순한 권고가 아니라, 상호 운용성과 법적 추적 가능성을 위한 실질적 기준선입니다.

Deterministic PBA의 핵심은 로깅 없이도 역추적이 가능하다는 점입니다. 외부 IP와 포트만 알면 어느 가입자에게 할당된 블록인지 산술적으로 계산할 수 있습니다. 이는 대규모 환경에서 per-session 로그의 저장 비용과 개인정보 문제를 동시에 해결합니다.

# Deterministic PBA 역추적 알고리즘 예시
def reverse_lookup(ext_ip, ext_port, block_size=256, port_start=1024):
    """외부 IP:포트 → 가입자 ID 역산"""
    block_index = (ext_port - port_start) // block_size
    subscriber_id = ip_to_pool_index(ext_ip) * blocks_per_ip + block_index
    return subscriber_id

# 예: 203.0.113.1:1300 → 블록 1 → 가입자 B
# (1300 - 1024) // 256 = 1 → 블록 #1 → 가입자 B

# Linux에서 CGNAT용 nftables 설정 예시
table ip cgnat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;

    # 가입자별 포트 범위를 nftables map으로 관리
    ip saddr 100.64.0.0/10 oifname "wan0" \
      snat to 203.0.113.1-203.0.113.4 persistent,fully-random

    # 가입자별 동시 연결 제한 (REQ-2)
    ip saddr 100.64.0.0/10 ct count over 1024 drop
  }
}

# conntrack 테이블 CGNAT 규모 조정
sysctl -w net.netfilter.nf_conntrack_max=2097152
sysctl -w net.netfilter.nf_conntrack_buckets=524288

# UDP 타이머: RFC 4787 요구 최소 2분
sysctl -w net.netfilter.nf_conntrack_udp_timeout=120
sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=180

# TCP ESTABLISHED 타이머 축소 (5일은 CGN에 과도)
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=7200

NAT64/NPTv6 구현 상세: TAYGA, Jool, 464XLAT

앞서 NAT64와 NPTv6의 개념적 차이를 설명했지만, 실제 Linux에서 이를 구현하는 도구는 크게 세 가지입니다. TAYGA(사용자 공간(User Space) stateless NAT64), Jool(커널 모듈(Kernel Module) stateful NAT64), 그리고 464XLAT(CLAT + PLAT 조합)입니다. 각각의 아키텍처와 성능 특성이 다르므로 환경에 맞게 선택해야 합니다.

# Jool 커널 모듈 기반 Stateful NAT64 설정 예시
modprobe jool
jool instance add "nat64inst" --iptables --pool6 64:ff9b::/96

# IPv4 풀 설정
jool pool4 add --tcp 203.0.113.10 1024-65535
jool pool4 add --udp 203.0.113.10 1024-65535
jool pool4 add --icmp 203.0.113.10 0-65535

# BIB/Session 테이블 확인
jool bib display --tcp
jool session display --tcp

# DNS64: BIND 9 설정 예시
# named.conf에 추가:
# dns64 64:ff9b::/96 {
#     clients { any; };
#     mapped { !rfc1918; any; };
#     suffix ::;
# };

# TAYGA stateless NAT64 설정
# /etc/tayga.conf
# tun-device nat64
# ipv4-addr 192.168.255.1
# ipv6-addr 2001:db8:1::1
# prefix 64:ff9b::/96
# dynamic-pool 192.168.255.0/24

tayga --mktun
ip link set nat64 up
ip route add 192.168.255.0/24 dev nat64
ip route add 64:ff9b::/96 dev nat64

# NPTv6: nftables로 프리픽스 변환
table ip6 nptv6 {
  chain prerouting {
    type filter hook prerouting priority raw; policy accept;
    ip6 daddr 2001:db8:200::/48 \
      ip6 daddr set fd00:10::/48 notrack
  }
  chain postrouting {
    type filter hook postrouting priority srcnat; policy accept;
    ip6 saddr fd00:10::/48 \
      ip6 saddr set 2001:db8:200::/48 notrack
  }
}

conntrack과의 깊은 연동: nf_nat_hook과 튜플 변환

NAT와 conntrack의 관계는 "conntrack이 상태를 저장하고 NAT가 헤더를 고친다" 수준보다 훨씬 깊습니다. 커널 내부에서 NAT는 conntrack의 튜플 변환 메커니즘을 직접 조작하며, 이 과정을 이해해야 zone 기반 NAT, 다중 NAT 체인, 복잡한 DNAT+SNAT 조합의 동작을 정확하게 예측할 수 있습니다.

/* net/netfilter/nf_nat_core.c — nf_nat_manip_pkt() 개념 축약 */
static unsigned int
nf_nat_manip_pkt(struct sk_buff *skb,
                  struct nf_conn *ct,
                  enum nf_nat_manip_type mtype,
                  enum ip_conntrack_dir dir)
{
    struct nf_conntrack_tuple target;

    /* ORIGINAL 방향이면 NAT된 값 적용, REPLY면 역변환 */
    if (dir == IP_CT_DIR_ORIGINAL)
        target = ct->tuplehash[IP_CT_DIR_REPLY].tuple;
    else
        target = ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple;

    /* L3 헤더 수정: IP 주소 변경 + IP 체크섬 */
    l3proto->manip_pkt(skb, &target, mtype);

    /* L4 헤더 수정: 포트 변경 + TCP/UDP 체크섬 */
    l4proto->manip_pkt(skb, ct, mtype, &target);

    return NF_ACCEPT;
}

# conntrack zone 설정: 멀티테넌트 NAT 환경
table inet zone_nat {
  chain prerouting {
    type filter hook prerouting priority raw; policy accept;
    iifname "tenant-a" ct zone set 1
    iifname "tenant-b" ct zone set 2
  }

  chain nat_prerouting {
    type nat hook prerouting priority dstnat; policy accept;
    # 같은 외부 포트를 서로 다른 내부 서버로 DNAT
    ct zone 1 tcp dport 80 dnat to 10.1.0.10:80
    ct zone 2 tcp dport 80 dnat to 10.2.0.10:80
  }
}

# zone별 conntrack 확인
conntrack -L -z 1
conntrack -L -z 2

Masquerade 내부 구현: 인터페이스 변경 감지

MASQUERADE는 단순히 "SNAT인데 IP를 자동으로 찾아주는 것"이 아닙니다. 커널의 nf_nat_masquerade.c는 인터페이스 다운과 주소 제거 이벤트를 감시하는 notifier를 등록하고, 해당 인터페이스에 묶인 conntrack 엔트리를 자동 정리합니다. 이 메커니즘이 MASQUERADE를 DHCP/PPPoE 환경에서 안전하게 만드는 핵심입니다.

/* net/netfilter/nf_nat_masquerade.c — 핵심 구조 축약 */

/* 1. 인터페이스 다운 이벤트 감시 */
static int masq_device_event(
    struct notifier_block *this,
    unsigned long event,
    void *ptr)
{
    struct net_device *dev = netdev_notifier_info_to_dev(ptr);

    if (event == NETDEV_DOWN) {
        /* 이 인터페이스와 연결된 NAT 매핑 정리 시작 */
        nf_ct_iterate_cleanup_net(net, device_cmp,
                                   (void *)(long)dev->ifindex, 0, 0);
    }
    return NOTIFY_DONE;
}

/* 2. 주소 변경 이벤트 감시 */
static int masq_inet_event(
    struct notifier_block *this,
    unsigned long event,
    void *ptr)
{
    struct in_ifaddr *ifa = ptr;
    struct net_device *dev = ifa->ifa_dev->dev;

    /* 주소가 제거되면 해당 주소로 NAT된 연결 정리 */
    nf_ct_iterate_cleanup_net(net, masq_device_cmp,
                               (void *)(long)dev->ifindex, 0, 0);
    return NOTIFY_DONE;
}

/* 3. conntrack 엔트리 비교: 해당 인터페이스의 NAT인지 확인 */
static int device_cmp(
    struct nf_conn *ct,
    void *ifindex)
{
    const struct nf_conn_nat *nat = nfct_nat(ct);

    if (!nat)
        return 0;
    /* masquerade가 이 인터페이스를 통해 적용됐는지 확인 */
    return nat->masq_index == (int)(long)ifindex;
}

NAT 성능 최적화: conntrack 튜닝과 GRO/GSO

앞서 성능 설계의 개괄을 다뤘지만, 여기서는 구체적인 튜닝 파라미터와 GRO/GSO가 NAT 경로에 미치는 영향을 상세히 살펴봅니다. NAT 성능은 결국 conntrack 해시 효율, 메모리 예산, NIC 오프로드와의 상호작용 세 가지로 분해됩니다.

# conntrack 해시 테이블 상태 확인
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max
sysctl net.netfilter.nf_conntrack_buckets

# 해시 체인 분포 확인 (커널 디버그 정보)
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/net/nf_conntrack | wc -l

# 메모리 사용량 추정
# entries * ~300 bytes = 메모리
# 1,000,000 entries ≈ 300MB
# 2,000,000 entries ≈ 600MB

# 권장 CGN 튜닝 셋
sysctl -w net.netfilter.nf_conntrack_max=2097152
sysctl -w net.netfilter.nf_conntrack_buckets=524288
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=7200
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=60
sysctl -w net.netfilter.nf_conntrack_udp_timeout=120
sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=180

# GC 관련 (커널 5.x+에서는 자동 관리가 대부분)
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_close_wait=60
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_fin_wait=60

GRO/GSO와 NAT의 상호작용은 자주 간과되지만 성능에 큰 영향을 미칩니다. GRO(Generic Receive Offload)는 여러 패킷을 하나의 큰 skb로 합쳐서 상위 스택에 올리고, GSO(Generic Segmentation Offload)는 반대로 전송 시 큰 skb를 분할합니다. 문제는 NAT가 이 합쳐진/분할된 패킷의 어느 시점에서 체크섬(Checksum)을 보정하는가입니다.

Hairpin NAT: 내부 클라이언트에서 공인 IP로의 접근

앞서 hairpin NAT의 개념을 설명했지만, 실제 패킷 경로와 필요한 규칙을 구체적으로 추적하면 이해가 훨씬 깊어집니다. Hairpin NAT의 핵심 문제는 응답의 비대칭 경로입니다. DNAT만 적용하면 서버는 클라이언트에게 직접 응답하고, 클라이언트는 "내가 접속한 공인 IP가 아닌 내부 IP에서 답이 왔다"고 인식해 세션을 거부합니다.

# Hairpin NAT 완전한 nftables 설정
table inet nat {
  chain prerouting {
    type nat hook prerouting priority dstnat; policy accept;
    # 외부 + 내부 모두에서 공인 IP로 접근 시 DNAT
    tcp dport 443 ip daddr 203.0.113.10 dnat to 192.168.10.30:8443
  }

  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    # 외부 나가는 트래픽: 일반 masquerade
    oifname "wan0" masquerade

    # Hairpin: 내부→내부 트래픽에서 소스를 게이트웨이로 변경
    # (서버가 게이트웨이로 응답을 보내도록 강제)
    ip saddr 192.168.10.0/24 ip daddr 192.168.10.30 tcp dport 8443 \
      snat to 192.168.10.1
  }
}

nftables NAT 구문: map, vmap, 체이닝

nftables의 NAT는 단순한 snat to/dnat to를 넘어 map과 vmap을 활용해 동적이고 효율적인 NAT 규칙을 구성할 수 있습니다. 이는 수십~수백 개의 포트 포워딩 규칙이 필요한 환경에서 규칙 수를 극적으로 줄이고 lookup 성능을 개선합니다.

# map 기반 다중 포트 포워딩 (DNAT)
table inet nat {
  map portfwd {
    type inet_service : ipv4_addr . inet_service
    elements = {
      8080 : 10.0.1.10 . 80,
      8443 : 10.0.2.20 . 443,
      2222 : 10.0.3.30 . 22,
      3306 : 10.0.4.40 . 3306,
      5432 : 10.0.5.50 . 5432
    }
  }

  chain prerouting {
    type nat hook prerouting priority dstnat; policy accept;
    iifname "wan0" dnat to tcp dport map @portfwd
  }

  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "wan0" masquerade
  }
}

# 런타임에 포트 포워딩 추가 (재로드 불필요)
nft add element inet nat portfwd { 9090 : 10.0.6.60 . 80 }
nft delete element inet nat portfwd { 3306 : 10.0.4.40 . 3306 }

# vmap 기반 테넌트별 NAT 체이닝
table inet multitenant {
  chain tenant_a_nat {
    snat to 203.0.113.10
  }

  chain tenant_b_nat {
    snat to 203.0.113.20
  }

  map tenant_dispatch {
    type ipv4_addr : verdict
    flags interval
    elements = {
      10.0.1.0/24 : jump tenant_a_nat,
      10.0.2.0/24 : jump tenant_b_nat
    }
  }

  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "wan0" ip saddr vmap @tenant_dispatch
  }
}

# concatenated map: 소스 주소+포트로 복합 매핑
table inet complex_nat {
  map svc_map {
    type ipv4_addr . inet_service : ipv4_addr . inet_service
    elements = {
      192.168.1.0/24 . 80 : 10.0.1.10 . 8080,
      192.168.2.0/24 . 80 : 10.0.2.20 . 8080
    }
  }
}

디버깅 & 트레이싱: ftrace와 nf_nat 추적

앞서 기본 디버깅 절차를 다뤘지만, 복잡한 NAT 문제에서는 nft monitor trace와 conntrack -E 이상의 도구가 필요합니다. 커널의 ftrace 인프라를 활용하면 nf_nat_manip_pkt(), nf_nat_setup_info() 같은 내부 함수의 호출을 직접 추적할 수 있습니다.

# === 1. nft monitor trace: 패킷별 체인 통과 추적 ===
# 추적 대상 패킷 마킹
table inet trace_debug {
  chain prerouting {
    type filter hook prerouting priority raw; policy accept;
    ip saddr 192.168.10.20 tcp dport 443 meta nftrace set 1
  }
}

# 실시간 모니터링
nft monitor trace

# 출력 예시:
# trace id abc123 inet trace_debug prerouting packet:
#   iif "lan0" ether saddr ... ip saddr 192.168.10.20
#   ip daddr 203.0.113.10 tcp dport 443
# trace id abc123 inet nat prerouting rule
#   dnat to 192.168.10.30:8443 (verdict accept)

# === 2. conntrack 이벤트 모니터링 ===
# 새 연결과 소멸 이벤트만 추적
conntrack -E -e NEW,DESTROY -p tcp --orig-dst 203.0.113.10

# 타임스탬프와 ID 포함
conntrack -E -o timestamp,id

# 특정 NAT 바인딩 확인
conntrack -L -p tcp --reply-src 203.0.113.10 -o extended

# === 3. ftrace를 이용한 커널 함수 추적 ===
# nf_nat 관련 함수 추적 설정
cd /sys/kernel/debug/tracing
echo 0 > tracing_on
echo function > current_tracer
echo 'nf_nat_setup_info nf_nat_packet nf_nat_manip_pkt' > set_ftrace_filter
echo 1 > tracing_on

# 추적 결과 확인
cat trace_pipe | head -100

# 특정 프로세스/CPU만 추적
echo 0 > tracing_on
echo function_graph > current_tracer
echo 'nf_nat_*' > set_ftrace_filter
echo 1 > tracing_on

# === 4. perf를 이용한 NAT 경로 프로파일링 ===
# NAT 관련 함수의 CPU 소비 비율
perf top -g --filter 'nf_nat'
perf record -g -p $(pgrep ksoftirqd) -- sleep 10
perf report --sort comm,dso,symbol

# === 5. dropwatch로 패킷 드롭 위치 추적 ===
dropwatch -l kas
# 또는 perf로 kfree_skb 트레이스포인트
perf record -e skb:kfree_skb -a -- sleep 5
perf script

컨테이너/쿠버네티스 NAT: kube-proxy와 CNI

앞서 컨테이너 NAT의 기본을 다뤘지만, Kubernetes 환경에서의 NAT는 훨씬 복잡한 다층 구조를 가집니다. kube-proxy의 iptables 모드, IPVS 모드, 그리고 eBPF 기반 CNI(Cilium)가 각각 다른 방식으로 Service의 ClusterIP를 backend Pod IP로 변환합니다.

# kube-proxy iptables 모드: 실제 생성되는 규칙 확인
iptables -t nat -L KUBE-SERVICES -n --line-numbers
iptables -t nat -L KUBE-SVC-XXXXX -n   # Service별 체인
iptables -t nat -L KUBE-SEP-YYYYY -n   # Endpoint별 체인

# 확률 기반 DNAT 규칙 (3개 backend 예시)
# -A KUBE-SVC-XXXXX -m statistic --mode random --probability 0.33333
#     -j KUBE-SEP-AAA
# -A KUBE-SVC-XXXXX -m statistic --mode random --probability 0.50000
#     -j KUBE-SEP-BBB
# -A KUBE-SVC-XXXXX -j KUBE-SEP-CCC

# KUBE-SEP-AAA 내부:
# -A KUBE-SEP-AAA -p tcp -j DNAT --to-destination 10.244.2.10:8080

# IPVS 모드 확인
ipvsadm -Ln
# TCP  10.96.0.100:80 rr
#   -> 10.244.2.10:8080   Masq    1      0          0
#   -> 10.244.3.11:8080   Masq    1      0          0

# Cilium eBPF 모드: Service 매핑 확인
cilium service list
cilium bpf lb list

# conntrack과 kube-proxy의 상호작용 디버깅
conntrack -L -d 10.96.0.100
# 참고: IPVS 모드에서도 conntrack은 사용됨 (MASQUERADE 등)

NAT와 보안: 오해와 실제

NAT가 "보안을 제공한다"는 관념은 현장에서 가장 흔하고 위험한 오해 중 하나입니다. NAT는 주소 변환 도구이지 접근 제어(Access Control) 도구가 아닙니다. 이 섹션에서는 NAT의 보안 효과와 한계를 정확히 구분합니다.

# NAT가 아닌 방화벽으로 보안을 확보하는 올바른 패턴
table inet firewall {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    ct state invalid drop
    iifname "lo" accept
    # 명시적으로 허용하는 서비스만
    tcp dport { 22, 80, 443 } accept
    icmpv6 type { echo-request, nd-neighbor-solicit, nd-router-advert } accept
  }

  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    ct state invalid drop
    # 내부→외부는 허용
    iifname "lan0" oifname "wan0" accept
    # 포트 포워딩 대상만 허용
    iifname "wan0" oifname "lan0" ip daddr 192.168.10.30 tcp dport 8443 accept
  }
}

# NAT는 주소 변환 역할만
table inet nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    oifname "wan0" masquerade
  }
  chain prerouting {
    type nat hook prerouting priority dstnat; policy accept;
    iifname "wan0" tcp dport 443 dnat to 192.168.10.30:8443
  }
}

NAT 장애 패턴과 해결 체크리스트

실무에서 반복되는 NAT 장애 패턴을 체계화하면 디버깅 시간을 크게 단축할 수 있습니다. 아래는 가장 흔한 10가지 패턴과 각각의 진단 순서입니다.

# 종합 진단 스크립트
#!/bin/bash
echo "=== conntrack 상태 ==="
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max
echo "사용률: $(( $(sysctl -n net.netfilter.nf_conntrack_count) * 100 / \
  $(sysctl -n net.netfilter.nf_conntrack_max) ))%"

echo ""
echo "=== conntrack 통계 (에러 카운터) ==="
conntrack -S

echo ""
echo "=== NAT 관련 conntrack 분포 ==="
echo "SRC_NAT: $(conntrack -L 2>/dev/null | grep -c SRC_NAT)"
echo "DST_NAT: $(conntrack -L 2>/dev/null | grep -c DST_NAT)"
echo "OFFLOAD: $(conntrack -L 2>/dev/null | grep -c OFFLOAD)"

echo ""
echo "=== 외부 IP별 포트 사용량 (상위 5개) ==="
conntrack -L 2>/dev/null | \
  grep -oP 'src=\K[0-9.]+' | sort | uniq -c | sort -rn | head -5

echo ""
echo "=== 최근 드롭된 conntrack 이벤트 ==="
dmesg | grep -i 'nf_conntrack: table full' | tail -5

참고자료

• 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)
• man7: nft(8) — nftables 명령어 매뉴얼로 NAT 규칙 문법을 포함합니다
• man7: iptables-extensions(8) — SNAT, DNAT, MASQUERADE, REDIRECT 타겟 상세 설명입니다
• man7: conntrack(8) — conntrack 테이블 조회 및 관리 도구 매뉴얼입니다
• Linux Kernel Documentation: ip-sysctl — ip_forward, ip_local_port_range 등 NAT 관련 sysctl 설정을 설명합니다
• RFC 2663 — IP Network Address Translator Terminology and Considerations
• RFC 7857 — Updates to Network Address Translation (NAT) Behavioral Requirements
• RFC 7915 — IP/ICMP Translation Algorithm (SIIT, NAT64 변환 알고리즘)

관련 문서

• Netfilter — 훅 우선순위와 체인 구조
• 라우팅 — DNAT 이후 경로 결정과 비대칭 라우팅 해석
• conntrack 헬퍼 & ALG — helper 내부 동작과 보안상 제약
• Netfilter Flowtable — SW/HW 오프로드 상세
• NFQUEUE & DPI — NAT 이전/이후 패킷 검사와 userspace 처리
• TPROXY — REDIRECT와 다른 투명 프록시 경로
• IPVS 로드밸런싱 — DNAT와 유사한 로드밸런서 경로
• 네트워크 네임스페이스 — 컨테이너 NAT와 네임스페이스 경계
• Linux Containers — 브리지와 MASQUERADE 기반 외부 통신
• BPF/eBPF/XDP — eBPF 기반 NAT 대안과 XDP 훅
• IP (IPv4/IPv6) — IPv6 주소 체계와 NAT 필요성 재평가
• IPsec & xfrm — NAT-Traversal과 ESP 캡슐화
• WireGuard — UDP 기반 터널의 NAT 통과
• GRE — L4 포트 없는 터널의 NAT 제약
• TC (Traffic Control) — NAT와 QoS 정책의 상호작용
• sk_buff — 패킷 헤더 수정의 기반 자료구조