Debian/Ubuntu: duplicate address detected, DAD failed IPv6 — причины и исправление

Сообщения вида duplicate address detected, DAD failed или dadfailed в Debian и Ubuntu обычно появляются в момент назначения IPv6-адреса интерфейсу. Система проверяет, уникален ли адрес в локальном L2-сегменте, и если получает ответ, который трактуется как конфликт, помечает адрес как проблемный.

На практике это означает, что интерфейс может остаться без рабочего глобального IPv6, приложение не будет слушать нужный адрес, а маршрутизация станет вести себя нестабильно. Снаружи это часто выглядит как «IPv6 сломан», хотя корень проблемы обычно гораздо конкретнее.

Чаще всего виноват один из сценариев: реальный дубль статического адреса, клонированный образ ВМ с одинаковыми сетевыми параметрами, повторное назначение адреса разными средствами, ошибки в bridge-схеме, особенности виртуальной сети провайдера или неудачная комбинация SLAAC и ручной настройки.

Отдельная проблема в том, что администраторы иногда пытаются лечить всё через disable_ipv6. Это может временно убрать симптом, но почти никогда не устраняет первопричину. Гораздо полезнее понять, кто именно назначает адрес и на каком этапе ломается DAD.

Ниже разберём, что означает DAD, как диагностировать сбой и как аккуратно исправить его в netplan, systemd-networkd, NetworkManager и через параметры ядра.

Что такое DAD и почему IPv6 может не подняться

DAD, или Duplicate Address Detection, — это штатный механизм IPv6, который проверяет уникальность адреса перед тем, как интерфейс начнёт использовать его в обычном режиме. Когда ядро получает или назначает адрес, оно отправляет Neighbor Solicitation и ждёт, не ответит ли кто-то, кто уже использует этот IPv6.

Если ответа нет, адрес считается уникальным и становится рабочим. Если ответ есть, ядро помечает адрес как конфликтный. В выводе ip addr в этот момент можно увидеть признаки tentative или dadfailed.

DAD проверяет уникальность адреса только в пределах локального канального сегмента. Это не глобальная проверка маршрутизируемости, а защита от конфликта соседних узлов на одном L2.

Поэтому ошибка возможна не только на физических серверах, но и в виртуальной среде. На VDS или облачной ВМ она встречается при кривом шаблоне инстанса, неверно прописанном статическом IPv6, проблемах с NDP proxy или особенностях виртуального коммутатора.

Как проявляется проблема

Обычно администратор замечает её по журналу ядра, systemd или по тому, что IPv6 вроде бы прописан, но не работает. Особенно неприятны случаи, когда после перезагрузки сеть то поднимается, то нет.

• в journalctl -k есть строки duplicate address detected;
• в ip -6 addr адрес отмечен как dadfailed;
• сервис должен слушать dual stack, но фактически работает только по IPv4;
• адрес есть в конфиге, но не отвечает извне;
• после рестарта интерфейса поведение меняется непредсказуемо.

Базовый набор команд для первой проверки:

ip -6 addr show
ip -6 route show
journalctl -k -b | grep -Ei 'ipv6|dad|duplicate'
journalctl -u systemd-networkd -b
nmcli device show

Если у вас Ubuntu Server с netplan, помните, что это только слой описания конфигурации. Реально интерфейсом управляет systemd-networkd или NetworkManager, поэтому всегда проверяйте и YAML, и активный backend.

Дальше важно не прыгать сразу к отключению IPv6, а отделить реальный конфликт адреса от ошибки конфигурации или особенностей виртуальной инфраструктуры.

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

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

Подробнее

Основные причины duplicate address detected в Debian и Ubuntu

Реальный конфликт статического IPv6

Самый очевидный сценарий: один и тот же IPv6 вручную назначен двум хостам. Обычно это происходит после копирования конфигов между серверами, ручного развёртывания ВМ из шаблона или ошибок при распределении адресов в пределах подсети.

Если вы используете статический IPv6, сначала проверьте, что адрес действительно выдан именно этому серверу и не используется другой машиной, контейнером, балансировщиком или bridge-интерфейсом.

Клонированный образ и совпавшая генерация адресов

Если машина развёрнута из золотого образа, причина может быть в одинаковых идентификаторах, влияющих на генерацию IPv6. Это особенно заметно в сценариях со stable privacy addressing или плохо подготовленными шаблонами cloud-init.

На практике стоит проверить /etc/machine-id, настройки cloud-init, параметры SLAAC и все артефакты, которые могли перекочевать в новый инстанс без регенерации.

Повторное назначение адреса разными средствами

Одна из самых частых ошибок в Ubuntu — IPv6 прописан сразу в нескольких местах: в netplan, в файлах systemd-networkd, в профиле NetworkManager или ещё приходит через Router Advertisement. Адрес формально один, но логика управления сетью уже конфликтует.

Если вам нужно лучше понять, как сочетаются SLAAC, DHCPv6 и маршрутизация в IPv6-сетях, посмотрите материал про SLAAC, DHCPv6 и маршрутизацию IPv6. Там как раз разобраны сценарии, где автоконфигурация и ручные параметры мешают друг другу.

Проблемы с bridge, контейнерами и виртуальными интерфейсами

На хостах с Docker, LXC/LXD, Incus, libvirt, bridge-сетями и VLAN DAD иногда падает не из-за «чужого» узла, а из-за локальной схемы. Например, один и тот же IPv6 назначен и на bridge, и на подчинённый интерфейс, либо NDP-трафик возвращается назад нетипичным образом.

В таких случаях нужно проверить, на каком именно интерфейсе висит адрес, нет ли дублирования между bridge и slave и не поднимает ли контейнерная платформа похожую адресацию самостоятельно.

Сетевая особенность провайдера или виртуальной платформы

Иногда конфиг на вашей стороне корректный, но DAD всё равно стабильно проваливается. Причина может быть в особенностях виртуального свитча, антиспуфинге, NDP proxy, неверной сегментации или ошибке в облачной сети.

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

Пошаговая диагностика

Чтобы не отключать IPv6 наугад, удобнее пройтись по короткому плану. Он позволяет быстро понять, конфликт реальный или инфраструктурный.

1. Посмотреть состояние адреса

ip -6 addr show dev eth0

Если у адреса есть флаг dadfailed, проблема подтверждена. Если адрес висит как tentative, проверка ещё идёт или застряла в промежуточном состоянии.

2. Понять, кто управляет сетью

networkctl status eth0
systemctl is-active systemd-networkd
systemctl is-active NetworkManager

На Ubuntu Desktop обычно работает NetworkManager. На серверах Debian и Ubuntu чаще встречается systemd-networkd или ifupdown. Если есть netplan, обязательно проверьте значение renderer.

3. Сравнить конфиг с фактическим состоянием

Важно убедиться, что один и тот же IPv6 не назначается дважды разными механизмами и что интерфейс получает именно тот адрес, который вы ожидаете.

grep -R "address\|addresses\|gateway6\|dhcp6\|accept-ra" /etc/netplan /etc/systemd/network /etc/network 2>/dev/null

4. Проверить журнал ядра

journalctl -k -b | grep -Ei 'eth0|ens|enp|ipv6|dad|duplicate|ndisc'

В журнале обычно видно, какой адрес вызвал конфликт и на каком интерфейсе это произошло.

5. Посмотреть текущие sysctl-параметры

sysctl net.ipv6.conf.all.accept_dad
sysctl net.ipv6.conf.default.accept_dad
sysctl net.ipv6.conf.eth0.accept_dad
sysctl net.ipv6.conf.all.disable_ipv6
sysctl net.ipv6.conf.eth0.disable_ipv6

Здесь важно не только значение, но и источник. Его могли задать в /etc/sysctl.conf, в файлах /etc/sysctl.d/, через cloud-init или сторонний bootstrap-скрипт.

Что означает accept_dad и когда его менять

Параметр accept_dad определяет, как интерфейс выполняет Duplicate Address Detection. В большинстве случаев значение по умолчанию менять не нужно: DAD полезен и защищает от реальных конфликтов.

Трогать accept_dad имеет смысл только в узких сценариях: например, при доказанном ложном срабатывании в специфической виртуальной сети или когда вы временно обходите проблему в контролируемом сегменте до исправления сетевой схемы.

Проверить текущее значение:

cat /proc/sys/net/ipv6/conf/eth0/accept_dad

Временно изменить для интерфейса:

sysctl -w net.ipv6.conf.eth0.accept_dad=0

Сделать изменение постоянным:

printf 'net.ipv6.conf.eth0.accept_dad = 0
' > /etc/sysctl.d/90-ipv6-dad.conf
sysctl --system

Отключение DAD — это обходной путь, а не универсальное исправление. Если адрес реально занят, вы просто заставите систему использовать конфликтный IPv6.

Для production-систем правильнее сначала доказать, что конфликт ложный: проверить соседние узлы, bridge-схему, шаблоны ВМ, настройки гипервизора и корректность NDP в вашем сегменте.

Когда уместно использовать disable_ipv6

Параметр disable_ipv6 отключает стек IPv6 на интерфейсе или во всей системе. Это крайняя мера. Если приложение, DNS, firewall или внешний сервис ожидают dual stack, вы можете получить новые проблемы поверх исходной.

Для быстрой диагностики временное отключение допустимо:

sysctl -w net.ipv6.conf.eth0.disable_ipv6=1

Но постоянно отключать IPv6 разумно только тогда, когда он действительно не используется в проекте и попал в конфиг случайно. Если же адресация нужна, лечить стоит именно DAD, а не весь стек.

Исправление в netplan

В Ubuntu ошибка часто проявляется в конфигурациях netplan. Основные причины здесь — неправильный renderer, одновременное использование ручного адреса и RA, а также дублирование источников конфигурации.

Пример статической схемы без лишней автоконфигурации:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: false
      dhcp6: false
      accept-ra: false
      addresses:
        - 203.0.113.10/24
        - 2001:db8:100::10/64
      routes:
        - to: default
          via: 203.0.113.1
        - to: ::/0
          via: 2001:db8:100::1
      nameservers:
        addresses:
          - 2001:4860:4860::8888
          - 1.1.1.1

Если вам выдан статический IPv6, часто полезно отключить accept-ra, чтобы система не пыталась параллельно получить дополнительную конфигурацию через Router Advertisement.

После изменения конфига:

netplan generate
netplan try
netplan apply

На удалённом сервере лучше сначала запускать netplan try, чтобы не потерять доступ по SSH из-за ошибки в YAML.

Если вы разворачиваете проекты на сервере, где нужна гибкая ручная настройка сети и изоляция окружения, такие задачи обычно удобнее решать на VDS с полным контролем над сетевым стеком.

Исправление в systemd-networkd

Если backend — systemd-networkd, проверьте файлы в /etc/systemd/network/. Главный принцип тот же: не смешивать несколько способов назначения адреса без необходимости.

Пример аккуратного конфига:

[Match]
Name=eth0

[Network]
Address=203.0.113.10/24
Gateway=203.0.113.1
Address=2001:db8:100::10/64
Gateway=2001:db8:100::1
IPv6AcceptRA=no
DHCP=no

[IPv6AcceptRA]
UseDNS=no

Перезагрузка сети и проверка:

networkctl reload
systemctl restart systemd-networkd
networkctl status eth0
ip -6 addr show dev eth0

Если после перезапуска адрес сразу получает dadfailed, а конфиг точно уникален, уже имеет смысл проверять соседние ВМ, локальные мосты и сетевую сторону платформы.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Исправление в NetworkManager

На рабочих станциях и части серверов Ubuntu IPv6 управляется через NetworkManager. Здесь полезно смотреть не только GUI, но и реальные параметры профиля через nmcli.

Список подключений:

nmcli connection show

Посмотреть IPv6-настройки профиля:

nmcli connection show "Wired connection 1" | grep ipv6

Пример ручной настройки статического IPv6:

nmcli connection modify "Wired connection 1" ipv6.method manual
nmcli connection modify "Wired connection 1" ipv6.addresses "2001:db8:100::10/64"
nmcli connection modify "Wired connection 1" ipv6.gateway "2001:db8:100::1"
nmcli connection modify "Wired connection 1" ipv6.dns "2001:4860:4860::8888"
nmcli connection modify "Wired connection 1" ipv6.addr-gen-mode stable-privacy

Если IPv6 для конкретного профиля не нужен:

nmcli connection modify "Wired connection 1" ipv6.method disabled

Применить изменения:

nmcli connection down "Wired connection 1"
nmcli connection up "Wired connection 1"

Не оставляйте одновременно ручной адрес и автоматическую выдачу там, где это не требуется. Иначе один IPv6 может быть рабочим, а второй уйдёт в dadfailed и создаст ощущение общей сетевой поломки.

Если проблема появилась после клонирования ВМ

Это очень частый сценарий для Debian и Ubuntu. Вы делаете шаблон, разворачиваете несколько инстансов, а затем замечаете, что часть машин теряет рабочий IPv6 или получает конфликт на старте.

Проверьте следующее:

• у каждой ВМ должен быть уникальный /etc/machine-id;
• cloud-init не должен назначать один и тот же статический IPv6 всем инстансам;
• в шаблоне не должно быть жёстко заданного адреса, если он должен выдаваться индивидуально;
• после клонирования нужно регенерировать идентификаторы, если от них зависит формирование IPv6.

На этапе подготовки золотого образа полезно очищать временные состояния и уникальные идентификаторы. Это снижает риск не только IPv6-конфликтов, но и побочных проблем в DHCP, логах и системах инвентаризации.

Как отличить ложный DAD от реального конфликта

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

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

Что помогает различить эти сценарии:

• временная смена IPv6 на другой адрес из выделенного диапазона;
• проверка адреса на соседних хостах, контейнерах и bridge-интерфейсах;
• сравнение поведения в другой VLAN, на другой ВМ или другом гипервизоре;
• анализ ICMPv6-трафика во время DAD.

Для просмотра трафика подойдёт:

tcpdump -ni eth0 icmp6

Если видно ответы на DAD от другого узла, это сильный признак реального конфликта. Если же вы наблюдаете отражение собственного трафика или странную реакцию виртуальной сети, проблема, скорее всего, на стороне платформы.

Чего лучше не делать

• Не отключайте весь IPv6 через disable_ipv6, если конфликт относится только к одному адресу или одному интерфейсу.
• Не ставьте accept_dad=0 глобально на все интерфейсы без понимания топологии.
• Не смешивайте на одном интерфейсе netplan, ручные файлы networkd и настройки NetworkManager.
• Не назначайте один и тот же IPv6 одновременно на bridge и на подчинённый физический интерфейс.
• Не клонируйте ВМ без очистки уникальных идентификаторов и сетевых артефактов шаблона.

Краткий рабочий алгоритм

1. Проверьте ip -6 addr и подтвердите наличие dadfailed.
2. Посмотрите журнал ядра и определите интерфейс и конкретный адрес, на котором падает DAD.
3. Поймите, кто управляет сетью: netplan, systemd-networkd, NetworkManager или ifupdown.
4. Уберите задвоение адресации: ручной адрес плюс RA, bridge плюс slave, шаблон плюс cloud-init.
5. Проверьте, не использует ли адрес другая машина или контейнер.
6. Если среда виртуальная и конфликт ложный, точечно рассмотрите изменение accept_dad на нужном интерфейсе.
7. Полностью отключайте IPv6 только как осознанное архитектурное решение.

Итог

Ошибка DAD failed IPv6 в Debian и Ubuntu — это не «каприз системы», а защитная реакция ядра на подозрение в конфликте адреса. В нормальной сети этот механизм полезен и должен оставаться включённым.

Почти всегда у проблемы есть конкретная причина: дублирующийся статический IPv6, лишняя автоконфигурация, последствия клонирования ВМ, неправильная bridge-схема или особенности виртуальной сети. Поэтому главная задача — не выключить IPv6 как можно быстрее, а понять, кто именно назначает адрес и почему DAD считает его занятым.

Если действовать как при обычном сетевом инциденте — проверить backend, конфиг, журнал, соседние интерфейсы и реальную адресацию, — проблема обычно находится довольно быстро и исправляется без побочных эффектов для остальной инфраструктуры.