Два власника, једна адреса: дупликати 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 дао на почетку. Чувајте тај излаз уз запис о промени, јер је то једини доказ да је адреса јединствено држана.