NAT64 и DNS64: Подключение IPv6-сетей к IPv4

Будущее с IPv6-only#

Dual-stack — одновременная работа IPv4 и IPv6 — стандартный подход к миграции. Но поддержание двух параллельных сетей вечно не является целью. Конечная точка — инфраструктура IPv6-only с доступом к устаревшему IPv4 только при необходимости.

Этот переход уже происходит в мобильных сетях. Крупные операторы используют IPv6-only стеки на смартфонах. T-Mobile, AT&T и Verizon исключили IPv4 из своих LTE/5G сетей годы назад. Ваш телефон имеет IPv6-адрес. Когда вы обращаетесь к сайту, работающему только на IPv4, NAT64 и DNS64 прозрачно обрабатывают преобразование.

Корпоративные сети следуют тем же путем. IPv6-only снижает сложность, устраняет проблемы истощения IPv4-адресов и упрощает маршрутизацию. Но полное исключение IPv4 пока нереалистично — слишком много сервисов остаются IPv4-only. NAT64 и DNS64 заполняют этот пробел, позволяя IPv6-only сетям получать доступ к IPv4-интернету.

Как работают NAT64 и DNS64 вместе#

NAT64 выполняет преобразование протоколов на сетевом уровне. DNS64 синтезирует IPv6-адреса, которые запускают это преобразование. Они работают в паре — DNS64 без NAT64 бесполезен, а NAT64 без DNS64 требует ручной настройки.

Поток преобразования#

Вот что происходит, когда IPv6-only клиент обращается к IPv4-only сервису:

┌─────────────────────────────────────────────────────────────────┐
│ 1. Клиент запрашивает DNS для www.ipv4only.example.com        │
│    Тип запроса: 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                               │
│    Изменяет заголовки пакетов                                  │
│    Выполняет stateful NAT (отслеживает сессию)                │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 7. IPv4-пакет отправлен к назначению                           │
│    Источник: IPv4-адрес NAT64-шлюза                            │
│    Назначение: 198.51.100.10                                   │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 8. Обратный трафик преобразуется обратно                       │
│    NAT64 ищет сессию                                           │
│    Преобразует IPv4 → IPv6                                     │
│    Перенаправляет клиенту                                      │
└─────────────────────────────────────────────────────────────────┘

Клиент видит только IPv6. IPv4-only сервис видит только IPv4. NAT64 и DNS64 прозрачно обрабатывают преобразование.

Общеизвестный префикс#

Стандартный префикс NAT64 — 64:ff9b::/96 (RFC 6052). Этот общеизвестный префикс сообщает всем: «IPv4-адреса встроены здесь».

Встраивание IPv4-адресов работает так:

IPv4-адрес:    198.51.100.10
В hex:          C6.33.64.0A
Префикс NAT64: 64:ff9b::
Объединенный:  64:ff9b::c633:640a
Развернутый:   64:ff9b::198.51.100.10 (общая нотация)

Последние 32 бита IPv6-адреса содержат IPv4-адрес. Приложения никогда этого не видят — это чисто внутреннее для инфраструктуры преобразования.

Вы можете использовать пользовательские префиксы вместо общеизвестного. Распространенный выбор включает специфичные для организации префиксы, такие как 2001:db8:64::/96. Это позволяет traffic engineering (маршрутизацию NAT64-трафика по-другому), но требует изменений в конфигурации DNS64.

Глубокое погружение в DNS64#

DNS64 — это DNS-сервер со специальной логикой преобразования. Он перехватывает AAAA-запросы и синтезирует ответы, когда существуют только A-записи.

Логика работы DNS64#

AAAA-запрос для example.com
    ↓
Запрос вышестоящего DNS для AAAA
    ↓
AAAA-запись существует? ─ ДА ─→ Вернуть AAAA-запись (нативный IPv6)
    │
    НЕТ
    ↓
Запрос вышестоящего DNS для A
    ↓
A-запись существует? ─ НЕТ ─→ Вернуть NXDOMAIN
    │
    ДА
    ↓
Синтезировать AAAA = префикс + IPv4
    ↓
Вернуть синтезированную AAAA

Ключевое поведение:

• Предпочтение нативного IPv6: Если AAAA существует, DNS64 возвращает его неизмененным. Нет синтеза. NAT64 не задействован.
• Только IPv4 fallback: Синтез происходит только когда AAAA не существует
• Сохранение TTL кеша: Синтезированные записи наследуют TTL из A-записи
• Сложность 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: no

• dns64-synthall: Синтезировать ли даже когда AAAA существует (обычно нет)

PowerDNS Recursor:

# В recursor.conf
enable-dns64: yes
dns64-prefix: 64:ff9b::/96

Обнаружение DNS64#

Клиенты должны знать, какой DNS-сервер предоставляет DNS64. Обычно настраивается через:

Router Advertisements (SLAAC):

# radvd.conf
interface eth0 {
    RDNSS 2001:db8::53 {
        AdvRDNSSLifetime 300;
    };
};

DHCPv6:

option dhcp6.name-servers 2001:db8::53;

Современные операционные системы принимают DNS-серверы как из RA, так и из DHCPv6.

Глубокое погружение в NAT64#

NAT64 — это stateful преобразование — он поддерживает состояние сессии как традиционный NAT44. Каждое клиентское соединение получает запись в таблице состояний NAT64-шлюза.

Stateful преобразование#

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 Header | TCP/UDP/ICMP Header | Payload ]

Преобразован в IPv4:

[ IPv4 Header | TCP/UDP/ICMP Header | Payload ]

Преобразование включает:

• 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
Макс клиентов: ~16 миллионов одновременных сессий

Проблемы истощения адресов применяются — NAT64 сталкивается с теми же ограничениями портов, что и NAT44.

Варианты реализации#

Существует множество программных реализаций NAT64, от легковесных до операторского класса.

TAYGA: Легковесное userspace#

TAYGA — простой userspace NAT64-демон для Linux. Хорош для малых развертываний и тестирования.

Установка:

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
 
# Маршрут префикса NAT64 через TAYGA
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

Плюсы: Простота, легковесность, простая настройка Минусы: Ограниченная производительность (userspace), нет кластеризации, минимум функций

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

Плюсы: Высокая производительность (kernel space), активная разработка, хорошая документация Минусы: Сложность модуля ядра, иногда проблемы совместимости с обновлениями ядра

NAT64 облачных провайдеров#

Крупные облачные платформы предлагают управляемый NAT64:

AWS (NAT64 через Egress-Only Internet Gateway):

AWS не предоставляет нативный NAT64, но вы можете развернуть Jool или TAYGA на EC2-инстансах. Существуют некоторые сторонние AMI.

Альтернатива: Используйте dual-stack с IPv6-only внутренними сетями и IPv4 для внешнего доступа.

Google Cloud Platform:

GCP предоставляет Cloud NAT с поддержкой NAT64 (beta):

# Создайте 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::/96

Azure:

Azure поддерживает IPv6, но не предлагает управляемый NAT64. Разверните свой собственный используя Linux VM с Jool или TAYGA.

Плюсы (управляемые сервисы): Нет обслуживания, масштабируемость, интегрированный мониторинг Минусы: Специфичны для облака, меньше гибкости настройки, потенциальная стоимость

464XLAT: Включение IPv4-only приложений#

NAT64/DNS64 работает прозрачно для dual-stack приложений. Но некоторые приложения жестко кодируют IPv4-адреса или используют протоколы, которые DNS64 не может перехватить. 464XLAT решает это.

Как работает 464XLAT#

464XLAT добавляет клиентское преобразование (CLAT) перед NAT64 (PLAT):

┌─────────────┐      ┌──────────────┐      ┌──────────────┐
│  IPv4 App   │      │              │      │              │
│             │      │ IPv6-Only    │      │ IPv4 Server  │
│ 192.0.0.10  │      │ Network      │      │198.51.100.10 │
└──────┬──────┘      └──────────────┘      └──────────────┘
       │                                            │
   CLAT (local)                                PLAT (ISP)
   NAT46: IPv4→IPv6                           NAT64: IPv6→IPv4
       │                                            │
       └──────────── IPv6 Network ─────────────────┘

Шаги:

1. Приложение отправляет IPv4-пакет на 192.0.0.10 (виртуальный интерфейс CLAT)
2. CLAT преобразует IPv4 → IPv6 используя локальный префикс (например, 64:ff9b::c000:0a)
3. IPv6-пакет проходит сеть к PLAT (NAT64-шлюз)
4. PLAT преобразует IPv6 → IPv4
5. IPv4-пакет достигает назначения

Приложение видит локальную IPv4-связь. Сеть — IPv6-only. Преобразование происходит на обоих концах.

464XLAT на мобильных устройствах#

Android и iOS реализуют CLAT автоматически при подключении к IPv6-only сетям с NAT64:

Android CLAT:

• Обнаруживает NAT64 запросом ipv4only.arpa (возвращает синтезированную AAAA если NAT64 существует)
• Создает интерфейс clat4 с адресами 192.0.0.0/29
• Маршрутизирует IPv4-трафик приложений через CLAT
• Преобразует в IPv6 используя обнаруженный префикс NAT64

iOS CLAT:

• Аналогичный механизм обнаружения
• Прозрачен для приложений и пользователей

Вот почему IPv4-only приложения работают в T-Mobile, AT&T и других IPv6-only мобильных сетях.

Linux 464XLAT с Clatd#

Для Linux-систем в IPv6-only сетях:

# Установка
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-only сети

Используйте 464XLAT когда:

• У вас есть IPv4-only приложения, которые нельзя обновить
• Приложения обходят DNS (жестко закодированные IP)
• Вам нужна прозрачная поддержка IPv4 в IPv6-only инфраструктуре

Ограничения и подводные камни#

NAT64/DNS64 не идеальны. Понимание ограничений предотвращает неудачи развертывания.

1. DNSSEC ломается#

DNS64 синтезирует AAAA-записи, которые не существуют в авторитетной зоне. DNSSEC-подписи не покрывают эти синтетические записи, поэтому валидация не проходит.

Решения:

• Отключить валидацию DNSSEC на DNS64-резолвере (не идеально)
• Использовать DNS64 с поддержкой RFC 6147 обработки DNSSEC (ограниченная реализация)
• Принять, что DNSSEC-подписанные IPv4-only домены не будут валидироваться

Это самая большая операционная проблема с DNS64.

2. Жестко закодированные IPv4-адреса#

Приложения с жестко закодированными IP обходят DNS, поэтому DNS64 никогда не видит запрос. NAT64 не может помочь, потому что распознает только префикс NAT64.

Решения:

• Разверните 464XLAT (обрабатывает весь IPv4-трафик)
• Обновите приложения для использования DNS-имен
• Используйте application-layer gateways (редко, сложно)

3. IPv4-литералы в URL#

Веб-приложения передают http://192.0.2.1/api в URL или конфигурации. Браузеры не выполняют DNS-запросы для IP-литералов, поэтому DNS64 не синтезирует.

Решения:

• Использовать имена хостов вместо IP-литералов
• Application-layer прокси, которые переписывают литералы
• 464XLAT

4. FTP и другие ALG#

Протоколы, встраивающие IP-адреса в данные приложений (FTP активный режим, SIP и т.д.), часто не проходят через NAT64. Адрес в payload не соответствует заголовку пакета.

Решение:

• Использовать FTP пассивный режим (нет встроенных адресов)
• Разверните protocol-aware NAT64 с поддержкой ALG (сложно)
• Переходите на современные протоколы, которые не встраивают IP

5. Проблемы фрагментации#

Различия Path MTU между IPv4 и IPv6 могут вызывать проблемы с фрагментацией. IPv6 имеет минимальный MTU 1280 байт; IPv4 разрешает 576 байт.

Решение:

• Обеспечьте согласованность MTU в инфраструктуре
• Включите Path MTU Discovery (PMTUD)
• Мониторьте и оповещайте о ICMP Packet Too Big сообщениях

6. Reverse DNS#

PTR-записи для NAT64-преобразованных адресов не будут существовать. Приложения, требующие reverse DNS (некоторые почтовые серверы, контроль доступа), могут не работать.

Решение:

• Создайте PTR-записи для пула NAT64
• Настройте сервисы не требовать reverse DNS
• Используйте IPv6 нативно где reverse DNS важен

Мониторинг и устранение неполадок#

NAT64/DNS64 добавляет уровни преобразования, которые могут скрывать проблемы. Правильный мониторинг необходим.

Проверка DNS64#

Проверьте работает ли DNS64:

# Запрос для известного IPv4-only домена
dig AAAA ipv4.google.com @2001:db8::53
 
# Должен вернуть синтезированную AAAA с префиксом NAT64
# Пример: 64:ff9b::8.8.8.8

Если вы не получаете AAAA-запись, DNS64 не работает.

Тест связи NAT64#

Используйте специальный тестовый домен ipv4only.arpa:

# С IPv6-only клиента
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
 
# Показывает отображения адресов

Высокое количество сессий указывает на интенсивное использование или возможные проблемы (утечки соединений).

Анализ трафика#

Захват трафика до и после преобразования:

# Захват IPv6-трафика к префиксу NAT64
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)

Соображения безопасности#

NAT64 вводит последствия безопасности помимо типичного NAT.

Сканирование адресного пространства#

Префикс NAT64 делает IPv4-адреса предсказуемыми в IPv6. Атакующие могут сканировать 64:ff9b::/96 для обнаружения IPv4-сервисов, к которым вы обращаетесь.

Смягчение: Используйте специфичные для сети префиксы NAT64 вместо общеизвестного, ограничивая воздействие.

Обход контроля доступа#

IPv4-контроль доступа (правила файрвола, ACL) может не учитывать NAT64-преобразованный трафик, прибывающий с неожиданных IPv6-источников.

Смягчение: Применяйте политики безопасности к NAT64-шлюзу, а не только к конечным точкам.

NAT64 как усилитель атак#

Атакующие в IPv6-only сетях могут использовать NAT64 для запуска атак на IPv4-цели, потенциально обходя IPv4-based rate limiting или черные списки.

Смягчение:

• Ограничьте частоту NAT64-сессий на источник
• Логируйте все NAT64-преобразования для расследования злоупотреблений
• Применяйте те же политики безопасности, что и IPv4 NAT

Когда использовать NAT64/DNS64 vs. Dual-Stack#

Фреймворк решения:

┌─────────────────────────────────────────────────┐
│ Можете ли вы запустить dual-stack?              │
└─────────────────────┬───────────────────────────┘
                      │
          ┌───────────┴──────────┐
          │                      │
         ДА                     НЕТ
          │                      │
          ▼                      ▼
   ┌─────────────┐     ┌─────────────────────┐
   │ Используйте │     │ Почему нет?         │
   │ Dual-Stack  │     │                     │
   │             │     │ • Истощение IPv4    │
   │ (проще,     │     │ • Упрощение         │
   │  меньше     │     │   архитектуры       │
   │  проблем)   │     │ • Мобильная сеть    │
   └─────────────┘     │ • Cloud native      │
                       └──────────┬──────────┘
                                  │
                                  ▼
                         ┌────────────────────┐
                         │ Используйте        │
                         │ NAT64/DNS64        │
                         │                    │
                         │ Добавьте 464XLAT   │
                         │ если:              │
                         │ • IPv4-only приложения│
                         │ • Жестко закодированные IP│
                         └────────────────────┘

NAT64/DNS64 имеет смысл когда:

• Истощение IPv4-адресов — реальное ограничение
• Вы строите новую инфраструктуру (greenfield)
• Мобильная сеть или cloud-native архитектура
• Операционные преимущества single-stack перевешивают сложность преобразования

Dual-stack имеет смысл когда:

• IPv4-адреса доступны
• Смешанная устаревшая и современная инфраструктура
• Совместимость — высший приоритет
• Знакомство команды с dual-stack

Начните с малого и тестируйте#

Не развертывайте NAT64/DNS64 в production без тщательного тестирования:

1. Лабораторная среда: Настройте TAYGA или Jool в тестовой сети
2. Настройте DNS64: Используйте BIND или Unbound
3. Тестируйте приложения: Проверьте, что ваши конкретные приложения работают через преобразование
4. Мониторьте производительность: Измерьте задержку и накладные расходы пропускной способности
5. Документируйте проблемы: Отметьте, какие приложения или сервисы имеют проблемы
6. Планируйте обходные пути: Dual-stack для проблемных сервисов, 464XLAT для других

Только после успешного тестирования следует рассматривать production развертывание, и даже тогда начинайте с некритичных сетей или сегментов пользователей.

NAT64/DNS64 мощный, но добавляет сложность. Используйте там, где он решает реальные проблемы, а не потому что это новая технология.

Связанные статьи#

• Стратегии миграции IPv6 — Выбор правильного подхода к миграции
• Dual-Stack развертывание IPv6 — Одновременная работа IPv4 и IPv6
• Настройка IPv6 DNS — Настройка DNS для IPv6

Часто задаваемые вопросы#