Один клиент Windows держит 10.8.0.2 и работает, пока не изменится порядок загрузки; тогда тот же адрес сообщается как конфликт, хотя в клиенте ничего не изменилось. Второй хост в том же сбриженном сегменте претендует на то же значение, и машина, которая заканчивает настройку последней, обычно проигрывает. Оба считают, что адрес принадлежит им, и проигравший тихо перестаёт использовать адрес, который ему было велено использовать. Именно отношение к этому как к проблеме времени заставляет его возвращаться при каждой перезагрузке.

Прочитайте доказательства конфликта, прежде чем трогать мост

Windows сообщает о конфликте адреса вместе с аппаратным адресом другого претендента. Именно этот аппаратный адрес и есть полезный факт, потому что он соответствует одному интерфейсу на одном хосте, тогда как отображаемое имя события ничего не говорит о том, где находится дубликат. Запишите аппаратный адрес, прежде чем что-либо менять.

Обнаружение дубликатов на основе ARP опрашивает конкурирующих владельцев до использования адреса и продолжает наблюдать после. Поэтому хост, отсутствовавший во время настройки сети, может вызвать конфликт и час спустя. Опрос не является однократной проверкой при загрузке. Машина, появившаяся позже, может занять адрес, который спокойно использовался весь день, и именно поэтому сбой читается как гонка, а не как ошибка конфигурации.

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

Перечислите все заявки в сегменте

Сбриженная конфигурация TAP соединяет сегменты Ethernet, которые раньше были раздельными, поэтому адреса, уникальные внутри своих сетей, могут столкнуться, как только кадры начинают делить одно звено. Поэтому этот класс неисправностей существует в VPN и не существует в маршрутизируемых сетях, которые он заменил. Перечислите каждого возможного владельца, а не первого, кого вы подозреваете.

Пройдите список в этом порядке: адреса на каждом устройстве моста и его портах-участниках, пул OpenVPN и любое фиксированное назначение для клиента, а также любой сервер DHCP, охватывающий сбриженный сегмент. Затем сопоставьте аппаратный адрес из отчёта о конфликте с найденными интерфейсами.

ip -4 addr show | grep -E 'inet |^[0-9]+: '
bridge link show
ip neigh show dev br0

Пул и диапазон DHCP — это два владельца, о которых забывают. Напечатайте оба диапазона вместе и поищите пересечение, прежде чем делать что-либо ещё. Адрес моста, назначенный вручную, и пул, выдающий то же значение, рано или поздно столкнутся, и столкновение выглядит случайным, пока оба диапазона не напечатаны рядом.

Нумеруйте мосты только там, где им нужна идентичность

В обычном мосте хоста устройство моста несёт конфигурацию третьего уровня хоста, а участники Ethernet и TAP работают как порты. Дать каждому участнику собственный адрес или скопировать один сценарий настройки на несколько машин без изменения адреса — это путь, которым один сегмент обзаводится тремя владельцами одного значения. Участникам не нужны собственные идентичности, чтобы пересылать кадры. Им нужна ровно одна идентичность на хост, который должен быть доступен в этом сегменте.

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

Если адрес, который вы собираетесь удалить, — единственный путь в машину, то удаление его как эксперимента является самодельным простоем, а не диагностикой. Проверьте внешний путь, прежде чем что-либо тестировать.

Сделайте исправление устойчивым к перезагрузке

Изменение работающего интерфейса исправляет текущую загрузку и ничего больше. Всё, что создаёт адрес заново при запуске, вернёт конфликт при следующей перезагрузке, и вы заключите, что исправление не сработало, хотя на самом деле оно никогда не было постоянным. Запишите, какой файл вы изменили, чтобы следующая перезагрузка подтверждала решение, а не открывала сюрприз.

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

Зарезервируйте адреса моста внутри диапазона DHCP как исключения или перенесите их за его пределы. Резервирование, существующее только в таблице, не является исключением, и распределитель его не прочитает.

Докажите это при всех клиентах онлайн

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

Для прямого подтверждения проверьте наличие дублирующего владельца до назначения адреса, а после наблюдайте за таблицей соседей. Если ничто не отвечает на проверку и адрес остаётся уникально принадлежащим в течение полного цикла перезагрузки, конфликт решён, а не просто скрыт. Приведённые ниже команды выполняют обе проверки на устройстве моста. RFC 5227 описывает поведение проверки и объявления, которое применяют эти инструменты, и это источник, на который ссылаются, когда кто-то предлагает вместо этого отключить обнаружение.

arping -D -I br0 10.8.0.2
ip neigh show dev br0 | grep 10.8.0.2

Проверка без ответа — ожидаемый результат в чистом сегменте. Проверка, вызвавшая ответ, даёт вам аппаратный адрес оставшегося владельца — то же доказательство, которое событие Windows дало в начале. Храните этот вывод вместе с записью об изменении, потому что это единственное доказательство того, что адрес удерживается уникально.

Похожие статьи