Два сопственици, една адреса: дупликат 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 дејствуваат како порти. Давање на секој член сопствена адреса, или копирање на една скрипта за поставување на повеќе машини без промена на адресата, е начинот на кој еден сегмент добива три сопственици на истата вредност. Членовите не им требаат сопствени идентитети за да препраќаат рамки. Им треба точно еден идентитет по домаќин што мора да биде достапен на тој сегмент.

Мостот што само префрлува рамки воопшто не му треба адреса на тој сегмент. Ако го оставите без број, отстранувате цела класа судири, под услов домаќинот сѐ уште да има проверен пат за управување. Прво потврдете го пристапот, второ отстранете ја адресата и трето проверете достапноста.

Ако адресата што ќе ја избришете е единствениот пат во машината, бришењето како експеримент е самонанесен прекин, а не дијагноза. Проверете го надворешниот пат пред да тестирате нешто.

Направете корекцијата да преживее подигање

Менувањето на активен интерфејс го поправа тековното подигање и ништо друго. Што и да ја пресоздава адресата при подигање, ќе го врати конфликтот при следното подигање и ќе заклучите дека корекцијата не работела, иако всушност никогаш не била трајна. Забележете која датотека сте ја смениле, за да го потврди следното подигање одлука наместо да открие изненадување.

Најдете го сопственикот на таа конфигурација: профил на мрежен менаџер, датотека по интерфејс, дефиниција на контејнер или VM, или cloud-init фрагмент. Сменете ја таму, потоа намерно подигнете еден погоден домаќин за да потврдите дека новата вредност е таа што се враќа. Подигањето е единствениот тест што докажува трајност.

Резервирајте ги адресите на мостот во DHCP опсегот како исклучоци или преместете ги надвор од него. Резервацијата што постои само во табела не е исклучок и распределувачот нема да ја прочита.

Докажете го со секој клиент на линија

Една успешна врска не докажува ништо, бидејќи првичниот симптом се појавуваше само кога се менуваше редоследот. Подигнете го секој предвиден клиент, менувајте го редоследот на подигање и повторете по повторно поврзување. Потоа подигнете го домаќинот што порано губеше трката и потврдете дека адресата преживува.

За директна потврда, проверете дали има дупликат сопственик пред да ја доделите адресата и потоа набљудувајте ја табелата на соседи. Ако ништо не одговори на проверката и адресата остане единствено поседувана низ целосен циклус на подигање, конфликтот е решен, а не само скриен. Командите подолу ги извршуваат двете проверки на мостовниот уред. RFC 5227 го опишува однесувањето на проверка и објавување што го применуваат овие алатки, и тоа е изворот што се цитира кога некој предлага да се исклучи откривањето.

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

Проверка што не добива одговор е очекуваниот резултат на чист сегмент. Проверка што предизвикува одговор ви ја дава хардверската адреса на преостанатиот сопственик, истиот доказ што настанот на Windows ви го дал на почетокот. Чувајте го тој излез со записот за промената, бидејќи е единствениот доказ дека адресата е единствено држена.