NAT64/DNS64 на VDS: IPv6‑only инфраструктура и доступ к IPv4‑мирам

IPv6‑only инфраструктура на VDS — это меньше NAT‑слоёв, предсказуемые адреса и простая маршрутизация. Но в реальности часть внешних сервисов остаётся только в IPv4. Комбинация NAT64 и DNS64 позволяет сохранить чистый IPv6 внутри и при этом прозрачно ходить к IPv4‑ресурсам.

Что такое NAT64/DNS64 и как это работает

DNS64 — это резолвер, который при отсутствии AAAA‑записи синтезирует её из A‑записи, упаковывая IPv4 в выделенный IPv6‑префикс (часто 64:ff9b::/96). Клиент видит AAAA, строит IPv6‑сеанс до адреса из этого префикса. На границе сети NAT64 преобразует этот IPv6‑трафик в IPv4 и обратно.

Если упрощать:

• Клиент IPv6‑only делает getaddrinfo().
• DNS64 выдаёт синтетический AAAA, например 64:ff9b::c000:00aa для 192.0.0.170.
• Маршрутизация отправляет пакет к узлу NAT64 (ваш VDS‑шлюз).
• NAT64 преобразует пакет в IPv4 с исходником из пула egress‑адресов и ведёт состояние сессии.

Итог: приложения и сеть «думают», что всё IPv6, а доступ к «IPv4‑мирам» работает без изменения кода.

Когда это уместно

• Вы проектируете IPv6‑only сегмент и хотите минимизировать точечные костыли.
• Нужно обеспечить исходящий доступ к IPv4 для обновлений, CI/CD, артефактов, API, не меняя каждое приложение.
• Нужен единый контрольный шлюз и аудит трафика.

Важно понимать ограничения: NAT64 по умолчанию решает только исходящие соединения из IPv6‑сегмента к IPv4. Для входящих подключений от IPv4‑клиентов к вашим сервисам в IPv6‑сети нужны другие механики (например, статический SIIT, прокси на границе, Anycast фронты и т. п.).

Адресация и префикс: well‑known или свой

Есть два подхода:

• Well‑Known Prefix (WKP) 64:ff9b::/96. Удобно для старта и совместимо с большинством клиентов. Не маршрутизируется в интернет, применяется локально.
• Собственный префикс из вашего IPv6‑блока. Гибкость для сложных доменов маршрутизации, изоляция и наблюдаемость (по префиксу легко фильтровать). Требует явной раздачи маршрута до NAT64.

Для небольших и средних установок используйте 64:ff9b::/96. Важно: вне зависимости от выбранного префикса, клиенты должны знать, что маршрут на этот префикс идёт через ваш NAT64‑узел.

Предпосылки к развертыванию на VDS

• Хост с публичным IPv6 и включённой пересылкой IPv6.
• Для доступа в IPv4‑интернет у NAT64 должен быть реальный egress IPv4. Если ваш VDS строго IPv6‑only без IPv4 — используйте внешний узел‑шлюз с IPv4 или провайдерский NAT64 upstream.
• Резолвер DNS64, обслуживающий ваших клиентов (локально на хосте или централизованно).

Если ожидается большая нагрузка, заранее оцените ресурсы хоста и профиль трафика — поможет материал как выбрать конфигурацию VDS по CPU и RAM.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

План работ

1. Включить пересылку и базовые sysctl по IPv6/MTU/ICMP.
2. Выбрать движок NAT64: Tayga (user space, TUN, простота) или Jool (kernel module, производительность).
3. Настроить DNS64 (Unbound или BIND). В примерах возьмём Unbound.
4. Настроить firewall и маршрутизацию.
5. Проверить синтез AAAA, прохождение трафика и MTU.

Шаг 1. Sysctl и базовая сеть

# IPv6 forwarding и важные ICMP для PMTU
sysctl -w net.ipv6.conf.all.forwarding=1
sysctl -w net.ipv6.conf.default.forwarding=1
sysctl -w net.ipv6.conf.all.accept_ra=0
sysctl -w net.ipv6.icmp.echo_ignore_all=0
sysctl -w net.ipv6.icmp.ratelimit=0

# Рекомендуем включить TCP Fast Open и ECN по необходимости
sysctl -w net.ipv4.tcp_ecn=1
sysctl -w net.ipv4.tcp_fastopen=3

# Сохранить в /etc/sysctl.d/99-nat64.conf c теми же параметрами и применить
sysctl --system

Не блокируйте ICMPv6 типы Packet Too Big, Parameter Problem, Time Exceeded — иначе получите «чёрные дыры» MTU. Если используется локальный фаервол, учтите это в правилах.

Шаг 2. DNS64 на Unbound

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

apt update
apt install unbound

# /etc/unbound/unbound.conf.d/dns64.conf
server:
  interface: 127.0.0.1
  interface: ::1
  access-control: 127.0.0.0/8 allow
  access-control: ::1 allow
  do-ip6: yes
  do-ip4: yes
  prefer-ip6: yes

  # Включаем DNS64
  dns64-prefix: 64:ff9b::/96
  dns64-synthall: no

  # Рекомендуется валидация DNSSEC, но помните про возможные несовместимости с DNS64
  val-clean-additional: yes
  harden-dnssec-stripped: yes

# При необходимости добавьте forward-zone к вашим upstream‑резолверам

systemctl enable --now unbound

# Направьте локальный резолвинг через Unbound
resolvectl status
resolvectl dns lo ::1 127.0.0.1
resolvectl default-route lo yes

Если у вас централизованный резолвер для множества узлов, включите dns64-prefix на нём и раздайте адрес резолвера через DHCPv6, RA или статически.

Шаг 3А. NAT64 на Tayga (просто и понятно)

Tayga — пользовательский демон, работающий через TUN‑интерфейс. Он преобразует IPv6 в «внутренний» IPv4‑пул, а затем вам нужен SNAT, чтобы выйти в интернет через публичный IPv4 хоста.

apt install tayga

# /etc/tayga.conf
# Создаст TUN-интерфейс nat64
 tun-device nat64
 # Внутренний IPv4 адрес интерфейса tayga
 ipv4-addr 192.168.255.1
 # Пул для динамического назначения исходящих IPv4
 dynamic-pool 192.168.255.0/24
 # Префикс NAT64 (WKP)
 prefix 64:ff9b::/96
 # Директория состояния
 data-dir /var/spool/tayga

systemctl enable --now tayga

# Поднимем интерфейс и маршруты
ip link set nat64 up
ip addr add 192.168.255.1/24 dev nat64
ip -6 route add 64:ff9b::/96 dev nat64

SNAT на публичный IPv4:

# Определите внешний интерфейс, например eth0, и публичный IPv4, например 203.0.113.10
iptables -t nat -A POSTROUTING -s 192.168.255.0/24 -o eth0 -j SNAT --to-source 203.0.113.10

# Разрешите форвардинг
iptables -A FORWARD -i nat64 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o nat64 -m state --state ESTABLISHED,RELATED -j ACCEPT

Теперь IPv6‑клиент, достигший адреса в 64:ff9b::/96, попадёт в Tayga, будет преобразован к адресу из 192.168.255.0/24, а затем уйдёт в интернет с вашего публичного IPv4.

Шаг 3Б. NAT64 на Jool (производительно и нативно)

Jool — это набор модулей ядра для NAT64 и SIIT. Он работает быстрее за счёт отсутствия TUN‑копирования и умеет тонко управлять пулами адресов. Для исходящих соединений достаточно NAT64 с пулом публичных IPv4, назначенных хосту.

apt install jool-dkms jool-tools

# Добавим инстанс NAT64 со стандартным префиксом
jool instance add "nat64 v4v6" --netfilter --pool6 64:ff9b::/96

# Укажем пул источников IPv4, которыми владеет хост (обычно один публичный IPv4)
jool -i "nat64 v4v6" pool4 add --tcp --udp 203.0.113.10

# Проверим конфигурацию
jool -i "nat64 v4v6" instance display
jool -i "nat64 v4v6" pool4 display

Маршрутизация префикса на хост с Jool:

ip -6 route add 64:ff9b::/96 dev lo

Если этот узел — же и клиенты, маршрут на lo корректен: пакеты попадут в стек, перехватятся Jool и уйдут в IPv4. Если обслуживаете другие машины, раздайте маршрут на этот префикс через динамическую маршрутизацию или статически на L3‑шлюзах.

Форвардинг и минимальные правила:

sysctl -w net.ipv6.conf.all.forwarding=1
sysctl -w net.ipv4.ip_forward=1

# Разрешим ESTABLISHED/RELATED и исходящие
nft add table inet filter
nft add chain inet filter forward { type filter hook forward priority 0; }
nft add rule inet filter forward ct state established,related accept
nft add rule inet filter forward ip6 daddr 64:ff9b::/96 accept

Преимущество Jool: не нужен промежуточный частный IPv4‑пул и дополнительный SNAT — NAT64 сразу использует публичный IPv4 из pool4.

Шаг 4. Тестирование DNS64 и NAT64

Проверим синтетические AAAA на домене, где есть только A:

dig AAAA ipv4only.arpa @::1 +short

Должны увидеть адреса типа 64:ff9b::c000:00aa. Проверим пинг и curl через IPv6:

ping6 -c 3 64:ff9b::c000:00aa
curl -6 -I http://ipv4only.arpa

Если вы включили DNS64 централизованно и на клиентах прописан этот резолвер, тестируйте просто curl к реальному IPv4‑only ресурсу — стек сам использует AAAA, сгенерированное резолвером.

Маршрутизация клиентов и варианты топологий

Есть три распространённых сценария:

• Локальный: NAT64/DNS64 на том же VDS, что и приложение. Подходит для единичных серверов. Маршрут 64:ff9b::/96 на lo или локальный интерфейс, DNS64 — localhost.
• Граничный шлюз: Отдельный VDS выступает NAT64/DNS64 для сегмента. Раздаёте маршрут на префикс через RA или динамический протокол, DNS64 — адрес шлюза.
• Через туннель: Сервера подключаются к шлюзу WireGuard/IPsec по IPv6, маршрут на 64:ff9b::/96 указывает в туннель. Удобно, если VDS‑клиенты в разных локациях.

Ключевое: у клиента должен быть маршрут на префикс DNS64 и доступ к DNS64‑резолверу. В большинстве случаев достаточно статического маршрута и настройки resolv.conf к резолверу.

Производительность и выбор между Tayga и Jool

• Tayga: быстрый старт, минимум движущихся частей. Узкое место — копирование пакетов через TUN и дополнительный SNAT; приемлемо для сотен Мбит/с.
• Jool: модуль ядра, высокая пропускная способность и меньше накладных расходов. Гибкое управление пулами, counters и статистика. Выбор для высоких нагрузок.

На загруженных узлах добавьте базовые тюнинги: включите GRO/TSO там, где допустимо, держите MTU в цепочке согласованной, следите за conntrack и увеличьте таблицу, если много коротких соединений.

sysctl -w net.netfilter.nf_conntrack_max=524288
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=7200

Firewall и ICMPv6: не ломайте PMTU

Чаще всего проблемы «всё работает, кроме больших ответов» связаны с фильтрацией ICMPv6. Разрешите:

• Type 2 (Packet Too Big)
• Type 1 (Destination Unreachable)
• Type 3 (Time Exceeded)
• Echo Request/Reply для диагностики

nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0; }
nft add rule inet filter input meta l4proto icmpv6 icmpv6 type { destination-unreachable, packet-too-big, time-exceeded, parameter-problem } accept
nft add rule inet filter input meta l4proto icmpv6 icmpv6 type { echo-request, echo-reply } accept

NAT64 решает исходящие соединения из IPv6‑сегмента к IPv4. Для входящего трафика с IPv4 потребуются дополнительные механизмы (прокси, двустек или SIIT).

Отладка и мониторинг

• Проверка синтеза: dig AAAA имя, ожидайте адрес в 64:ff9b::/96.
• Jool: jool -i "nat64 v4v6" stats display, jool ... global display.
• Tayga: логи systemd, счётчики интерфейса nat64, iptables counters по SNAT‑правилу.
• Трассировка: tcpdump -i eth0 host 203.0.113.10 и tcpdump -i any ip6 and net 64:ff9b::/96.

Дополнительно укрепите сервисы и юниты на хосте — пригодится руководство по жёсткой изоляции systemd на VDS.

Типичные подводные камни

• Литералы IPv4: приложения, в которых жёстко прописан IPv4‑адрес, обойдут DNS64. Используйте хостнеймы или встроенные CLAT‑механизмы на клиентах, если доступны.
• Протоколы с адресами в payload: FTP active, некоторые SIP‑диалекты — потребуют прокси/ALG на прикладном уровне.
• DNSSEC: возможны проблемы валидации при синтезе записей. Тестируйте критичные домены; при необходимости настройте исключения.
• MTU/ICMPv6: блокировка Packet Too Big ломает большие ответы. Не режьте ICMPv6.
• Входящие подключения из IPv4: NAT64 это не решает. Нужен обратный перевод (SIIT) и отдельный пул IPv4 либо фронт с двустеком/прокси.

Постепенное внедрение и откат

Не обязательно переводить всё сразу. Начните с одного VDS и локального DNS64, проверьте CI/CD, пакетные менеджеры, агенты мониторинга. Далее включайте DNS64 для отдельных подсетей или групп серверов. Держите возможность быстро переключить резолвер назад (TTL 60–300 секунд) и отключить маршрут на префикс, чтобы мгновенно обойти NAT64 при инциденте.

Расширенные варианты

• Собственный префикс DNS64: удобно для политики и фильтрации. Раздайте маршрут на префикс через IGP.
• Stateless SIIT (jool_siit): когда нужна симметрия адресов и высокая производительность в дата‑центре. Требует планирования адресного пространства.
• WireGuard‑шлюз: объедините разрозненные IPv6‑only сервера в виртуальный сегмент и предоставьте общий NAT64/DNS64.

Итоги

NAT64/DNS64 — практичный способ получить доступ к «IPv4‑мирам» из IPv6‑only инфраструктуры без тотальной переделки приложений. На VDS решение поднимается за час: Unbound с dns64-prefix, затем NAT64 на Tayga (минимум зависимостей) или Jool (максимум производительности). Правильно настроенная маршрутизация, разрешённые ICMPv6 и мониторинг закрывают 90% «граблей». С таким фундаментом можно уверенно двигаться к полностью IPv6‑среде, сохраняя совместимость там, где она ещё нужна.