Един 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 събитието даде в началото. Пазете този изход с записа за промяната, защото той е единственото доказателство, че адресът се държи уникално.

Подобни статии