IPv6 на VDS: SLAAC vs DHCPv6, префиксы и корректные маршруты

Инструкции
24 окт, 2025
Время на чтение: ~13 мин
Автор: AI (GPT 5)

Искусственный интеллект

Данная статья была создана с использованием искусственного интеллекта (GTP-5). Пожалуйста, имейте в виду, что текст может содержать неточности или ошибки.

IPv6 перестал быть экзотикой: крупные сети уже давно в проде, а VDS‑провайдеры выдают адреса и даже целые префиксы. Но у Linux‑админа сразу возникает ряд вопросов: где берётся адрес — через SLAAC или DHCPv6, что означают Router Advertisements, как выглядит «правильный» маршрут по умолчанию в мире с ссылочными адресами шлюза, и что делать, если дали /64 или /56 для своих подсетей? Разбираемся детально и с примерами, чтобы ваш VDS уверенно ходил по IPv6 и раздавал сеть контейнерам и ВМ.

Как провайдеры выдают IPv6 на VDS

На практике встречаются несколько моделей выдачи IPv6 в облаках и дата‑центрах:

Единичный адрес /128 и шлюз с link‑local адресом (fe80::/10). Часто без RA, статически или через DHCPv6 (IA-NA). Маршрут по умолчанию строится через link‑local шлюза на том же интерфейсе.
Адрес /64 «на интерфейс» через SLAAC с RA (Router Advertisements). Можно получить адреса EUI‑64 или стабильные RFC7217, иногда вместе с подсказками MTU и DNS.
Распределённый префикс (например, /64 или /56), «маршрутизируемый» к вашему основному адресу. Вы дальше разбиваете его и раздаёте в свои подсети (бридж, VRF, маршрутизируемые сети для LXD/Docker/KVM).
DHCPv6-PD (Prefix Delegation): сервер получает делегированный префикс (IA-PD), а затем использует его для внутренних сетей, публикуя RA или статические адреса вниз по иерархии.

Ключевое отличие от IPv4 — отсутствие ARP и наличие Neighbor Discovery, из‑за чего ICMPv6 жизненно необходим. Плюс активное использование link‑local адресов для next‑hop (шлюза) и важность корректного выбора исходного адреса при исходящих соединениях.

SLAAC и DHCPv6: что выбрать на сервере

SLAAC (Stateless Address Autoconfiguration) позволяет хосту собрать адрес на основе префикса из RA (Router Advertisements). Для серверов это удобно, если:

провайдер стабильно шлёт RA;
вам хватает одного или нескольких автоматически собранных адресов;
DNS можно получить из RA (RDNSS) или прописать вручную.

DHCPv6 нужен, когда провайдер явно требует его для получения адреса (IA-NA) и/или дополнений (DNS, NTP), а также для Prefix Delegation (IA-PD), если вы хотите получить собственный префикс и маршрутизировать его дальше.

RA несут флаги: M (Managed) — использовать DHCPv6 для адресов; O (Other) — использовать DHCPv6 для «других» параметров (например, DNS). Некоторые провайдеры шлют RA только для маршрута по умолчанию, а адрес выдают через DHCPv6.

На Linux есть важный нюанс: если вы включаете IPv6‑маршрутизацию (forwarding=1), ядро по умолчанию перестаёт принимать RA. Для граничных серверов, которые ещё и принимают RA, ставят accept_ra=2 на нужном интерфейсе.

Плюсы и минусы

SLAAC: минимум настройки, автоматический маршрут по умолчанию, MTU из RA, быстрый подъём. Но контроль адресов ограничен, DNS через RA зависит от стека и менеджера сети.
DHCPv6-IA-NA: предсказуемый адрес из лиза, удобно для учёта. Зависимость от DHCPv6 сервера.
DHCPv6-PD: получаете префикс и свободу маршрутизации. Потребуются собственные RA/ND внутри и аккуратная фильтрация ICMPv6.

Маршрут по умолчанию IPv6 через link‑local шлюз на интерфейсе

Маршрутизация и «правильные» маршруты в IPv6

Типичный маршрут по умолчанию в IPv6 выглядит так: ::/0 через link‑local адрес шлюза на конкретном интерфейсе. Пример командой:

ip -6 route add default via fe80::1 dev eth0

Это нормально: link‑local «виден» только на локальном канале, поэтому нужно указать интерфейс. Если вам выдали /128 на интерфейс, это тоже корректно — адрес хоста, а маршрут по умолчанию указывает, куда отправлять остальной трафик. Для исходящих подключений не забудьте выбрать корректный исходный адрес, если у вас их несколько (policy routing по источнику).

Когда у вас есть «маршрутизируемый» префикс (например, /64), провайдер обычно «указал» на ваш основной адрес как на next‑hop для всего префикса. Дальше вы объявляете сеть на внутреннем интерфейсе и включаете форвардинг:

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

Маршрут в сторону вашей внутренней L2/L3 сети:

ip -6 addr add 2001:db8:100::1/64 dev br0
ip -6 route add 2001:db8:100::/64 dev br0

Если провайдер объявил ваш префикс «на‑линке» (редко, но бывает), может потребоваться Proxy NDP на внешнем интерфейсе, чтобы отвечать за адреса из префикса. В Linux это делается через proxy_ndp или ndppd. Чаще всего префикс именно маршрутизируемый, и Proxy NDP не нужен.

Примеры конфигураций

systemd-networkd: SLAAC с RA

# /etc/systemd/network/10-eth0.network
[Match]
Name=eth0

[Network]
IPv6AcceptRA=yes
IPv6PrivacyExtensions=no
DHCP=no

[Address]
# При необходимости можно добавить стабильный адрес из выделенного префикса
# Address=2001:db8:1234::10/64

В этом варианте адрес и маршрут приходят из RA. Если включён форвардинг, добавьте на интерфейс:

# /etc/sysctl.d/99-ipv6.conf
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.eth0.accept_ra=2

systemd-networkd: DHCPv6 (адрес) и RA (маршрут)

# /etc/systemd/network/10-eth0.network
[Match]
Name=eth0

[Network]
DHCP=ipv6
IPv6AcceptRA=yes

[DHCPv6]
WithoutRA=solicit

Подходит, если провайдер выдаёт адрес по DHCPv6, а маршрут — из RA.

systemd-networkd: DHCPv6-PD и раздача префикса

# /etc/systemd/network/10-eth0.network
[Match]
Name=eth0

[Network]
DHCP=ipv6
IPv6AcceptRA=yes

[DHCPv6]
PrefixDelegationHint=2001:db8:200::/56
WithoutRA=solicit

# /etc/systemd/network/20-br0.netdev
[NetDev]
Name=br0
Kind=bridge

# /etc/systemd/network/21-br0.network
[Match]
Name=br0

[Network]
IPv6SendRA=yes

[IPv6SendRA]
Managed=no
OtherInformation=no

[IPv6Prefix]
Assign=yes
# networkd сам нарежет из IA-PD префикс на br0

В этом сценарии networkd запросит PD у провайдера и автоматически назначит часть префикса на br0, одновременно шлёт RA во внутреннюю сеть.

Netplan (Ubuntu): SLAAC и статический DNS

network:
  version: 2
  ethernets:
    eth0:
      dhcp6: no
      accept-ra: true
      addresses: []
      nameservers:
        addresses: [2001:4860:4860::8888, 2606:4700:4700::1111]

NetworkManager (nmcli): DHCPv6 и ручной маршрут по умолчанию

nmcli con mod eth0 ipv6.method dhcp
nmcli con mod eth0 ipv6.never-default no
nmcli con up eth0

Если RA нет, но известен link‑local шлюз, маршрут можно прописать через nmcli:

nmcli con mod eth0 +ipv6.routes "::/0 fe80::1 dev eth0"

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

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

Подробнее

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

Базовые проверки адресов и маршрутов:

ip -6 addr show dev eth0
ip -6 route show dev eth0

Тест канала и MTU:

ping -6 -c 3 2606:4700:4700::1111
ping -6 -M do -s 1400 2606:4700:4700::1111

Смотрим RA и ICMPv6:

tcpdump -i eth0 icmp6
rdisc6 eth0

DHCPv6‑клиент (в зависимости от дистрибутива):

journalctl -u systemd-networkd -f
journalctl -u NetworkManager -f

Пример RA и логов DHCPv6 в терминале для диагностики

ICMPv6 и firewall: не блокируйте себе сеть

ICMPv6 — не «дополнение», а часть протокола: без него не работает Path MTU Discovery, Neighbor Discovery, SLAAC и многие другие механизмы. Базовый набор для nftables:

nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0; }
nft add chain inet filter forward { type filter hook forward priority 0; }
nft add rule inet filter input meta l4proto ipv6-icmp accept
nft add rule inet filter forward meta l4proto ipv6-icmp accept

Если нужно детализировать типы, можно разрешить как минимум: echo-request/echo-reply, neighbor-solicitation/neighbor-advertisement, router-advertisement, packet-too-big, time-exceeded, parameter-problem. См. также практическую настройку AAAA и IPv6 в Nginx/Apache и firewall.

Выбор исходного адреса и policy routing

Когда на интерфейсе несколько IPv6‑адресов (например, SLAAC‑адрес и статический из вашего префикса), убедитесь, что исходящий трафик уходит с нужного источника. Иначе внешние сервисы увидят «не тот» адрес. Решения:

Явно указывать исходный адрес в демонах/конфигурации веб‑сервера, почтовика и т.д.
Использовать policy routing по источнику: таблицы маршрутизации и ip -6 rule.
Убрать лишние автоадреса (например, запретить privacy‑адреса на сервере: net.ipv6.conf.all.use_tempaddr=0).

Типичные проблемы и решения

Включили forwarding — пропали маршруты из RA. Решение: accept_ra=2 на нужном интерфейсе.
Блокируете ICMPv6 — нет соседей, не работает PMTU, соединения «подвисают». Разрешите необходимые типы.
Маршрут по умолчанию не поднимается без интерфейса. В IPv6 для link‑local next‑hop всегда указывайте интерфейс.
Выдан /128 и нет трафика. Проверьте, что есть default через link‑local шлюза на правильном интерфейсе.
Получили префикс, но внутренние узлы «не видят» мир. Включите forwarding=1, раздавайте RA во внутреннюю сеть, проверьте правильность маршрута к префиксу.
Несколько дефолтных маршрутов с разными метриками вызывают флап. Оставьте один «основной» или настройте policy routing.
MTU. Если провайдер объявляет MTU в RA — доверяйте ему. При нестабильном канале проверьте «packet-too-big» и адаптируйте MTU.

Контейнеры и ВМ: как раздать IPv6 из префикса

Имея маршрутизируемый префикс, вариантов два:

Маршрутизируемый L3: внутренняя сеть с /64 на бридже/виртуальном свиче, RA через radvd/dnsmasq или через IPv6SendRA в systemd-networkd. Гостям назначаются адреса из этого /64, а сервер форвардит в интернет.
Бридж с L2 до гостя и адрес у гостя из внешнего /64 — на VDS это редко допустимо, так как провайдер обычно не пропускает L2 RA/ND из ваших ВМ наружу.

Пример минимальной раздачи RA во внутреннюю сеть с dnsmasq:

# /etc/dnsmasq.d/ipv6.conf
interface=br0
enable-ra
ra-param=br0,10,30
dhcp-range=::100,::1ff,constructor:br0,ra-names,64,24h

Для Docker можно включить IPv6 и указать префикс вашей внутренней сети (не глобальный внешний, если вы не планируете L2‑бридж наружу):

# /etc/docker/daemon.json
{
  "ipv6": true,
  "fixed-cidr-v6": "fd00:dead:beef::/64"
}

Если хотите раздавать глобальный префикс контейнерам, лучше создать выделенную L3‑сеть и публиковать RA туда, а не включать контейнеры в «внешний» L2.

Адресация: стабильные адреса vs privacy

На серверах обычно используют стабильные адреса (RFC7217), чтобы адрес не менялся при перезапусках и сохранялся в ACL/мониторинге. В Linux это настраивается через addr_gen_mode, а privacy‑адреса отключают:

sysctl -w net.ipv6.conf.all.use_tempaddr=0
sysctl -w net.ipv6.conf.default.use_tempaddr=0

Если используется SLAAC и вы хотите предсказуемый адрес, добавьте статический адрес из вашего /64 вручную и используйте его как исходный для сервисов.

Чеклист «завёл IPv6 на VDS»

Понимаю модель выдачи: /128 или /64 на интерфейс, маршрутизируемый префикс, DHCPv6-IA-NA или DHCPv6-PD.
Выбран метод адресации: SLAAC, DHCPv6 или статический, с учётом флагов RA.
Маршрут по умолчанию через link‑local и правильный интерфейс присутствует.
ICMPv6 не заблокирован: ND, RA, PTB и базовые типы разрешены.
Если есть префикс — включён форвардинг, RA во внутренние сети, маршруты расставлены.
Исходный адрес сервисов предсказуем, privacy‑адреса отключены при необходимости.
Проверены MTU и Path MTU Discovery, отсутствуют «подвисания» соединений.
Журналы systemd-networkd/NetworkManager чисты, RA и DHCPv6 отрабатывают стабильно.

Итоги

Грамотно настроенный IPv6 на VDS — это не только «ещё один адрес», а возможность упростить маршрутизацию, расширить подсети для контейнеров/ВМ и повысить отказоустойчивость без NAT. Понимание роли SLAAC и DHCPv6, корректной работы RA, важности ICMPv6 и правильной развесовки маршрутов избавит от множества «странных» симптомов: от обрывов соединений до неработающих контейнерных сетей. Двигайтесь от модели выдачи провайдера, не блокируйте базовые механизмы IPv6 и держите под контролем исходные адреса — и стек будет работать так же предсказуемо, как и в старом добром IPv4, только с ощутимо большим адресным пространством.

Поделиться статьей