NAT64 및 DNS64: IPv6 전용 네트워크를 IPv4에 연결
IPv6 전용 클라이언트가 IPv4 전용 서비스에 액세스할 수 있도록 NAT64 및 DNS64를 배포합니다. 아키텍처, 구성 및 문제 해결을 다룹니다.
IPv6 전용 미래#
듀얼 스택(IPv4 및 IPv6를 동시에 실행)은 표준 마이그레이션 접근 방식입니다. 하지만 두 개의 병렬 네트워크를 영원히 유지하는 것이 목표는 아닙니다. 최종 목표는 필요할 때만 레거시 IPv4에 액세스하는 IPv6 전용 인프라입니다.
이 전환은 이미 모바일 네트워크에서 일어나고 있습니다. 주요 통신사는 스마트폰에서 IPv6 전용 스택을 실행합니다. T-Mobile, AT&T 및 Verizon은 수년 전에 LTE/5G 네트워크에서 IPv4를 제거했습니다. 휴대전화에는 IPv6 주소가 있습니다. IPv4 전용 웹사이트에 액세스하면 NAT64 및 DNS64가 투명하게 변환을 처리합니다.
기업 네트워크도 같은 경로를 따릅니다. IPv6 전용은 복잡성을 줄이고 IPv4 주소 고갈 문제를 제거하며 라우팅을 단순화합니다. 하지만 완전한 IPv4 제거는 아직 현실적이지 않습니다. 너무 많은 서비스가 IPv4 전용으로 남아 있습니다. NAT64 및 DNS64는 이 격차를 메우고 IPv6 전용 네트워크가 IPv4 인터넷에 액세스할 수 있게 합니다.
TL;DR - 빠른 요약
핵심 포인트:
- NAT64는 IPv6 패킷을 IPv4로 변환합니다. DNS64는 A 레코드에서 AAAA 레코드를 합성합니다
- 잘 알려진 접두사 64:ff9b::/96은 IPv6 공간에 IPv4 주소를 포함합니다
- 모바일 네트워크는 이를 광범위하게 사용합니다(T-Mobile, AT&T, Verizon은 IPv6 전용)
- DNS64는 DNSSEC을 중단합니다. 합성 레코드가 서명된 영역과 일치하지 않습니다
바로가기: 아키텍처는 NAT64 및 DNS64가 함께 작동하는 방법, 배포는 구현 옵션, 알려진 문제는 제한 사항을 참조하세요.
NAT64 및 DNS64가 함께 작동하는 방법#
NAT64는 네트워크 계층에서 프로토콜 변환을 수행합니다. DNS64는 이 변환을 트리거하는 IPv6 주소를 합성합니다. 이들은 쌍으로 작동합니다. NAT64가 없는 DNS64는 쓸모없고 DNS64가 없는 NAT64는 수동 구성이 필요합니다.
변환 흐름#
IPv6 전용 클라이언트가 IPv4 전용 서비스에 액세스할 때 일어나는 일:
┌─────────────────────────────────────────────────────────────────┐
│ 1. 클라이언트가 www.ipv4only.example.com에 대한 DNS 쿼리 │
│ 쿼리 유형: AAAA (IPv6 주소) │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ 2. DNS64 서버가 업스트림 DNS에 쿼리 │
│ 수신: A 레코드 → 198.51.100.10 (IPv4만) │
│ AAAA 레코드 없음 │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ 3. DNS64가 AAAA 레코드 합성 │
│ NAT64 접두사 + IPv4 주소 결합 │
│ 결과: 64:ff9b::198.51.100.10 │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ 4. 클라이언트가 합성된 IPv6 주소 수신 │
│ 64:ff9b::198.51.100.10으로 패킷 전송 │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ 5. NAT64 게이트웨이가 패킷 가로채기 │
│ 64:ff9b::/96 접두사 인식 │
│ 임베디드 IPv4 추출: 198.51.100.10 │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ 6. NAT64가 IPv6 → IPv4로 변환 │
│ 패킷 헤더 변경 │
│ 상태 저장 NAT 수행 (세션 추적) │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ 7. 대상으로 IPv4 패킷 전송 │
│ 소스: NAT64 게이트웨이 IPv4 주소 │
│ 대상: 198.51.100.10 │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ 8. 반환 트래픽 재변환 │
│ NAT64가 세션 조회 │
│ IPv4 → IPv6로 변환 │
│ 클라이언트로 전달 │
└─────────────────────────────────────────────────────────────────┘클라이언트는 IPv6만 봅니다. IPv4 전용 서비스는 IPv4만 봅니다. NAT64 및 DNS64는 변환을 투명하게 처리합니다.
잘 알려진 접두사#
표준 NAT64 접두사는 64:ff9b::/96입니다(RFC 6052). 이 잘 알려진 접두사는 모든 사람에게 "IPv4 주소가 여기에 임베디드되어 있습니다"라고 알려줍니다.
IPv4 주소 임베딩은 다음과 같이 작동합니다:
IPv4 주소: 198.51.100.10
16진수: C6.33.64.0A
NAT64 접두사: 64:ff9b::
결합: 64:ff9b::c633:640a
확장: 64:ff9b::198.51.100.10 (일반 표기법)IPv6 주소의 마지막 32비트에는 IPv4 주소가 포함됩니다. 애플리케이션은 이를 절대 보지 않습니다. 변환 인프라에만 내부적입니다.
잘 알려진 접두사 대신 사용자 정의 접두사를 사용할 수 있습니다. 일반적인 선택에는 2001:db8:64::/96과 같은 조직별 접두사가 포함됩니다. 이를 통해 트래픽 엔지니어링(NAT64 트래픽을 다르게 라우팅)이 가능하지만 DNS64 구성 변경이 필요합니다.
DNS64 심층 분석#
DNS64는 특별한 변환 로직이 있는 DNS 서버입니다. AAAA 쿼리를 가로채고 A 레코드만 존재할 때 응답을 합성합니다.
DNS64 로직 흐름#
example.com에 대한 AAAA 쿼리
↓
AAAA에 대한 업스트림 쿼리
↓
AAAA 레코드 존재? ─ 예 ─→ AAAA 레코드 반환 (네이티브 IPv6)
│
아니요
↓
A에 대한 업스트림 쿼리
↓
A 레코드 존재? ─ 아니요 ─→ NXDOMAIN 반환
│
예
↓
AAAA = 접두사 + IPv4 합성
↓
합성된 AAAA 반환주요 동작:
- 네이티브 IPv6 우선: AAAA가 존재하면 DNS64는 변경하지 않고 반환합니다. 합성 없음. NAT64 관여하지 않음.
- IPv4 폴백만: AAAA가 존재하지 않을 때만 합성 발생
- 캐시 TTL 유지: 합성된 레코드는 A 레코드의 TTL을 상속
- DNSSEC 복잡성: 합성은 DNSSEC 검증을 깨뜨림(나중에 자세히)
DNS64 구성 예#
BIND 9:
options {
// ... 다른 옵션 ...
dns64 64:ff9b::/96 {
clients { any; };
mapped { !192.168.0.0/16; !10.0.0.0/8; any; };
exclude { 64:ff9b::/96; ::ffff:0:0/96; };
suffix ::;
};
};매개변수:
clients: DNS64를 받는 클라이언트(보통any)mapped: 변환할 IPv4 주소(RFC 1918 사설 주소 제외)exclude: 합성하지 않을 IPv6 범위suffix: 주소에서 IPv4가 임베디드되는 위치 사용자 정의(고급)
Unbound:
server:
module-config: "dns64 validator iterator"
dns64:
dns64-prefix: 64:ff9b::/96
dns64-synthall: nodns64-synthall: AAAA가 존재할 때도 합성할지 여부(보통 no)
PowerDNS Recursor:
# recursor.conf에서
enable-dns64: yes
dns64-prefix: 64:ff9b::/96DNS64 탐색#
클라이언트는 DNS64를 제공하는 DNS 서버를 알아야 합니다. 일반적으로 다음을 통해 구성됩니다:
라우터 광고(SLAAC):
# radvd.conf
interface eth0 {
RDNSS 2001:db8::53 {
AdvRDNSSLifetime 300;
};
};DHCPv6:
option dhcp6.name-servers 2001:db8::53;최신 운영 체제는 RA 및 DHCPv6 모두에서 DNS 서버를 수락합니다.
NAT64 심층 분석#
NAT64는 상태 저장 변환입니다. 기존 NAT44와 같이 세션 상태를 유지합니다. 각 클라이언트 연결은 NAT64 게이트웨이의 상태 테이블에 매핑됩니다.
상태 저장 변환#
NAT64 게이트웨이가 추적하는 것:
- IPv6 소스 주소 및 포트
- IPv4 대상 주소 및 포트
- 변환된 IPv4 소스 주소 및 포트
- 프로토콜(TCP/UDP/ICMP)
- 세션 타이머
세션 테이블 항목:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
IPv6 클라이언트 측 │ IPv4 서버 측
━━━━━━━━━━━━━━━━━━━━━━━━━━┿━━━━━━━━━━━━━━━━━━━━━━━━━━
2001:db8:100::45:1234 │ 203.0.113.5:6789
(클라이언트 IPv6:포트) │ (NAT IPv4:포트)
│ ↕
│ 198.51.100.10:80
│ (대상 IPv4:포트)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
프로토콜: TCP
상태: ESTABLISHED
타임아웃: 7440초반환 트래픽이 203.0.113.5:6789에 도착하면 NAT64는 세션을 조회하고 2001:db8:100::45:1234로 재변환합니다.
프로토콜 변환#
NAT64는 주소 이상을 변환합니다. IPv4 및 IPv6 패킷 형식 간에 변환합니다:
IPv6 패킷:
[ IPv6 헤더 | TCP/UDP/ICMP 헤더 | 페이로드 ]IPv4로 변환:
[ IPv4 헤더 | TCP/UDP/ICMP 헤더 | 페이로드 ]변환에는 다음이 포함됩니다:
- TTL/Hop Limit: 감소 및 복사
- 단편화: IPv6 단편화 → IPv4 단편화(MTU 고려)
- ICMP: ICMPv6 → ICMPv4(메시지 유형 매핑)
- 체크섬: 새 프로토콜 헤더에 대해 재계산
주소 지정 풀#
NAT64에는 아웃바운드 연결을 위한 IPv4 주소가 필요합니다. 소규모 배포는 포트 오버로딩과 함께 단일 IPv4 주소를 사용합니다(홈 라우터처럼). 대규모 배포는 풀을 사용합니다.
# 소규모: 단일 IPv4
NAT64 풀: 203.0.113.5/32
최대 클라이언트: 약 65,000개의 동시 세션
# 대규모: IPv4 풀
NAT64 풀: 203.0.113.0/24
최대 클라이언트: 약 1,600만 개의 동시 세션주소 고갈 문제가 적용됩니다. NAT64는 NAT44와 동일한 포트 제한에 직면합니다.
구현 옵션#
경량부터 통신사급까지 여러 NAT64 소프트웨어 구현이 존재합니다.
TAYGA: 경량 사용자 공간#
TAYGA는 Linux용 간단한 사용자 공간 NAT64 데몬입니다. 소규모 배포 및 테스트에 적합합니다.
설치:
apt-get install tayga
# TUN 인터페이스 생성
ip tuntap add name nat64 mode tun
ip link set nat64 up
ip addr add 192.168.255.1/24 dev nat64
ip addr add 2001:db8:ffff::1/96 dev nat64구성 (/etc/tayga.conf):
tun-device nat64
ipv4-addr 192.168.255.1
ipv6-addr 2001:db8:ffff::1
prefix 64:ff9b::/96
dynamic-pool 192.168.255.0/24
data-dir /var/lib/tayga시작 및 라우팅:
systemctl start tayga
# TAYGA를 통해 NAT64 접두사 라우팅
ip route add 64:ff9b::/96 dev nat64
ip route add 192.168.255.0/24 dev nat64
# 포워딩 활성화
sysctl -w net.ipv6.conf.all.forwarding=1
sysctl -w net.ipv4.ip_forward=1장점: 간단함, 경량, 쉬운 설정 단점: 제한된 성능(사용자 공간), 클러스터링 없음, 최소 기능
Jool: 커널 모듈#
Jool은 NAT64를 Linux 커널 모듈로 구현하여 더 나은 성능을 제공합니다.
설치:
# 저장소 추가 (Debian/Ubuntu)
apt-get install linux-headers-$(uname -r)
apt-get install jool-dkms jool-tools
# 모듈 로드
modprobe jool구성:
# NAT64 인스턴스 생성
jool instance add "default" --netfilter --pool6 64:ff9b::/96
# IPv4 주소 풀 추가
jool -i "default" pool4 add --tcp 203.0.113.5 1024-65535
jool -i "default" pool4 add --udp 203.0.113.5 1024-65535
jool -i "default" pool4 add --icmp 203.0.113.5 1024-65535
# 활성화
jool -i "default" global update enabled true라우팅:
ip route add 64:ff9b::/96 via 2001:db8::1장점: 고성능(커널 공간), 활발한 개발, 좋은 문서 단점: 커널 모듈 복잡성, 커널 업데이트와의 가끔 호환성 문제
클라우드 공급자 NAT64#
주요 클라우드 플랫폼은 관리형 NAT64를 제공합니다:
AWS (송신 전용 인터넷 게이트웨이를 통한 NAT64):
AWS는 네이티브 NAT64를 제공하지 않지만 EC2 인스턴스에 Jool 또는 TAYGA를 배포할 수 있습니다. 일부 타사 AMI가 존재합니다.
대안: 내부 IPv6 전용 네트워크 및 외부 액세스를 위한 IPv4로 듀얼 스택 사용.
Google Cloud Platform:
GCP는 NAT64 지원으로 Cloud NAT를 제공합니다(베타):
# NAT64 서브넷 생성
gcloud compute networks subnets create nat64-subnet \
--network=my-network \
--region=us-central1 \
--range=10.0.0.0/24 \
--enable-nat64
# Cloud NAT 구성
gcloud compute routers nats create my-nat64 \
--router=my-router \
--region=us-central1 \
--enable-nat64 \
--nat64-prefix=64:ff9b::/96Azure:
Azure는 IPv6를 지원하지만 관리형 NAT64를 제공하지 않습니다. Jool 또는 TAYGA를 사용하여 Linux VM을 사용하여 자체 배포하세요.
장점(관리형 서비스): 유지 관리 없음, 확장 가능, 통합 모니터링 단점: 클라우드 특정, 구성 유연성 감소, 잠재적 비용
통신사급 NAT64#
통신 및 대형 ISP 배포는 상용 솔루션을 사용합니다:
- Cisco ASR with CGv6
- Juniper MX Series with NAT64 service
- A10 Thunder CGN
- F5 BIG-IP with CGNAT module
이들은 고가용성, 법적 준수를 위한 로깅 및 정교한 트래픽 정책으로 수백만 개의 동시 세션을 처리합니다.
464XLAT: IPv4 전용 애플리케이션 활성화#
NAT64/DNS64는 듀얼 스택 애플리케이션에 투명하게 작동합니다. 하지만 일부 앱은 IPv4 주소를 하드코딩하거나 DNS64가 가로챌 수 없는 프로토콜을 사용합니다. 464XLAT가 이를 해결합니다.
464XLAT 작동 방식#
464XLAT는 NAT64(PLAT) 이전에 클라이언트 측 변환(CLAT)을 추가합니다:
┌─────────────┐ ┌──────────────┐ ┌──────────────┐
│ IPv4 앱 │ │ │ │ │
│ │ │ IPv6 전용 │ │ IPv4 서버 │
│ 192.0.0.10 │ │ 네트워크 │ │198.51.100.10 │
└──────┬──────┘ └──────────────┘ └──────────────┘
│ │
CLAT (로컬) PLAT (ISP)
NAT46: IPv4→IPv6 NAT64: IPv6→IPv4
│ │
└──────────── IPv6 네트워크 ─────────────────┘단계:
- 앱이 192.0.0.10(CLAT 가상 인터페이스)으로 IPv4 패킷 전송
- CLAT가 로컬 접두사를 사용하여 IPv4 → IPv6로 변환(예: 64:ff9b::c000:0a)
- IPv6 패킷이 PLAT(NAT64 게이트웨이)로 네트워크를 통과
- PLAT가 IPv6 → IPv4로 변환
- IPv4 패킷이 대상에 도달
앱은 로컬 IPv4 연결을 봅니다. 네트워크는 IPv6 전용입니다. 양 끝에서 변환이 발생합니다.
모바일에서의 464XLAT#
Android 및 iOS는 NAT64가 있는 IPv6 전용 네트워크에 연결될 때 자동으로 CLAT를 구현합니다:
Android CLAT:
ipv4only.arpa를 쿼리하여 NAT64 탐지(NAT64가 존재하면 합성된 AAAA 반환)- 192.0.0.0/29 주소로
clat4인터페이스 생성 - CLAT를 통해 IPv4 앱 트래픽 라우팅
- 탐지된 NAT64 접두사를 사용하여 IPv6로 변환
iOS CLAT:
- 유사한 탐지 메커니즘
- 앱 및 사용자에게 투명
이것이 IPv4 전용 앱이 T-Mobile, AT&T 및 기타 IPv6 전용 모바일 네트워크에서 작동하는 이유입니다.
Clatd를 사용한 Linux 464XLAT#
IPv6 전용 네트워크의 Linux 시스템용:
# 설치
apt-get install clatd
# /etc/clatd.conf 구성
clat-v4-addr=192.0.0.1
clat-v6-addr=2001:db8:1234:5678::1
plat-prefix=64:ff9b::/96
# 시작
systemctl enable --now clatd
# 확인
ip addr show clat
ping -4 8.8.8.8 # IPv6 전용 네트워크에서도 작동해야 함다음과 같은 경우 464XLAT 사용:
- 업데이트할 수 없는 IPv4 전용 애플리케이션이 있음
- 애플리케이션이 DNS를 우회(하드코딩된 IP)
- IPv6 전용 인프라에서 투명한 IPv4 지원이 필요
배포 시나리오#
NAT64/DNS64는 특정 사용 사례에 적합합니다. 배포 시기를 이해하면 아키텍처 실수를 피할 수 있습니다.
시나리오 1: 모바일 네트워크#
상황: 수백만 명의 가입자가 있는 5G/LTE 통신사, 제한된 IPv4 주소
솔루션: NAT64/DNS64 + 464XLAT가 있는 IPv6 전용 네트워크
이점:
- 무선 네트워크 및 코어에서 IPv4 제거
- 단순화된 라우팅(단일 프로토콜)
- IPv4 주소 제약 없이 확장
- 464XLAT를 통한 레거시 앱 지원
구현:
- 통신사 코어의 PLAT (NAT64)
- 통신사 DNS 서버의 DNS64
- 핸드셋의 CLAT (자동)
이것은 전 세계적으로 지배적인 모바일 아키텍처입니다.
시나리오 2: 기업 IPv6 전용 네트워크#
상황: 새 데이터 센터, 듀얼 스택 복잡성을 피하기 위해 IPv6 전용 원함
솔루션: IPv6 전용 내부 네트워크, 외부 IPv4 서비스에 액세스하기 위한 NAT64
이점:
- 단순화된 주소 지정(IPv4 DHCP, NAT 등 없음)
- 현대적인 아키텍처
- 애플리케이션이 IPv6를 지원하도록 강제
과제:
- 일부 기업 앱은 IPv4 전용으로 남아 있음
- 관리 인터페이스는 종종 IPv4 전용
- 레거시 하드웨어 호환성
권장 사항: 기업의 경우 듀얼 스택이 일반적으로 더 쉽습니다. IPv6 전용은 그린필드, 클라우드 네이티브 환경에 적합합니다.
시나리오 3: 클라우드 네이티브 마이크로서비스#
상황: Kubernetes 클러스터, 서비스가 IPv6를 통해 내부적으로 통신
솔루션: 외부 IPv4 API 종속성을 위한 NAT64가 있는 IPv6 전용 클러스터
이점:
- 단순화된 서비스 메시
- 대규모 클러스터에서 IPv4 주소 고갈 없음
- 컨테이너 네트워킹을 위한 네이티브 IPv6
구현:
- Kubernetes IPv6 전용 모드
- 송신을 위한 NAT64 게이트웨이
- 클러스터 DNS를 통한 DNS64 (CoreDNS 지원)
# DNS64가 있는 CoreDNS ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
health
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
dns64 64:ff9b::/96
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}컨테이너 오케스트레이션에서 IPv6가 표준이 되면서 증가하는 사용 사례입니다.
제한 사항 및 함정#
NAT64/DNS64는 완벽하지 않습니다. 제한 사항을 이해하면 배포 실패를 방지할 수 있습니다.
1. DNSSEC 중단#
DNS64는 권한 영역에 존재하지 않는 AAAA 레코드를 합성합니다. DNSSEC 서명은 이러한 합성 레코드를 포함하지 않으므로 검증이 실패합니다.
솔루션:
- DNS64 리졸버에서 DNSSEC 검증 비활성화(이상적이지 않음)
- RFC 6147 DNSSEC 처리를 지원하는 DNS64 사용(제한된 구현)
- DNSSEC 서명된 IPv4 전용 도메인이 검증되지 않는다는 것을 수락
이것은 DNS64의 가장 큰 운영 과제입니다.
2. 하드코딩된 IPv4 주소#
하드코딩된 IP가 있는 애플리케이션은 DNS를 우회하므로 DNS64는 쿼리를 보지 못합니다. NAT64는 NAT64 접두사만 인식하므로 도움이 되지 않습니다.
솔루션:
- 464XLAT 배포(모든 IPv4 트래픽 처리)
- DNS 이름을 사용하도록 애플리케이션 업데이트
- 애플리케이션 계층 게이트웨이 사용(드물고 복잡함)
3. URL의 IPv4 리터럴#
URL 또는 구성에서 http://192.0.2.1/api를 전달하는 웹 앱. 브라우저는 IP 리터럴에 대해 DNS 조회를 수행하지 않으므로 DNS64는 합성하지 않습니다.
솔루션:
- IP 리터럴 대신 호스트 이름 사용
- 리터럴을 다시 작성하는 애플리케이션 계층 프록시
- 464XLAT
4. FTP 및 기타 ALG#
애플리케이션 데이터에 IP 주소를 임베디드하는 프로토콜(FTP 능동 모드, SIP 등)은 종종 NAT64를 통해 실패합니다. 페이로드의 주소가 패킷 헤더와 일치하지 않습니다.
솔루션:
- FTP 수동 모드 사용(임베디드 주소 없음)
- ALG 지원이 있는 프로토콜 인식 NAT64 배포(복잡함)
- IP를 임베디드하지 않는 최신 프로토콜로 이동
5. 단편화 문제#
IPv4 및 IPv6 간의 경로 MTU 차이로 인해 단편화 문제가 발생할 수 있습니다. IPv6의 최소 MTU는 1280바이트입니다. IPv4는 576바이트를 허용합니다.
솔루션:
- 인프라 전체에서 MTU가 일관되도록 보장
- 경로 MTU 탐색(PMTUD) 활성화
- ICMP Packet Too Big 메시지 모니터링 및 경고
6. 역방향 DNS#
NAT64로 변환된 주소에 대한 PTR 레코드가 존재하지 않습니다. 역방향 DNS가 필요한 애플리케이션(일부 메일 서버, 액세스 제어)이 실패할 수 있습니다.
솔루션:
- NAT64 풀에 대한 PTR 레코드 생성
- 역방향 DNS를 요구하지 않도록 서비스 구성
- 역방향 DNS가 중요한 경우 기본적으로 IPv6 사용
듀얼 스택 대체가 아님
NAT64/DNS64는 IPv6 전용 네트워크가 IPv4 리소스에 도달하기 위한 도구입니다. 자체적으로 마이그레이션 전략이 아닙니다. 듀얼 스택은 대부분의 네트워크에 권장되는 경로로 남아 있습니다. IPv6 전용이 아키텍처적으로 의미가 있는 곳(모바일, 클라우드 네이티브, 그린필드)에서 NAT64/DNS64를 사용하세요.
모니터링 및 문제 해결#
NAT64/DNS64는 문제를 모호하게 만들 수 있는 변환 계층을 추가합니다. 적절한 모니터링이 필수적입니다.
DNS64 확인#
DNS64가 작동하는지 테스트:
# 알려진 IPv4 전용 도메인에 대한 쿼리
dig AAAA ipv4.google.com @2001:db8::53
# NAT64 접두사로 합성된 AAAA를 반환해야 함
# 예: 64:ff9b::8.8.8.8AAAA 레코드를 얻지 못하면 DNS64가 작동하지 않습니다.
NAT64 연결 테스트#
특수 테스트 도메인 ipv4only.arpa 사용:
# IPv6 전용 클라이언트에서
ping6 ipv4only.arpa
# NAT64를 통해 응답을 받아야 함
# 도메인은 192.0.0.170으로 확인되고 64:ff9b::192.0.0.170으로 합성됨ping이 실패하면 NAT64 게이트웨이에 연결할 수 없거나 변환하지 않습니다.
세션 테이블 검사#
NAT64 세션 상태 확인:
Jool:
jool -i "default" session display
# 활성 세션 표시
# 다음을 찾으세요: 클라이언트 IPv6, 변환된 IPv4, 대상TAYGA:
cat /var/lib/tayga/dynamic.map
# 주소 매핑 표시높은 세션 수는 과도한 사용 또는 잠재적인 문제(연결 누출)를 나타냅니다.
트래픽 분석#
변환 전후 트래픽 캡처:
# NAT64 접두사로의 IPv6 트래픽 캡처
tcpdump -i eth0 -n 'ip6 and dst net 64:ff9b::/96'
# 변환된 IPv4 트래픽 캡처
tcpdump -i eth1 -n 'ip and src 203.0.113.5'
# 변환을 확인하기 위해 비교다음을 찾으세요:
- NAT64에 도착하지만 변환되지 않는 패킷
- 변환되지만 전달되지 않는 패킷
- 비대칭 라우팅(반환 트래픽이 NAT64에 도달하지 않음)
일반적인 문제#
증상: DNS64가 합성된 AAAA를 반환하지만 연결 실패
원인:
- NAT64 게이트웨이에 연결할 수 없음
- NAT64 접두사를 차단하는 방화벽
- 라우팅 문제(NAT64 접두사로의 패킷이 잘못된 방향으로 이동)
디버그:
traceroute6 64:ff9b::198.51.100.1
# NAT64 게이트웨이로 라우팅되어야 함증상: 일부 사이트는 작동하지만 다른 사이트는 작동하지 않음
원인:
- 네이티브 IPv6가 있는 사이트 작동(NAT64 관여하지 않음)
- 특별한 요구 사항이 있는 IPv4 전용 사이트 실패
- 단편화 또는 MTU 문제
디버그:
# 다른 MTU로 테스트
ping6 -M do -s 1400 64:ff9b::198.51.100.1증상: 연결이 느리거나 타임아웃
원인:
- NAT64 게이트웨이 과부하
- 세션 테이블 가득 참
- 비대칭 라우팅
디버그:
# NAT64 CPU 및 세션 수 확인
# 연결 설정 시간 모니터링
time curl -6 http://ipv4-only-site.example.com보안 고려 사항#
NAT64는 일반적인 NAT를 넘어 보안 영향을 도입합니다.
주소 공간 스캐닝#
NAT64 접두사는 IPv6에서 IPv4 주소를 예측 가능하게 만듭니다. 공격자는 64:ff9b::/96를 스캔하여 액세스하는 IPv4 서비스를 발견할 수 있습니다.
완화: 잘 알려진 접두사 대신 네트워크별 NAT64 접두사를 사용하여 노출을 제한합니다.
액세스 제어 우회#
IPv4 액세스 제어(방화벽 규칙, ACL)는 예상치 못한 IPv6 소스에서 도착하는 NAT64로 변환된 트래픽을 고려하지 않을 수 있습니다.
완화: 엔드포인트뿐만 아니라 NAT64 게이트웨이에 보안 정책을 적용합니다.
공격 증폭기로서의 NAT64#
IPv6 전용 네트워크의 공격자는 NAT64를 사용하여 IPv4 대상에 대한 공격을 시작할 수 있으며 IPv4 기반 속도 제한 또는 블랙리스트를 우회할 수 있습니다.
완화:
- 소스당 NAT64 세션 속도 제한
- 남용 조사를 위한 모든 NAT64 변환 로그
- IPv4 NAT와 동일한 보안 정책 적용
DNS64 캐시 중독#
DNS64 서버가 손상되면 공격자는 NAT64를 통해 공격자 제어 IPv4 주소를 가리키는 악의적인 AAAA 레코드를 합성할 수 있습니다.
완화:
- DNS64 서버 보안(모든 DNS 인프라와 동일)
- 가능한 경우 DNSSEC 사용(호환성 문제에도 불구하고)
- 비정상적인 합성 패턴에 대한 DNS64 모니터링
NAT64/DNS64 대 듀얼 스택 사용 시기#
의사 결정 프레임워크:
┌─────────────────────────────────────────────────┐
│ 듀얼 스택을 실행할 수 있습니까? │
└─────────────────────┬───────────────────────────┘
│
┌───────────┴──────────┐
│ │
예 아니요
│ │
▼ ▼
┌─────────────┐ ┌─────────────────────┐
│ 듀얼 스택 │ │ 왜 안 됩니까? │
│ 사용 │ │ │
│ │ │ • IPv4 고갈 │
│ (더 간단함, │ │ • 아키텍처 │
│ 문제 적음) │ │ 단순화 │
│ │ │ • 모바일 네트워크 │
└─────────────┘ │ • 클라우드 네이티브 │
└──────────┬──────────┘
│
▼
┌────────────────────┐
│ NAT64/DNS64 사용 │
│ │
│ 다음의 경우 │
│ 464XLAT 추가: │
│ • IPv4 전용 앱 │
│ • 하드코딩된 IP │
└────────────────────┘NAT64/DNS64가 적합한 경우:
- IPv4 주소 고갈이 실제 제약
- 새로운 인프라 구축(그린필드)
- 모바일 네트워크 또는 클라우드 네이티브 아키텍처
- 단일 스택의 운영 이점이 변환 복잡성을 능가
듀얼 스택이 적합한 경우:
- IPv4 주소 사용 가능
- 레거시 및 최신 인프라 혼합
- 호환성이 최우선 순위
- 듀얼 스택에 대한 팀 친숙도
NAT64의 미래#
IPv6 전용 네트워크가 더 일반화됨에 따라 NAT64 채택이 증가합니다:
추세:
- 모바일 통신사는 거의 보편적으로 배포
- 관리형 NAT64 옵션을 추가하는 클라우드 공급자
- IPv6 전용 + NAT64를 사용하는 IoT 및 엣지 컴퓨팅
- 비용/단순성을 위해 IPv6 전용을 실험하는 데이터 센터
남아 있는 과제:
- DNSSEC 호환성은 여전히 우아하게 해결되지 않음
- 애플리케이션 계층 프로토콜 문제 지속
- 운영 전문 지식은 여전히 개발 중
장기: IPv4 인터넷이 축소되고 IPv6가 유비쿼터스가 됨에 따라 NAT64 사용이 감소할 수 있습니다. 대부분의 대상이 네이티브 IPv6를 가지고 있어 변환이 필요하지 않습니다. 하지만 그것은 수년 후입니다. 현재로서는 NAT64/DNS64가 IPv6 전용 네트워크를 가능하게 하는 핵심 기술입니다.
작게 시작하고 테스트#
철저한 테스트 없이 프로덕션에 NAT64/DNS64를 배포하지 마세요:
- 랩 환경: 테스트 네트워크에 TAYGA 또는 Jool 설정
- DNS64 구성: BIND 또는 Unbound 사용
- 애플리케이션 테스트: 특정 앱이 변환을 통해 작동하는지 확인
- 성능 모니터링: 지연 시간 및 처리량 오버헤드 측정
- 문제 문서화: 문제가 있는 앱 또는 서비스 기록
- 해결 방법 계획: 문제가 있는 서비스에 대한 듀얼 스택, 다른 서비스에 대한 464XLAT
성공적인 테스트 후에만 프로덕션 배포를 고려해야 하며, 그 경우에도 중요하지 않은 네트워크 또는 사용자 세그먼트로 시작하세요.
NAT64/DNS64는 강력하지만 복잡성을 추가합니다. 실제 문제를 해결하는 곳에서 사용하세요. 새로운 기술이기 때문이 아니라.
관련 글#
- IPv6 마이그레이션 전략 - 올바른 마이그레이션 접근 방식 선택
- 듀얼 스택 IPv6 배포 - IPv4 및 IPv6를 함께 실행
- IPv6 DNS 구성 - IPv6용 DNS 설정
자주 묻는 질문#
듀얼 스택이 있으면 NAT64가 필요한가요?
아니요. 듀얼 스택 네트워크는 IPv4 및 IPv6 연결이 모두 기본적으로 존재하므로 NAT64가 필요하지 않습니다. NAT64는 IPv4 전용 대상에 액세스하는 IPv6 전용 네트워크 전용입니다. 듀얼 스택이 있으면 클라이언트는 IPv4를 사용하여 IPv4 서버에 직접 연결하고 IPv6를 사용하여 IPv6 서버에 직접 연결합니다.
DNS64 없이 NAT64를 사용할 수 있나요?
기술적으로는 가능하지만 비현실적입니다. DNS64가 없으면 클라이언트는 NAT64 접두사에 IPv4 주소를 임베디드하여 합성된 IPv6 주소를 수동으로 구성해야 합니다. 이를 위해서는 애플리케이션 또는 사용자가 NAT64 접두사를 알고 수동 변환을 수행해야 합니다. DNS64는 이를 자동화하여 NAT64를 투명하게 만듭니다. 항상 함께 배포하세요.
DNS64로 DNSSEC 검증이 실패하는 이유는 무엇인가요?
DNS64는 권한 DNS 영역에 존재하지 않는 AAAA 레코드를 합성합니다. 이러한 합성 레코드에는 DNSSEC 서명이 없어 검증이 실패합니다. DNS64 리졸버에서 DNSSEC 검증을 비활성화하거나, DNSSEC를 신중하게 처리하는 DNS64 구현을 사용하거나(제한된 옵션), DNSSEC 서명된 IPv4 전용 도메인이 검증되지 않는다는 것을 수락할 수 있습니다. 이것은 현재 완벽한 솔루션이 없는 알려진 제한 사항입니다.
NAT64와 NAT44의 차이점은 무엇인가요?
NAT44는 IPv4를 IPv4로 변환합니다(홈 라우터처럼 소스 주소 변경). NAT64는 IPv6와 IPv4 간에 변환합니다(프로토콜을 완전히 변경). 둘 다 세션 상태를 유지하고 유사한 포트 고갈 문제에 직면합니다. NAT64는 패킷 형식을 변환하고, ICMP 유형 매핑을 처리하고, IPv4 및 IPv6 간의 MTU 차이를 처리해야 하므로 더 복잡합니다.