To eiere, én adresse: doble IP-er på en TAP-bro

Én Windows-klient holder 10.8.0.2 og virker til startrekkefølgen endres; da rapporteres samme adresse som en konflikt, og ingenting ved klienten er endret. En annen vert på samme brokoblede segment krever samme verdi, og maskinen som blir ferdig med konfigurasjonen sist, taper som regel. Begge tror de eier den, og taperen slutter stille å bruke en adresse den fikk beskjed om å bruke. Nettopp det å behandle dette som et tidsproblem er det som gjør at det kommer tilbake ved hver omstart.

Les konfliktbevisene før du rører en bro

Windows rapporterer en adressekonflikt sammen med maskinvareadressen til den andre kreveren. Den maskinvareadressen er det nyttige faktum, fordi den peker på ett grensesnitt på én vert, mens hendelsens viste navn ikke sier noe om hvor duplikatet bor. Skriv ned maskinvareadressen før du endrer noe.

ARP-basert duplikatregistrering undersøker konkurrerende eiere før en adresse tas i bruk, og følger deretter med videre. Derfor kan en vert som var fraværende mens du konfigurerte nettverket, fortsatt forårsake en konflikt en time senere. Undersøkelsen er ikke en engangssjekk ved oppstart. En maskin som dukker opp etterpå, kan ta en adresse som har vært i rolig bruk hele dagen, og derfor ser feilen ut som et kappløp i stedet for en konfigurasjonsfeil.

En konflikthendelse sier i seg selv ikke hvilken konfigurasjon som skapte det andre kravet, og hvis du rydder adresser eksperimentelt, ødelegger du koblingen som ville ha fortalt deg det. Poenget med beviset er å gjøre en maskinvareadresse om til et grensesnitt du kan undersøke. Å søke i inventaret etter maskinnavn sender deg som regel til feil vert.

Kartlegg hvert krav på segmentet

Et brokoblet TAP-oppsett forbinder Ethernet-segmenter som før var adskilte, så adresser som var unike i sine egne nettverk, kan kollidere når rammer deler én lenke. Derfor finnes denne feilklassen på en VPN og ikke på de rutede nettene den erstattet. List opp hver mulig eier i stedet for den første du mistenker.

Gå gjennom listen i denne rekkefølgen: adressene på hver broenhet og dens medlemsport, OpenVPN-poolen og enhver fast tildeling per klient, samt enhver DHCP-server som dekker det brokoblede segmentet. Sammenhold deretter maskinvareadressen fra konfliktrapporten med grensesnittene du fant.

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

Poolen og DHCP-området er de to eierne folk glemmer. Skriv ut begge områdene sammen og se etter overlapp før du gjør noe annet. En håndtilordnet broadresse og en pool som deler ut samme verdi, vil før eller siden kollidere, og kollisjonen ser tilfeldig ut helt til begge områdene skrives ut side ved side.

Numre broer bare der de trenger en identitet

I en vanlig vertsbro bærer broenheten vertens konfigurasjon for tredje lag, og Ethernet- og TAP-medlemmene opptrer som porter. Å gi hvert medlem sin egen adresse, eller kopiere ett oppsettsskript til flere maskiner uten å endre adressen, er måten ett segment ender opp med tre eiere av samme verdi. Medlemmene trenger ikke egne identiteter for å videresende rammer. De trenger nøyaktig én identitet per vert som må være nåbar på det segmentet.

En bro som bare svitsjer rammer, trenger ikke adresse på det segmentet i det hele tatt. Lar du den være unummerert, fjerner du en hel klasse kollisjoner, forutsatt at verten fortsatt har en administrasjonsvei du har verifisert. Bekreft tilgang først, fjern adressen som nummer to, og kontroller nåbarheten som nummer tre.

Hvis adressen du er i ferd med å slette, er den eneste veien inn til maskinen, er det en selvpåført nedetid og ikke en diagnose å slette den som et eksperiment. Verifiser den alternative veien før du tester noe.

Sørg for at rettelsen overlever en omstart

Endring av et aktivt grensesnitt retter den gjeldende oppstarten og ingenting annet. Det som enn gjenoppretter adressen ved oppstart, vil gjenopprette konflikten ved neste omstart, og du vil konkludere med at rettelsen ikke virket, selv om den faktisk aldri var varig. Noter hvilken fil du endret, slik at neste omstart bekrefter en beslutning i stedet for å avsløre en overraskelse.

Finn eieren av den konfigurasjonen: en nettverksadministratorprofil, en fil per grensesnitt, en container- eller VM-definisjon, eller et cloud-init-fragment. Endre den der, og start deretter bevisst én berørt vert på nytt for å bekrefte at det er den nye verdien som kommer tilbake. En omstart er den eneste testen som beviser varighet.

Reserver broadressene inne i DHCP-området som unntak, eller flytt dem utenfor. En reservasjon som bare finnes i et regneark, er ikke et unntak, og tildeleren vil ikke lese den.

Bevis det med hver klient på nett

Én vellykket tilkobling beviser ingenting, fordi det opprinnelige symptomet bare dukket opp når rekkefølgen endret seg. Start hver tiltenkte klient, varier startrekkefølgen, og gjenta etter en gjenoppkobling. Start deretter verten som pleide å tape kappløpet på nytt, og bekreft at adressen overlever.

For direkte bekreftelse, undersøk om det finnes en dobbel eier før adressen tildeles, og følg deretter med på nabolagetabellen. Hvis ingenting svarer på undersøkelsen, og adressen forblir unikt eid gjennom en full omstartssyklus, er konflikten løst og ikke bare skjult. Kommandoene nedenfor utfører begge kontrollene på broenheten. RFC 5227 beskriver undersøkelses- og annonseringsatferden som disse verktøyene utøver, og det er referansen man siterer når noen foreslår å slå av registreringen i stedet.

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

En undersøkelse uten svar er det forventede resultatet på et rent segment. En undersøkelse som fremkaller et svar, gir deg maskinvareadressen til den gjenværende eieren, det samme beviset Windows-hendelsen ga deg i starten. Ta vare på den utskriften sammen med endringsloggen, fordi det er det eneste beviset på at adressen holdes unikt.