Два власники, одна адреса: дублікати IP на мосту TAP

Один клієнт 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 дала на початку. Зберігайте цей вивід разом із записом про зміну, бо це єдиний доказ того, що адреса утримується унікально.